[SOLVED] Can cadence NCsimulator initialize unresetable flip/flops?

[George_P]

Hi,

does NCsim provide some kind of simulation switch/parameter to initialize all the unresetable flip flops of the design, instead of leaving them undefined (or X)?

Regards,
Giorgos

 

[rca]

I don't know for NCsim but for Modelsim you could compile the verilog code with initialization of flop.
do you work at RTL or gate level?

 

[George_P]

I don't know for NCsim but for Modelsim you could compile the verilog code with initialization of flop.
do you work at RTL or gate level?

I am working on gate level, with a verilog netlist, at NCsim. Any ideas?

Regards

 

[DFT_designer]

Hi,

Is your question: can ncsim force values in the simulated design ?
My answer is yes, it is feasible. To do it you have to reset the simulation, select a signal from the "design browser" not the "waveform window", right click choose the "create force" command, select a value, run the simulation.

regards,

 

[George_P]

Hi,

Is your question: can ncsim force values in the simulated design ?
My answer is yes, it is feasible. To do it you have to reset the simulation, select a signal from the "design browser" not the "waveform window", right click choose the "create force" command, select a value, run the simulation.

regards,

Thank you, but I need to do this for thousands of flops, so I am asking for an automated feature of the simulation tool for unresetable memory elements. Otherwise I will do it by scripting.

Regards

 

[rca]

The question why you need to reset this flop?
If the design is well done, normally the unreset flop should not impact the behavior, no?
What I did for previous design, during the DFT, I reports all flops in a file, and with a simple script, I force all flops with random values to not test with all zeros or all ones.

 

[jrwebsterco]

Pardon if this is getting away from the main question, but am curious if anyone has any experience with this ...

Some area-critical design requirements discourage resettable flops everywhere due to them not truly needing to be reset in *principle* (and in reality).
(or SEE requirements may discourage async-resets, but many libs don't provide a true sync-reset flop)
However, in gate-level simulation *practice*, advanced synthesis optimizations esp. with complementary-output flops can result in logic-clouds that will not resolve if the flop outputs are X, and not only on reset paths.
(DC-Ultra seems to be very aggressive about doing this, even when setting hdlin_ff_always_sync_set_reset to true).
The result is an inability to get parts of a design out of X during reset in gate-level sims.
Built-in time-zero random initialization simulator features often will not help if e.g. the clock-network leafs are not at non-X during time-zero (e.g. due to a PLL model or delays with SDF annotation).

In this case, some type of simulator-specific script after time-zero (after clock settling), or a custom-PLI-function approach might be the only practical solution.
(we resorted to the latter, even re-calling the PLI in the middle of a sim when the PLL got restarted)
And even then, one must be careful to not be fooled into being helped by the random init values coincidentally hiding a true bug!
2-value logic simulation also seems dangerous since it might hide useful timing-violation behaviors.

I think I once read a discussion somewhere about enhancing simulators to support a complementary "not-X" value in addition to X, to get around this problem.
(maybe it was at the end of item 5 of this ESNUG: https://www.deepchip.com/posts/0246.html )
I'd also love to know about a tech-article that tries to give thorough practical treatment of all of this.

 

[sameer_dlh25]

Hi George_P,

I think you need some script. Unfortunately there is no easier way to do the same :-(

Cheers
Sameer

 

[George_P]

Hi George_P,

I think you need some script. Unfortunately there is no easier way to do the same :-(

Cheers
Sameer

Thank you Sameer and RCA. Indeed I didn't find any other way so I did through scripting deposits to all of these FFs.

The reason for wanting to do sth like this is just to verify some timing and functionality issues, until an initialization problem is solved. Yes, in principle, in a working design it should not be necessary.

My regards guys.