Can I pass value between runs in Transient Noise simulation?

Presumably you mean with the "multiple runs" capability? If so, this is not possible. It sounds a rather strange requirement - what are you trying to actually do?

Andrew

Yes, multiple runs, like in this picture.


I need to simulate noise of a comparator by injecting stair case signal at one input and fix voltage at the other.
For each step value, I need to read if the output is 1 or 0.
After running this transient noise multiple times, let's say 1000 runs, I will get how many 1s and 0s I got out of 1000runs.
At the end, I am expecting an s-curve with y-axis as probablility of 1 and x-axis as the step value.
I tried to avoid post-processing, so I thought if I can pass values between runs, I can somehow count this 1s for each run.

It doesn't seem particularly onerous to do this as a post-processing step, and in fact doing that would allow you to do the sweep of the seed (which is all the "multiple runs" does) in ADE instead which would allow the simulations to run in parallel. If you'd set up a dependency between them it would be more complex and limit you to run them sequentially.

Anyway, it can't really be done right now - I guess you could potentially have a Verilog-A model which read from a file at the beginning and wrote at the end of the transient analysis - but I think it's going to be tricky to get that working properly. Far more complex than just doing this with post-processing (which should be possible in ADE).

Andrew

Andrew Beckett said:

in fact doing that would allow you to do the sweep of the seed (which is all the "multiple runs" does) in ADE instead which would allow the simulations to run in parallel.

How can I sweep the seed?
I have just checked it that I cannot put a variable in the seed.

Yes, set the Noise Seed to VAR("iter") and then a variable called iter will get created automatically. You have to use the VAR() syntax - there are some fields that do directly allow a variable to be entered, but the standard syntax is to use VAR("varName").

Andrew

Dear delgsy,

delgsy said:

How can I sweep the seed?
I have just checked it that I cannot put a variable in the seed.

First, in direct answer to your last question that Andrew answered, Andrew is absolutely correct in that the seed can be a assigned a sweep variable using the syntax VAR("design_variable_for_seed"). I have swept transient noise simulations through seed values using this exact syntax and it works as you desire.

delgsy said:

I need to simulate noise of a comparator by injecting stair case signal at one input and fix voltage at the other.
For each step value, I need to read if the output is 1 or 0.
After running this transient noise multiple times, let's say 1000 runs, I will get how many 1s and 0s I got out of 1000runs.
At the end, I am expecting an s-curve with y-axis as probablility of 1 and x-axis as the step value.
I tried to avoid post-processing, so I thought if I can pass values between runs, I can somehow count this 1s for each run.

I think your intent is to characterize the noise margin of the comparator under study - i.e - the degree to which it can resolve the difference between the reference voltage on one of its terminals (in your words "the fix voltage at the other terminal" and the applied voltage on its other terminal (in your words "the stair case signal").

I have two suggestions if I may...

I think the criteria that the comparator output be a logic "1" or a logic "0" at the d of each transient noise simulation may not provide an accurate assessment of the comparator noise margin.

Why do I make that statement?

1. Any real comparator will have a finite gain that will vary with a number of environmental factors (supply voltage, temperature), silicon process, overdrive, and the slope of the input as it crosses the reference voltage at its opposite input. As a result, its propagation delay time will show significant variation as the input signal approaches the reference voltage applied to its other terminal. The propagation delay time may, in fact, exceed the simulation time you choose. In this case, the output signal may not reach its final logic state at the end of your simulation time or may exhibit unstable behavior that will not settle by the end of the simulation. This form of metastable behavior is probably one you are familiar. Hence, collating the number of times the comparator output is classified as a logic "1" or logic "0" at the end of each simulation will not provide a true measure of the noise margin. This same effect occurs when characterizing the set-up and hold-times of a logic gate or flip-flop. An example from a reference I include is shown Figure 1.

2... and what do I suggest as an alternative criteria?

a. I might suggest that you alter your methodology to measure the propagation delay time for each simulation.

b. In lieu of using a stair case function, use a linear ramp whose slope you vary for each set of simulations (include both positive and negative slopes). The use of a staircase function does not show the variation in comparator response with its slope about the reference voltage - which in my experience can be significant.

As such, you will collect a propagation delay for each transient noise simulation. at input voltages far from the reference, the propagation delay will be relatively constant. Normalize all propagation delay times to this value. The noise margin can then be defined as the range of input voltages whose propagation delay times are no more than, say, 1% or 10% the minimum propagation delay time. There will be a noise margin for each set of transient noise simulations at a specific input slope.

Please excuse all my words delgsy! However, I did want to alert you to some concerns I have in the interest of saving you time in the long run!

Shawn

Figure 1

definition_setup_hold_times_markovic_2001_sml_083019.pdf

Please allow me to comment on your proposed methodology in the interest of helping you avoid some unexpected results if I may. Feel free to ignore my comments if you wish!

I think your intent is to characterize the noise margin of the comparator under study - i.e - the degree to which it can resolve the difference between the reference voltage on one of its terminals (in your words "the fix voltage at the other terminal" and the applied voltage on its other terminal (in your words "the stair case signal").

I have two suggestions if I may...

I think the criteria that the comparator output be a logic "1" or a logic "0" at the d of each transient noise simulation may not provide an accurate assessment of the comparator noise margin.

Why do I make that statement and what do I suggest as an alternative criteria?

1. Any real comparator will have a finite gain that will vary with a number of environmental factors (supply voltage, temperature), silicon process, overdrive, and the slope of the input as it crosses the reference voltage at its opposite input. As a result, its propagation delay time will show significant variation as the input signal approaches the reference voltage applied to its other terminal. The propagation delay time may, in fact, exceed the simulation time you choose. In this case, the output signal may not reach its final logic state at the end of your simulation time or may exhibit unstable behavior that will not settle by the end of the simulation. This form of metastable behavior is probably one you are familiar. Hence, collating the number of times the comparator output is classified as a logic "1" or logic "0" at the end of each simulation will not provide a true measure of the noise margin. This same effect occurs when characterizing the set-up and hold-times of a logic gate or flip-flop. An example from an example analysis I performed of the set-up and hold-times of a DFF is shown in Figure 1.