Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/index.php?threads/gate-level-simulations-a-necessary-evil.785/
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021370
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

Gate level simulations - A necessary evil

3 part series discussion the NEED for GLS and why is it considered EVIL. The final wrap up with some good practices.

Part 1 - siddhakarana: 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.

Part 2 - siddhakarana: Gate Level Simulations : A Necessary Evil - Part 2
[FONT=&quot]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.[/FONT]


Part 3 - siddhakarana: Gate Level Simulations : A Necessary Evil - Part 3
The response to the initial 2 posts (Part 1, Part 2) clearly show that GLS touches the career profile of almost all verification engineers. I am wrapping up this 3 part series on GLS with some recommendations that might be of some help if you aren’t already deploying them. Please do drop in an email or comment to share your tips & tricks.

<script type="text/javascript" src="http://platform.linkedin.com/in.js"></script><script type="in/share" data-counter="right"></script>

How about sharing your experience with GLS?
 
Last edited by a moderator:
very good. I read it and showed it to my professor.

The problem is formal verification guys don't like it that much.
 
At conceptual level, yes formal verification should be able to address all of these but the tools have limitations that provides the breathing space for GLS.
 
Back
Top