Wednesday, June 29, 2011

Gate Level Simulations : A Necessary Evil - Part 2

In the previous post, we discussed on why GLS is necessary. In this post we take a look as to why is it challenging.

Having GLS in the design flow means it needs to be planned and started quite early in the verification cycle. GLS has to pass through various stages before sign off and serves to check both functionality and timing (complementing STA & LEC). The setup of GLS starts off when the prelim netlist is released. Since this netlist is prone to functional and timing bugs, the GLS bring up uses selected functional tests with zero/unit delay (timing checks and specify blocks turned off) simulations. This helps in setting up the flow for GLS and confirm that the netlist is properly hooked up. Later with higher confidence netlist releases pre-layout SDF can be tried out till the final SDF is delivered. With final netlist and post layout SDF in place, GLS claims a lot of simulation time and debugging effort before sign off.

Why Evil?

Some of the challenges for GLS closure include –

- GLS with timing is inherently slow. Careful planning is required to decide the list of vectors to be simulated on netlist, turn around time for these tests and memory requirements for dump and logs.
- Identifying the optimal list of tests to efficiently utilize GLS in discovering functional or timing bugs is tough. Coverage/Assertions dedicated for GLS are required to assure completeness of these tests.
- Prelim netlist simulations without timing are prone to race conditions. With improperly balanced clock tree, sometimes data propogation to next stage happens before clock leading to unusual results.
- During the initial stages of GLS, identifying the list of flops/latches that needs to be initialized (forced reset) is a bug hurdle. Simulation pessimism would drive out X on the output of all such components without proper reset bringing GLS to a standstill.
- During clock tree synthesis, the clock port/net is replaced with a clock tree with buffers/invertors to balance the clocks. Monitors/Assertions hooked to the clock port in test bench during RTL simulations need to be revised for GLS to make sure the intended net is getting probed.
- A lot (hierarchy, net naming etc) changes with each netlist release leading to a lot of rework on the force statements (if any remaining) as well as the assertions/monitors.
- For netlist simulations with timing check, one needs to remove the synchronizer setup-hold constraints from the SDF file or disable timing check on these component instances. Getting a list of these synchronizers is a dauting task if certain coding conventions aren’t followed.
- Assertions are increasingly used for functional verification to improve observability and error detection. Reusing the assertions for GLS raises reliability concerns due to issues arising from incorrect clock connections or negative hold time causing assertion sampling at undesirable time.
- Debugging the netlist simulations is one of the biggest challenge. In GLS, ‘X’s are generated if there is a violation of timing requirements on any of the netlist components or when a given input condition is not declared in a UDP’s (User defined primitives) table. Identifying the right source of the problem requires probing the waveforms at length which means huge dump files or rerunning simulations multiple times to get the right timing window of failure. Engineers tend to get lost easily during the debugging of X propogation source.

Amidst all these challenges, GLS has been part of the ASIC design flow for decades making it a Necessary Evil!

Monday, June 20, 2011

Gate Level Simulations : A Necessary Evil - Part 1

Rising complexity, tightening schedules and ever demanding time to market pressure are pushing the industry to move to the next level of abstraction for design representation viz ESL (Electronic System Level). A similar push came in when there was a need to move from gate level to RTL. Even after efficiently using RTL simulations for a couple of decades, the industry is still relying on GLS (Gate level simulation) before sign off. Many organizations have recognized this effort so very important that there are dedicated GLS teams verying netlists for one project or the other throughout the year. Advancements in static verification tools like STA (static timing analysis) and Equivalence Checking (EC) have leveraged GLS to some extent but so far none of the tools have been able to abandon it. GLS still claims a significant portion of the verification cycle footprint.

On demand from some readers, here is a 3 part series that would try to address this less talked but significant topic.

Why necessary?

GLS or Netlist simulations typically need to start early when functional verification is still progressing to flush the GLS flow and verifying that the netlist is hooked up correctly. Timing at this point can be ‘zero delay’, ‘unit delay’. Later, these simulations are performed after back annotating first 'pre layout SDF' and finally ‘post layout SDF’ with the goal to assure that the design will run at the desired operating frequency. Following points summarize (in no specific order) the need for GLS in the ASIC design flow.

GLS are a must –

- To verify critical timing paths of asynchronous designs that are skipped by STA.
- To validate the constraints used in STA and EC. Static verification tools are constraint based and they are only as good as the constraint supplied. Careless use of wildcards, typos, design changes not propogating to constraints or incorrect understanding of the design all demand validation of these constraints.
- ­To verify any black boxes in EC. Multi vendor EDA tools flow is common. Sometimes to direct the synthesis, RTL instantiates a module from the synthesis tool vendor library for which an equivalent is hard to find in a competitor’s EC tool.
- To verify the power up and reset operation of the design.
- To verify that the design doesn’t have any unintended dependence on initial conditions.
- To verify low power structures absent in RTL and added during synthesis (power aware simulations). Apart from logical netlist even physical netlist (with VDD & GND) needs to be verified here.
- To collect switching activity for power estimation and correlation.
- To verify the integration of digital and analog netlist.
- To verify DFT structures absent in RTL and added during or after synthesis. Also required to simulate ATPG patterns.
- To generate ATE test vectors.
- To validate EDA tool flow change while moving from one vendor’s sign off tool to another.
- To validate that RTL simulations were not having any undesired force statements from test bench and masking bugs.

Finally, GLS is a great confidence booster in the quality of the netlist. The probability of having ‘sound sleep’ after tape out improves with GLS.

Suggested Reading -

1. ESNUG article -
2. All my X's come from Texas...Not!! (SNUG 2004)

Gate Level Simulations : A Necessary Evil - Part 2
Gate Level Simulations : A Necessary Evil - Part 3