Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

SDF simulations -> why needed?

Status
Not open for further replies.

ivlsi

Advanced Member level 3
Advanced Member level 3
Joined
Feb 17, 2012
Messages
883
Helped
17
Reputation
32
Reaction score
16
Trophy points
1,298
Activity points
6,868
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!
 

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
 

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?
 
Last edited:

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?
 

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.
 
  • Like
Reactions: ivlsi

    ivlsi

    Points: 2
    Helpful Answer Positive Rating
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 :p.

Regards
 

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.
 
  • Like
Reactions: ivlsi

    ivlsi

    Points: 2
    Helpful Answer Positive Rating
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?
 

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.
 

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.
 

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.
 

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.
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top