Question about IOParameters arguments

[VictorY-1Qbit]

I've noticed that the performance of my application is strongly affected by the arguments of the IOParameters, that I defined in a InferenceRPUConfig before to convert my network to analog.

I'm not sure to totally understand the meaning of the different properties of this object from the documentation. I'm hoping that someone could help me to clarify a few points.

1. About inp_bound / out_bound: I think to understand that is the maximal logical values inputed to the DAC / ADC. So if inp_bound=2.0 and inp_res=1/(2**8), each input will be discretized into 2^8 (256) values between 0 and 2. Is it correct?
2. What happen if an input is lower than 0 or higher than 2 during the inference?
3. About inp_noise / out_noise: I think to understand that it represents all the electronic noise , excepted from the memristor reading noise (which is defined in the noise_model). This noise is additive, so after each multiplication of the VMM, a gaussian number centred on 0 and a std-deviation defined by out_noise will be added to the logical value. Is it correct?
4. Is the noise from DAC / ADC included in this inp_noise / out_noise? What other source of noise should be considered here?
5. What is justification for the defaults values inp_noise = 0.0 and out_noise = 0.06?
6. Finally, even when I set a seed for pytorch, numpy and python.random, the noise from inp_noise / out_noise are not reproducible. Is guess that could be related to a C implementation. Is there a recommended way to seed the RNG for the whole library?

Environment: python 3.9.2, aihwkit 0.8, torch 2.01

[maljoras]

Hi @VictorY-1Qbit ,
thanks for the questions. At the outset, many of the design choices of the IOParameters are explained in this paper, maybe worth a look.

1. The input is clipped to -inp_bound to inp_bound, however, the input management (i.e. noise management) potentially scales the digital input (dynamically or fixed) before applying it to the DAC. The input bound range clipping and quantization happens after that. Note that inp_res setting is applied to the full range. So if set to 256, there are 256 bins from -inp_bound to inp_bound. Because of the scaling, the inp_bound typically is set (arbitrarily) to 1 to normalize the analog input in respect to analog noise setting.
2. It might get scaled (see noise management or input range learning). If input is still larger than the input bound after scaling, then it will get clipped.
3. The noise_model defines only has "static" noises that are once applied to the conductances. There are fixed (once added to the weights). Thus a repeated MVM with the same input would result in the identical output (such as programming noise is once applied). They are only updated for instance when calling model_drift_weights. However, the noise sources defined by IOParameters are applied on the level of a single MVM and therefore are system noise, but they don't statically affect the weights/conductance (only the output). For instance, if out_noise > 0.0 then output noise is added anew each time an input is applied (thus the same input will result in different outputs even when repeatedly given although the internal weights do not change). Yes, the output noise is simply Gaussian additive.
4. DAC / ADC in the aihwkit, just refers to the quantization and range clipping. Noise is set with inp/out_noise. Typically that noise can be attributed to the ADC or other system effects. This depends on the application.
5. They are from this publication Gokmen & Vlasov 2016, where they are justified.
6. Yes, the IOParameter noise is not seeded with the python seed. This is on purpose, as this hardware noise is always present. In case of an actual hardware one would not be able to seed it either.

[victor-yon]

Thank you for the detailed answer, that clarify the data flow and will help me to set appropriate values.

I'm just not sure to understand the argument about seeding (the last point). Of course it is not possible seed a physical hardware, but controlling all the variables is one advantage of the simulation. Professional circuit and electronic simulation tools allow the user to fix a seed because it is useful for reducibility and debugging.

In my opinion aihwkit should let the user seed the RNG. I should maybe create an issue to talk specifically about this point.