SDF simulations -> why needed?

[ivlsi]

Hi All,

Why SDF (Gate-Level) simulations are required for SignOff? Why just STA is not enough?

Why we can see 'X' propagation in SDF simulations, which were not in RTL?

Once 'X' propagation occurs in SDF simulation, how to fix them? Should it be done using Verilog's 'force' and 'release' commands? Are there another methodologies?

Thank you!

 

[RCircuit]

Timing constraints can be wrong, some paths maybe constrained incorrectly. And analog liberty file maybe not accurate.
If a MUX has sel as x, the gate level output would be x, even inputs are all ones or zeros. While "assign out = sel? in1 : in0" can be non-x.
If you have vcs, you are lucky. Otherwise force and release has to be used.
I tried this method, it seems good.
https://www.nandigits.com/use_case_remove_x_in_gate_simulation.htm

 

[maulin sheth]

STA is : static timing analysis and when we do SDF simulation at gate level netlist with pattens is dynamic timing analysis.
So we need to do simulation with SDF because it confirms that patterns are passing with timing also, as pattern on design run with actual timing. So we need confirmation that patterns are passing with timing or not?

 

[ivlsi]

While running SDF simulations, Setup and Hold timing checks for synchronizers should be disabled. So, how practically should it be done? By editing the SDF? Lib cell itself? By forcing synchronizer's output be the same as it's input?

 

[RCircuit]

You can modify SDF file. The better way is to use run script to disable timing check on those sync cells. E.G. Questasim, tcheck_set dut/uabc/usync off
The link I gave doesn't have sync cell handling part. But you can use that tool or prime time to get_cells on all first stage sync flops.

 

[ads-ee]

You can modify SDF file. The better way is to use run script to disable timing check on those sync cells. E.G. Questasim, tcheck_set dut/uabc/usync off
The link I gave doesn't have sync cell handling part. But you can use that tool or prime time to get_cells on all first stage sync flops.

This is why I've found it to be a good practice to have some module called something like TWO_FLOP_SYNCHRONIZER.v(vhd) with the names of the synchronizer flops like synchronizing_ff[1:0] so they are very easy to find in a netlist. Try finding them if everyone names them differently in a big design across multiple levels of hierarchy .

Regards

 

[sharath666]

1.SDF simulations are a great confidence booster.
2.STA does not show asynchronous paths.
3.SDF simulations show behaviour of circuit with DFT structures embedded.(You are verifying that
DFT structures don't alter the functionality)

RTL simulations show X only if there is multiple drive, not otherwise. There might be genuine problems with your design which are not indicated in RTL simulations. I faced one a few years back. Thereafter we decided to buy the X tracking licence in VCS.

For synchronizers you will have to reset the notifiers for the 1st sync flop to avoid X propagation.

 

[ivlsi]

RTL simulations show X only if there is multiple drive, not otherwise

What's about not defined signals like floating inputs or outputs from not initialized memories?

There might be genuine problems with your design which are not indicated in RTL simulations

For example?

we decided to buy the X tracking license in VCS

Does Cadence's NCSIM have the same license/feature? What does the feature actually allow to do?

For synchronizers you will have to reset the notifiers for the 1st sync flop to avoid X propagation

Should it be done by simulator's command(s) or by editing the SDF?

 

[sharath666]

1.Floating inputs will be as the name indicates, floating. They will not be used within the design. So it should be ok. A proper used signal will no be X. That is what I meant.
2.Not able to recollect.
3.Not sure if NCSIM also has this feature. Maybe you can go through VCS user guide and find out more about this. This feature will actually show a signal as X in RTL simulations in faulty designs.
4.You have to do it manually.In the testbench file I suppose.

 

[dave_59]

The "X" propagation feature when using SDF in a gate-level simulation is available in any Verilog simulator. Timing checks have a "notifier" register that creates an event when violating a timing check during simulation. That event is used to produce an X on the output of a flip-flop or latch when the violation happens. The timing checks and notifiers are part of the gate-level netlist that is the output from your synthesis tool. RTL designs don't have flip-flops or gates yet, and there are no propagation delays for SDF to annotate.

I believe all major simulation vendors (Mentor/Cadence/Synopsys) have an X tracing feature to help you find the source of an X. At Mentor we call it Causality or Time Cone. It involves looking a signal transition to X, and finding the root cause of what cause that signal going to X. That usually means looking back in time to see the cone of logic and trying to figure out which signal transition in the input cone caused the output of of the cone to go to X. When the cone involves flip-flops you may need to go back in clock cycles to see the transition to X on the data input to the flop. This functionality does not usually come with the basic version of the tool because there is a lot more analysis and data to store.

A big problem with with using dynamic simulation to catch these timing violations is that you have to have the right set of stimulus to produce the error. Clock domain crossing tools can be a big help in finding these error without stimulus because they use exhaustive formal analysis to verify your timing checks.

 

[RCircuit]

Hi Dave, CDC tool is only used to check if any sync logic is missing. It can't replace any simulations, right? Well, using gate level simulation to catch CDC problem doesn't make sense either.

 

[dave_59]

RCircuit, not sure if you are agreeing or disagreeing with me.

My point was dynamic simulation, whether RTL or gate-level, requires stimulus to introduce produce errors that then need to be observed. Static/formal analysis is exhaustive. Although the computational requirements of static analysis can be prohibitive, certain problems can localize the analysis in to smaller pieces that can be much more effective than dynamic simulation. CDC and initialization/reset tracing are two examples.