Programmatically Capturing Cell Delay In The Encounter Digital Implementation System

A while back we were talking about how to programatically troubleshoot timing violations in Encounter.  That post recieved a lot of good comments (thanks!) but one in particular touched on a point that I've worked on with other users, so I thought to raise it up for visibility here and go more in depth on the topic.  Nataraja G asks:

"how can we get the delay values associated with that cell ? is it possible!"

When I first looked at our CTE-TCL inferface for probing timing programmatically I too thought it would be convenient to capture the delay through a given cell.  Then it would be easy to capture all the instances in a given path with delay greater than a given value, for example.  However, it's a little more complicated than that in practice.  It is possible, however, and choosing the best method depends on what exactly you're looking to achieve.

Let's get right into an example of an actual timing path to see how we might be able to extract information about cell delay programmatically.

In this blog entry I'll be seeking to capture the delay through i0 in this simple reg2reg path that goes through a single buffer:

     +-------------------------------------------------------------+ 
     | Instance |     Arc     |  Cell | Delay | Arrival | Required |
     |          |             |       |       |  Time   |   Time   |
     |----------+-------------+-------+-------+---------+----------|
     | i0       | CK ^        |       |       |   0.000 |    0.309 |
     | i0       | CK ^ -> Q v | DFFX1 | 0.286 |   0.286 |    0.595 | 
     | i1       | A v -> Y v  | BUFX1 | 0.156 |   0.442 |    0.751 | 
     | i2       | D v         | DFFX1 | 0.000 |   0.442 |    0.751 | 
     +-------------------------------------------------------------+

Reporting timing through a given instance

Before going too much further, it's probably worth mentioning the "reportDelayCalculation" command.  It's helpful for asking the tool to write out information about how delay was calculated for a given instance.  Here's an abridged example of what it writes out if we call it:

encounter 1> reportDelayCalculation -from i0/CK -to i0/Q
-------------------------------------------------------------
                           Rise        Fall
-------------------------------------------------------------
Input transition time  : 0.120000 ns 0.120000 ns 
Effective capacitance  : 0.003261 pF 0.003261 pF
Cell delay             : 0.377800 ns 0.286200 ns 
Output transition time : 0.093300 ns 0.079400 ns 
------------------------------------------------------------- 

This is perhaps useful information, but what if we want to do something more programmatic?

Programatically capturing the delay for a portion of a path

The "get_arcs" command can be useful in situations where you want to capture the delay from any point to any point.  In this case

encounter 38> get_arcs -from i0/CK -to i0/Q
0x36

The 0x36 tells us we've caught a "collection" that we can in turn query for more information.  The "report_property" command can be used to list what information we can query for the collection:

encounter 40> report_property [get_arcs -from i0/CK -to i0/Q]   
property                            | value    
-------------------------------------------------
arc_type                            | rising_edge
delta_delay_max_fall                |  
delta_delay_max_rise                |  
delta_delay_min_fall                |  
delta_delay_min_rise                |  
delay_max_fall                      | 0.286
delay_max_rise                      | 0.378
delay_min_fall                      | 0.286
delay_min_rise                      | 0.378
is_cellarc                          | true
is_disabled                         | false
mode                                |  
object_type                         | timing_arc
sdf_cond                            |  
sdf_cond_end                        |  
sdf_cond_start                      |  
sense                               | non_unate
source_pin                          | {...} 
sink_pin                            | {...} 
when                                |

encounter 42> get_property [get_arcs -from i0/CK -to i0/Q] delay_max_fall  
0.286 

With get_arcs, we needed to select from the rising and falling arcs.  If we want to capture the arc that appears in a given timing report for a specific instance, we can capture a timing collection and query its timing_points.  The timing_points are sorted such that we can perform a subtraction of arrival time to determine the delay through any instance.  Here's a proc that finds the delay through a given instance name in a timing collection:

proc user_get_inst_delay {inst_name timing_collection} {
  set timing_points [get_property $timing_collection timing_points]
  set previous_arrival_time 0
  foreach_in_collection timing_point $timing_points {
    set pin [get_property $timing_point pin]
    set pin_name [get_property $pin hierarchical_name]
    set inst [file dirname $pin_name]
    set arrival [get_property $timing_point arrival]
    if {[string match $inst_name $inst]} {
      set cell_delay [expr $arrival - $previous_arrival_time]
    }
    set previous_arrival_time $arrival
  }
  puts "Delay for inst $inst_name is $cell_delay"
}

encounter 63> user_get_inst_delay i1 [report_timing -collection]
Delay for inst i1 is 0.156

We could also write the script such that we find the instances with delay greater than a certain amount and potentially do something with those instances like upsize them.  Here's an example of how the script could be reworked to do that:

proc user_get_inst_delay_greater_than {max_delay timing_collection} {
  set timing_points [get_property $timing_collection timing_points]
  set previous_arrival_time 0
  foreach_in_collection timing_point $timing_points {
    set pin [get_property $timing_point pin]
    set pin_name [get_property $pin hierarchical_name]
    set inst [file dirname $pin_name]
    set arrival [get_property $timing_point arrival]
    set cell_delay [expr $arrival - $previous_arrival_time]
    if {[expr $cell_delay > $max_delay]} {
      puts "Delay for inst $inst is $cell_delay"
    }
    set previous_arrival_time $arrival
  }
}

encounter 62> user_get_inst_delay_greater_than 0.2 [report_timing -collection]
Delay for inst i0 is 0.286

Having the ability to programatically query timing in the physical domain can be a powerful tool.  If you're not that into scripting but you still want to troubleshoot timing you might find our Global Timing Debug utility useful.  It provides a menu-driven way to capture categories of paths with certain characteristics.  For example you could create a category that had all of the paths in the design with more than "n" instances with delay greater than "y".

For more information on programming and timing analysis in Encounter check out the Advanced Timing Tcl Scripting Commands chapter of the Encounter Digital Implementation System Text Command Reference.

Question of the Day: Any tips or tricks related to this you'd like to share?  Any suggestions for improvement?

Robert Dwyer