gate level simulations

joecool · Senior Joined: Jan 09, 2006 Posts: 39 Location: Austin, TX

I was wondering what everyones thoughts are on gate level simluations.

Is it enough to say:

-RTL passes simulations
-a Logic Equavlance check of RTL verses Gate passes
Therefore the gate is working?

Or is it better to run a gate level sim?

jun · Senior Joined: Mar 03, 2007 Posts: 129

Gate level simulation is useful for timing check.
Though there is STA for timing check, STA rely on user's timing constrain. In case user does not constrain timing properly, such as set false path/multicycle path incorrectly, etc, the timing violation may not be found since timing report maybe shows everything is fine.

In this case, the gate level simulation, work as dynamic timing check, can help user to find timing problem.

normandie · Senior Joined: Jul 04, 2007 Posts: 30

what he says is true.
you'll find many timing violations when you run a gate-level sim.
in our experience we normally find hold timing violations.

You dont need to run all of your tests though. Gate level sim is slow. some test we run took weeks to hit the 5M cycle mark.
Find good candidate tests for gate-level sim.

FYI even the netlist from post layout is subjected to tests.
Just to verify if everything is ok before really taping out.

joecool · Senior Joined: Jan 09, 2006 Posts: 39 Location: Austin, TX

Thanks for the feedback.

The main reasoin why we do gate is to catch some async issuses.

holger · Newbie Joined: Sep 06, 2007 Posts: 1

jun · Senior Joined: Mar 03, 2007 Posts: 129

tessitd · Senior Joined: Sep 05, 2006 Posts: 286 Location: Colorado

As several posters have said Gate Level Simulations are necessary, I call them essential. Here is a quick list of what I have found with Gate Level Simulations:

1) RESET, RESET, RESET - the Chip doesn't get out of reset. Mostly the RTL coder didn't initialize something with reset but used a declared verison (shows up in Synthesis log, but who has time to read those). I spend most of my gate simulations issue here getting the thing running. Start with Gates as soon as you get a decent netlist+SDF and you will be rewarded with going home on time a few night. Don't do this and pull a few all nighters wondering what the heck is going on!

2) PLL Configuration Issues - Assumes your Foundry simulation model is sound. Nothing worse then clocks not starting.

3) Async clock domain crossing issues; should be caught by running Lint and CDC tools, again who has time to read all those reports.

4) IO timing not implemented correctly in STA or not written yet for that new DDR-X memory but we have a simulation model!

5) Checking polarity between blocks - oops we forgot to connect block A and block B in RTL simulations, but we have them in gates. Do they talk to each other (this is the Mixed Signal Example above).

Biggest thing you could do to your BFM models (whatever language) is to allow signals to be checked and generted in simulation within the tolerances allowed. This makes gate level simulation much more interesting and realistic.

Gate Level simultions are necessary, but don't do every test - just basic functionality should get it done. Once you start seeing errors come out of Gate Simulations you can go back to STA and your reports and show what needs to be fixed.

TomT...

sharanbr · Senior Joined: Sep 27, 2004 Posts: 194

To add:

We did find an issue in one of our designs where the fifo pointers to two different fifos came out of reset at different times and were off by more than a clock cycle during post route simulations. So, the fifos went out of sync and everything went haywre after that.
This was a very bad sync strategy used by the designer. But similar to bugs, such issues do keep creeping in into designs. We were glad that we did do gate sims.
Probably a constraint on reset would have brought this out. But such things are so easy to miss out. Especially when designer and STA personnel are different.

supertrooper · Senior Joined: Jan 11, 2005 Posts: 270

In addition to the aforesaid the following should be noted:

- for checking chip initialization and functional correctness gate-level
simulation with unit-delay timing would be sufficient. It runs much faster
in comparison with full-timing simulation (but still very slow than RTL
simulation). The advantage is that you can start to simulate your netlist
early not waiting for timing constraints to meet.
- in contrast full-timing simulation is used mainly for checking assync logic
and IO timing. As a rule it should incorporate worst and best timings.