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!
