Home > Community > Blogs > Digital Implementation > edi system s get metric command makes metrics reporting quick amp easy
 
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more convenient.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).
 

Email

* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

EDI System’s get_metric Command Makes Metrics Reporting Quick and Easy

Comments(0)Filed under: Digital Implementation, cadence, cadence.com community, encounter, "SoC-Encounter", SoC-Encounter, Encounter Digital Implementation, EDI system, Cadence Online Support, SoC realization, EDI 10.1, EDI 11, EDI 11.1, get_metric

In this blog post I want to highlight the command get_metric that was introduced in Encounter Digital Implementation (EDI) System 10.1 and enhanced further in version 11. Have you ever tried writing a script to extract information from the log file like run times or timing results? It becomes complicated quite fast when you're trying to capture the desired data, especially if a command is run multiple times. Also, any script is reliant on the log file format staying consistent.

The command get_metric was developed to make reporting metrics easy and straightforward. When the variable encEnableMetric is set to 1 (default in EDI 11) EDI System will automatically store metrics for a set of a predefined commands. These metrics are saved with the database (*.enc.dat/designName.metric) and made accessible from session to session using get_metric.

Here are some examples of how it is used:

get_metric by itself returns all metrics last computed:

encounter> get_metric
    34726           design.numStandardCell
    35327           design.numNet
     0               design.numFloatBlock
     4               design.numFixedBlock
     34726           design.numSingleRowCell
     0               design.numDoubleRowCell
     0               design.numMultiRowCell
     0               design.numIoInst
     0               design.numFixedIo
     0               design.numFloatIo
     156584          design.numTerm
     4.43            design.numTermPerNet
     40.547 %        design.util
     0.138           design.pinDensity
     1.10e+06 um     place.totalNetLength
     -1.036 ns       timing.setup.WNS.all
     -61.875 ns      timing.setup.TNS.all
     12273           timing.setup.numPaths.all
     100             timing.setup.numViolatingPaths.all
     0.026 ns        timing.setup.WNS.reg2reg
     ...

 

Use the -cmd option to filter metrics by command:

encounter> get_metric -cmd verifyGeometry
verifyGeometry
     3    verify.geom.cell
     0    verify.geom.samenet
     0    verify.geom.wiring
     0    verify.geom.antenna
     0    verify.geom.short
     0    verify.geom.overlap
     3    verify.geom.total

 

Use wildcards to match multiple commands:

encounter> get_metric -cmd verify*
verifyGeometry
     3    verify.geom.cell
     0    verify.geom.samenet
     0    verify.geom.wiring
     0    verify.geom.antenna
     0    verify.geom.short
     0    verify.geom.overlap
     3    verify.geom.total
verifyConnectivity -type all -error 1000 -warning 50
     0    verify.conn
verifyProcessAntenna -reportfile leon.antenna.rpt -error 1000
     0    verify.antenna

 

You can specify the metric name to report. If multiple commands have the same metric it returns the most recent one:

encounter> get_metric timing.setup.WNS.all
     -1.036 ns timing.setup.WNS.all

 

Filter by both command and metric:

encounter> get_metric timing.setup.WNS.all -cmd {optDesign* *setup*}
optDesign -preCts
     0.006 ns   timing.setup.WNS.all
optDesign -postCts
     -1.023 ns timing.setup.WNS.all
optDesign -postCts -hold
     -1.023 ns timing.setup.WNS.all
optDesign -postRoute
     -1.036 ns timing.setup.WNS.all
optDesign -postRoute -hold
     -1.036 ns timing.setup.WNS.all

 

If you want to format your own standard QoR report, the -tcl and -value options are used to read the data directly into Tcl lists/values you can write out in any style you choose. Below is an example of using the -tcl option:

encounter> get_metric design.* -tcl
{design.numStandardCell 34726} {design.numNet 35327} {design.numFloatBlock 0} {design.numFixedBlock 4} {design.numSingleRowCell 34726} {design.numDoubleRowCell 0} {design.numMultiRowCell 0} {design.numIoInst 0} {design.numFixedIo 0} {design.numFloatIo 0} {design.numTerm 156584} {design.numTermPerNet 4.43} {design.util 40.547 %} {design.pinDensity 0.138}

 

Use the -value option to return only the metric's value. Here I assign it to a variable:

encounter> set totalGeomViols [get_metric verify.geom.total -value]
  3

 

Lastly, use the following to report metrics for all the commands run:

encounter> get_metric -cmd *
placeDesign
     34726           design.numStandardCell
     35327           design.numNet
...
optDesign -preCts
     0.006 ns   timing.setup.WNS.all
     0.000 ns   timing.setup.TNS.all
...
clockDesign -specFile DATA/leon.ctstch
     306             clock.clk.numBuffer
     1978.44         clock.clk.areaBuffer
...
optDesign -postCts
     -1.023 ns       timing.setup.WNS.all
     -62.451 ns      timing.setup.TNS.all
...
optDesign -postCts -hold
     -1.023 ns       timing.setup.WNS.all
     -62.490 ns      timing.setup.TNS.all
     12273           timing.setup.numPaths.all
...
optDesign -postRoute
     -1.036 ns       timing.setup.WNS.all
     -61.835 ns      timing.setup.TNS.all
     12273           timing.setup.numPaths.all
...
optDesign -postRoute -hold
     -1.036 ns       timing.setup.WNS.all
     -61.875 ns      timing.setup.TNS.all
...
verifyGeometry
     3    verify.geom.cell
...
verifyConnectivity -type all -error 1000 -warning 50
     0    verify.conn
verifyProcessAntenna -reportfile
leon.antenna.rpt -error 1000
     0    verify.antenna

 

The metrics are stored in the .metric file with both the command and options. So it's useful to use wildcards when specifying the -cmd option.

 

The commands currently supported by get_metric are:

placeDesign
optDesign
timeDesign
clockDesign
verifyGeometry
verifyConnectivity
verifyProcessAntenna
verifyMetalDensity
report_power
addFiller
addWellTap
addEndCap

If you've haven't tried get_metric I encourage you to give a try and let us know what you think. Are there commands currently not supported which you would like to report metrics on?

Brian Wallace

Comments(0)

Leave a Comment


Name
E-mail (will not be published)
Comment
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.