Multiple Monte Carlo Sampling in a single HSPICE simulation

I am trying to run a HSPICE simulation which involves testing for process variation and effect of noise on the circuit.

The HSPICE models that model the process variation require me to run a Monte Carlo simulation. Moreover, the models are encrypted so I cannot modify the parameters or even know what is being modified. I have to use a transient monte carlo simulation to trigger the process variation. For example, .TRAN 1ps 10ns sweep monte=100 firstrun=3, would trigger 100 instances of my circuit with different process variations for each of those instances and each instance would have a transient analysis run on it with a time step of 1ps for 10ns.

I want to now include transient noise to the above set-up. To accomplish this, I need to use ".TRANNOISE V(out) METHOD=MC SAMPLES=10 SEED=5" to create transient noise that will be added to the specified output node while performing the transient analysis. But when I include both these statements, HSPICE overwrites the second command without performing a Monte Carlo for the second command which in my case is noise. So it does not add noise at all, but only includes process variation. If I reverse the statements, then I only get noise but not the process variation.

How can I keep both the monte carlo sampling?

Hi,
What is the software are you using? Did you try to search for a solution in the manual/help of it?
Why do you want to vary process in Monte Carlo analysis? Corner selection isn't good to run transient with noise?
Why do you need to run transient analysis with noise and MC? Is it a switched-capacitor circuit?

frankrose said:

What is the software are you using?

Click to expand...

I am using HSPICE

Did you try to search for a solution in the manual/help of it?

Click to expand...

Yes. I have searched HSPICE Userguides (basic, simulation, RF, advanced as well).

Why do you want to vary process in Monte Carlo analysis? Corner selection isn't good to run transient with noise?

Click to expand...

Since I am using a foundry provided spice model, I need to use Monte Carlo analysis for getting intra-die process variation.

Why do you need to run transient analysis with noise and MC? Is it a switched-capacitor circuit?

Click to expand...

The circuit I am trying to simulate is a 6T SRAM cell. I want to see how transient noise affects the bit cell value on power-up. This is both dependent on the small variations between the transistors caused by process variation and the noise on the nodes.

In the distant past when I had to grind numerous MC
analyses, I would put a transistor (or pair) of each type
in the top level schematic so that I could get at the
transistor attributes easily. In the simulator I used, you
could print the .MODEL params and the .OP device
attributes. Running with process variation on and
mismatch off, would give the process deviation. The
simulator had a repeatable pseudorandom behavior,
and if needed I could set MCCNT= and return to any
problem iteration at will. Dunno about HSPICE.

Your use of tnoise I think may be over-elaborate -
especially if you do not, in fact, know the noise
attributes of the supply at the SRAM cell ports (and
these can be expected to vary across the chip, so
what are you thinking you will gain, given GIGO?

I don't know HSPICE either, in Cadence we simulated HSPICE models earlier but to check intra-die process variation we didn't have to use Monte Carlo analysis. Foundry models are generated at the edges of the technology too in FF/FS/SF/SS sections, they were enough for analog circuits, hard to imagine digital blocks require more. Power-up sequence of digital circuits is hardly affected by an issue like this, power-on reset handles the initial values. Your noise simulation I think won't give useful results either, there are temperature mismatches on the chip too... how will you simulate that? Over-elaborate.

dick_freebird said:

In the distant past when I had to grind numerous MC
analyses, I would put a transistor (or pair) of each type
in the top level schematic so that I could get at the
transistor attributes easily. In the simulator I used, you
could print the .MODEL params and the .OP device
attributes. Running with process variation on and
mismatch off, would give the process deviation. The
simulator had a repeatable pseudorandom behavior,
and if needed I could set MCCNT= and return to any
problem iteration at will. Dunno about HSPICE.

Click to expand...

This is correct. This is the way I would perform experiments if I know the model parameters and can change them. Since I am using proprietary models of the foundry, these are encrypted. I only see encrypted text when I tell HSPICE to print the variables being altered during the MC simulations. So, I know there are 5 variables being modified for each process variation MC.

Your use of tnoise I think may be over-elaborate -
especially if you do not, in fact, know the noise
attributes of the supply at the SRAM cell ports (and
these can be expected to vary across the chip, so
what are you thinking you will gain, given GIGO?

Click to expand...

The whole point of this is to model thermal noise causing voltage fluctuations on the bit value of the SRAM cells. For an exact reason as to why we want to do this, check out :

https://ieeexplore.ieee.org/document/4674345

The power-up of SRAM cells are unique to the IC due to process variation being unique in every IC (has great impact on hardware security). So the realistic way to model this is to get foundry provided SPICE models that mimic process variation on Silicon. We want to see the effect of different parameters such as supply voltage fluctuations on the reliability of a particular power-up state. So having a source of transient noise (which mimics thermal noise) along with process variation is essential to our experiment setting.

The foundry explicitly tells that the only way to model process variation is to use a particular library model and to include ".tran time_step stop_time MC". This triggers the process variation in the models.

frankrose said:

I don't know HSPICE either, in Cadence we simulated HSPICE models earlier but to check intra-die process variation we didn't have to use Monte Carlo analysis. Foundry models are generated at the edges of the technology too in FF/FS/SF/SS sections, they were enough for analog circuits, hard to imagine digital blocks require more.

Click to expand...

Well, the transient behaviour of SRAM is more analog than digital. Although the final output is binary, the actual bit value (values stored in the SRAM) are not digital during power-up.

Power-up sequence of digital circuits is hardly affected by an issue like this, power-on reset handles the initial values.

Click to expand...

Power-up states of SRAM are not random at all. They are directly dependent on the threshold variation mismatches during manufacturing. Please take a look at https://ieeexplore.ieee.org/document/4674345 which shows that the power-up state of SRAM is unique to the IC and can be used as the IC's fingerprint.

Your noise simulation I think won't give useful results either, there are temperature mismatches on the chip too... how will you simulate that? Over-elaborate.

Click to expand...

For now, I just want to see the effect of thermal noise on the SRAM power-up states when each cell has it's own process variation. So, thermal mismatches are not considered but only manufacturing mismatches are considered.

I see, it is interesting. I didn't read the whole IEEE article obviously, quite massive, so I have no idea about how reliable this fingerprint for years for example.
I think I am confused a bit about your terminology, in Cadence Monte Carlo analysis it is possible to vary the process and/or mismatch together/separately.
I thought you talk about MC-process variation, which is basically corner simulation, but now I think you talk about MC-mismatch variation ("...when each cell has it's own process variation..."). Is it correct?

frankrose said:

I see, it is interesting. I didn't read the whole IEEE article obviously, quite massive, so I have no idea about how reliable this fingerprint for years for example.

Click to expand...

They are quite reliable. So reliable that they are being used commercially to protect IP on FPGA (Xilinx Ultrascale+ has a PUF based cryptokey to protect IP).

I think I am confused a bit about your terminology, in Cadence Monte Carlo analysis it is possible to vary the process and/or mismatch together/separately.
I thought you talk about MC-process variation, which is basically corner simulation, but now I think you talk about MC-mismatch variation ("...when each cell has it's own process variation..."). Is it correct?

Click to expand...

Yes, you are correct. This is a mismatch analysis between transistors. We can perform this mismatch analysis on different corners as well. But I am limiting myself to TT corner as of now.