GLS Kick-Start

A good reference is HERE

GLS is usually performed on ASIC IP or ASIC SoC. It is usually not performed on Soft IP or soft SoC implemented using FPGA programmable fabric core. The only time (I can humbly think of) that GLS is possibly considered on FPGA is when there’s an inaccuracy of FPGA design timing convergence reported by FPGA software (usually during parallel FPGA software development where timing model is still under QC); but for this case, GLS might not be the best tool to verify the software still.

A few more GLS details to take note on top of the reference …

(1) Negative timing check is common with higher process nodes. Simulators might have this negative timing check feature turned-off by default (meaning timing check will be turned-off) & provide explicit switch to turn it on. The negative timing check can be accurately restored with the feature switch as long as $setuphold or $recrem has an overall positive timing window. Besides, do check on process library if it comes with separated timing check placeholder for negative timing check handling, usually enabled through i.e. “`ifdef ntc”.

(2)??? Watch-out for negative timing delay (Yes. You can see the future now ??) in SDF potentially on interconnect delays. Make sure the timing delay negative value is insignificant (i.e. vs $timescale’s simulation resolution) to ensure accurate GLS run still. This is because tool can’t handle negative delay but just replace them with zero. If the negative delay is a concern, you’ll need to pre-process the SDF before GLS.

(3)??? When running with timing model, make sure correct timing check/delay value is back-annotated. Do provide correct tool switches correlated to format of SDF received to ensure correct values are back-annotated per timing corners run. STA tool that generating the SDF usually can choose to generate 3 corners timing info in a single file per (min:typ:max) triples format; or generate one corner timing info per file (still in triples format but all three values in bracket are the same). Please double check the SDF format with corresponding right switch as tool usually won’t flag any warnings on this. The tool will just do what you ask it to do.

(4) Process library might come with artificial transport delay modelling. When the transport delay is bigger than actual delay from SDF, different tool might handle timing back-annotation differently by default. Hence, do check on tool handling of different type of delays in Verilog with possible different switches i.e zero delay vs unit delay vs path delay vs distributed delay.

(5) Having an X simulated at sequential cell output when there’s a timing violation is not just purely handled by tool. You need to review Verilog coding of process library. Make sure timing placeholder (the specify block) of sequential cells includes notifier flag besides negative timing check handler. And make sure the UDP instantiated by the sequential cells (usually this is the way process library Verilog model is coded) is taking in notifier as input & produce X-output from its primitive truth table coded.

Complementary notes…

(6) ??? You can only disable timing check on the first flop of a pure double-synchronizer structure. The full list of registers should be coming from structural design team through SYN/STA tool generation. Don’t directly take constraint file from designers & blindly disable timing check of all the registers specified by false-paths.

(7)? ?? MCP test scenarios for GLS run should be enabled with corresponding MCP assertions.

(8)?? ? To reduce assertion rework on GLS due to optimized internal signals in netlist, compose assertions with port signals as much as possible. Modules ports usually wont be optimized away with hierarchical SYN.

(9)??? Functional glitch check on critical design signals can be achieved in GLS by defining $width requirement of the signals in a separated SDF. This could be a better approach comparing to assertion as for the assertion coding, you’ll have to identify/compose a much higher frequency sampling event to detect potential glitch.