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.
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 - http://www.deepchip.com/items/0421-01.html
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
LinkedIn Groups : Low Power and Power Management Designs
ReplyDeleteAbsolutely, but it could be a lot smarter. Wiring is now the dominant load, and power-management means your supplies are variable - not to mention the variability in the Silicon. So I don't think Verilog & SDF really cut it as an approach. It's time for some new technology.
Posted by Kevin Cameron
Yes, I agree. But till we get the new technology we still rely on GLS. Are we even discussing on this new technology in the industry given the focus on the higher abstraction level?
Posted by Gaurav Jalan
LinkedIn Group: VLSI Design
ReplyDeleteIMO, GLS are worthless when it comes to the top two reasons people run them: Functional correctness of the netlist, and STA constraint verification.
The reason is that they are so slow and resource hungry. As a result, one is limited to running a small set of tests, that do little more than give you a warm and fuzzy feeling.
It is simply impractical to come close to LEC or STA with gate simulations, and if you cannot cover more than a fraction of the design, how much of these flow's issues do you really expect to catch?
Posted by Yair Aizenberg
Hi Yair, in past decade GLS still have survived for no. of reasons. Ofcourse they cannot replace the work that STA and LEC does. STA and LEC both still are netlist sign off tools. The point is that there are still areas that are left uncovered by STA and LEC where so far the industry has only GLS as an option.
Posted by Gaurav Jalan
LinkedIn Group: Low Power and Power Management Designs
ReplyDeleteUntil you get some new technology you will be stuck with "fast" spice if you actually want to verify anything. I do have some pat-pending technology for better GLS, but I doubt you'll see it anytime soon - the various Verilog standards are too dysfunctional to support it properly at the moment.
Posted by Kevin Cameron
LinkedIn Group: HVL (SystemC/C++/Verilog /Vera/Specman) Experts
ReplyDeleteMy 2 cents .... I don't know if I would agree that we should run GLS for checking lapses in constraints. For that we need to have constraint checkers. The reason for this is, one can only catch these constraint issues if one is lucky, as it is very vector dependent. Typically one has to run GLS to see a) reset behavior b) vector simulations. These two are prio-1, beyond that it is all nice to have. One can also do GLS for better power estimation.
Posted by Prasad A V S S
LinkedIn Groups : VLSI Design
ReplyDeleteSome aspects are out of scope for LEC or STA to determine CDC , Clocking tree Post layout
POR sequence check IO drive strengths at PADS are some of the reasons why we go for GLS through STA & LEC are clean.
Any more specific aspects other than this?
Posted by sampath pardu
LinkedIn Groups : VLSI Design
ReplyDeleteWhilst STA is a very powerful tool, it cannot verify all aspects of a design where multiple clock domains exist, as is the case in most designs.
STA needs to be used in conjunction with GLS, use STA to verify all aspects that it can and use GLS to fill in the holes such as re-synchronization between clock domains, and areas where STA will show a timing violation which is architecturally guaranteed but would be invalid using a cycle based approach, for example where a multi-cycle path exists by design intent.
In any case neither STA not GLS can be used for true functional verification which still has to rely on RTL level simulation and formal verifiation metheds.
There is no single technique that can adequately verify any design.
Personally I try to prove functionality using C++ cycle based models and optimized RTL simulations to verify logic functionality, neither of these verify timing so that has to be done with STA and GLS.
Posted by Phil Young
LinkedIn Groups : VLSI Design
ReplyDeleteGuarav has it right. STA provides great timing analysis but does nothing for functional verification. LEC gives a functional equivalence but occasionally the constraints leave holes in the coverage. GLS may only be as good as the effort you put into it, but GLS gives more that a warm fuzzy, it also provides a much needed sanity check that the design will function as expected.
Posted by Kevin Traynor
GLS is needed for sure in various places. However, with the new technology applied in other flow steps before GLS, many GLS work can be avoided. e.g, GLS is used to check design with synchronized clocks. With the current new tools in CDC area, such checks can be formally done by formal tools that can give more complete prove. The same for timing constraint checks, there are tools existing to verify timing constraints/exceptions at RTL or gate level. They can catch more issues than GLS. As for scan/DFT related logic that doesn't exist at RTL, you may can do gate-level formal verification using assertions. I have seen some successful stories in this area.
ReplyDeleteAlthough GLS is a necessity, we should continue reducing the efforts for GLS by catching bugs earlier.
i have a question..
ReplyDeleteif suppose i have incomplete sensitivity list, like
""always@(a or b) begin
c= a&b;
a = c|b;
end""
what i will get after synthesis?????
I have been checking out a few of your stories and i can state pretty good stuff. I will definitely bookmark your blog slide gate opener
ReplyDeleteWe recently found one issue , where in the clock tree because buffers were used we saw glitch and the clock was high cintinuously. These kind of issues can be caught in GLS verification only
ReplyDeleteVery comprehensive article on GLS. After reading you can assess your GLS understanding here: https://www.growdv.com/tests/gate-level-simulation/
ReplyDelete