Pitfall of Tcl - Over Reaching Timing Exceptions

Dec 30th, 2019   |   Hollis , Robertson

Generating set_false_path and set_multicycle_path timing exceptions can be an arduous task for block owners in an SoC.  It requires detail understanding of the design, which usually remains with the RTL designer, and sometimes several STA iterations to reveal timing violations where exceptions may be required, but that is a subject for another time.  The scenario for discussion here is when an SoC is in tapeout phase of the project and a block or hard macro owner adds a timing exception that causes heart palpitations for the SoC integrator.

Assume the blk1 circuit in Figure 1 below.

The block contains a bus of static mode registers.  The alert block owner recognizes this and set all these registers to false path.  To ensure all registers are captured the block owners generates the following set_false_path.

set_false_path –from [get_pins –hier –filter “full_name =~ *mode*/CK”]

At blk1 level this works perfectly, however, Figure 2 shows the SoC level circuit.

Since the set_false_path is auto-promoted to the SoC level signoff STA constraints, it is over reaching into blk2 timing path from blk2/umodem_lane1_reg_1/CK and blk2/umodem_lane2_reg_2/CK.  Both are now false path.

PROBLEM

How would the SoC integrator find this?  Are there PERL scripts to locate them? Do the PERL scripts scale with design size? Is the PERL script robust enough to support various design topologies?

Does the SoC integrator have STA Tcl scripts to find this? How does the SoC integrator even know which block is the intended scope?

If neither of the above then there must at least be a design review where multiple designers manually drudge through all constraints to find such an overreach because this is a chip killer.

SOLUTION

Timevision by Ausdia, has a feature, as part of “Check SDC Module”, which will not only find these gross over reaches, but will report the intended scope of the set_false_path, and report all blocks where the overreaching set_false_path has impacted, along with the constraint file and line number.  If the set_false_path originated from a Tcl proc or nested Tcl files Timevision will report the entire Tcl stack for ease of debug.

This check can be used in a regression flow so the SoC integrator can run it every time new design data is delivered from the block owner and a flag can be set to interrupt the design flow and notify both the appropriate block owner and the SoC integrator of the overreaching exception.

Below is a sample output.

Exception         Intended Scope    Actual Impact       Status

--------------------------------------------------------------------------------------

set_false_path2   blk1                    blk1 blk2          Over Reaching

“set_false_path2” details:

set_false_path (top_cons.tcl:18:2) -from [get_pins -hier \

          -filter "full_name =~ *mode*/CK"]

Tcl Stack = {top_cons.tcl 18}

No more heart palpitations for the SoC integrator!