Friday, September 9, 2016

GLS : gate level simulation


1. GLS is a step in the Design flow to ensure that the design meets the functionality after placement and routing.

2. What all inputs are needed to perform GLS: we Need post-routed netlist, Testbench, SDF (standard delay format file).

3. SDF is meant for Standard Delay format which will have all the delay information for the cell and the wire.

4. To generate SDF: we read in the routed netlist and the Extracted parasitics file(from Extraction Tool say StarRC extraction from Synopsys Inc, SPEF [ Standard Parasitics Extraction Format]).

5.Q .I have a doubt, say if I perform Formal Verification say Logical Equivalence across Gatelevel netlists(Synthesis and post routed netlist). Do you still see a reason behind GLS.

Answer: If we have verified the Synthesized netlist functionality is correct when compared to RTL and when we compare the Synthesized netlist versus Post route netlist logical Equivalence then i think we may not require GLS after P & R(placing and routing). But how do we ensure on Timing sir. To my knowledge, Formal Verification Logical Equivalence Check does not perform Timing checks and don't ensure that the design will work on the operating frequency, so still, I would go for GLS after post route database.


6. Q : I partially agree, say I perform Static Timing Analysis, after post route, I take the post routed netlist and the extracted parasitics file and the Design timing constraints and perform the Design timing checks say all possible checks(setup/hold/clockgating/…) do you still see a reason for GLS after post route.


Answer: I agree STA will check all the possible cases and corners and place the chip in different modes and things like that. But still see that GLS is a super-set over STA.

if by mistake the designer has placed timing exceptions like false-paths,multi-cycle paths, then how we ensure that the design will meet timing requirements, so i feel ,that there should be some mechanism to validate as a counter check, so i still feel GLS is needed after post route design sir.if the design is not synchronous friendly and purely asynchronous design then our STA will not favour us much.I still feel one more reason for GLS is how to ensure that the design will be out of reset and our reset sequences and initialization sequences, boot-ups are fine. So I feel GLS is mandatory though it has limitations of Ensuring the quality of test vectors.

Ensuring that the vectors will cover the complete area of the design (what i mean is the coverage analysis) and simulation run-time and things like that GLS ensure that the “Guarantee for Design Meeting for Functionality”

Gate level simulation represents a small slice of what should actually be tested for a tape-out. They offer a warm feeling that, what you are going to get back will actually work and secondly, they offer some confidence that your static timing constraints are correct.

But the common reason to go for a gate level simulations are as follows:
To check if the reset release, initialization sequence and boot up sequences are proper.
STA tools doesn't verify the asynchronous interfaces.
Unintended dependencies on initial conditions can be found through GLS
Good for verifying the functionality and timing of circuits and paths that are not covered by STA tools
Design changes can lead to incorrect false path/multi cycle path in the design constraints.
It gives an excellent feeling that the design is implemented correctly

So before shipping a design to tape-out, we run a limited set of gate level simulations. Because there are some difficulties associated with this GLS, they are:
Takes a lot of setting up and debugging
Takes a huge amount of computing recourses ( CPU time and disk space for storing wave)
RTL simulations alone take multiple days of run time even for a single regression. GLS takes 10* times.
Generation of debug data (VCD, Debussy) is impossible with GLS

In my opinion, the gate-level simulations are needed mainly to verify any environment and initialization issues.

Source: Internet 

No comments:

Post a Comment

Ethernet and more

Ethernet is a protocol under IEEE 802.33 standard User Datagram Protocol (UDP) UDP is a connectionless transport protocol. I...