Saturday, 6 February 2021

Tuesday, 19 January 2021

Sanity Checks in Physical Design Flow

 Sanity Checks in Physical Design Flow
  • check_library
  • check_timing 
  • report_constraint 
  • report_timing 
  • report_qor
  • check_design

check_library:
check_library validates the libraries i.e., it performs consistency checks between logical and physical libraries, across logical libraries, and within physical libraries.

This command checks library qualities in three main areas:
Physical library quality
Logic versus physical library consistency
Logic versus logic library consistency

check_timing
PNR tool wont optimize the paths which are not constrained. So we have to check any unconstrained paths are exist in the design. check_timing command reports unconstrained paths.
If there are any unconstrained paths in the design, run the report_timing_requirements command to verify that the unconstrained paths are false paths.

report_constraints
It reports to check the following parameters. 
Worst Negative Slack (WNS)
Total Negative Slack (TNS)
Design Rule Constraint Violations

report_timing:
report_timing displays timing information about a design.
The report_timing command provides a report of timing  information  for the  current design.  By default, the report_timing command reports the single worst setup path in each clock group.

report_qor:
report_qor displays QoR information and statistics for the current design. This  command  reports timing-path group and cell count details, along with current design statistics such as combinational, noncombinational, and  total  area. 
The  command also reports static power, design rule violations, and compile-time details.

check_design:
check_design checks the current design for consistency.

The check_design command checks the internal representation of the current design for consistency, and issues error and warning  messages  as appropriate.

Error messages indicate design problems of such severity that the compile command does not accept the design
Warning messages are informational and do not necessarily indicate design  problems.  However, these messages should be investigated.

Potential  problems  detected  by  this  command include

  • Unloaded input ports or undriven output ports 
  • Nets without loads or drivers  or  with multiple  drivers 
  • Cells  or  designs  without inputs or outputs 
  • Mismatched pin counts between an  instance  and  its  reference 
  • Tristate buses with non-tristate drivers 
  • wire loops across hierarchies, and so forth.