Introduction
This Document describes the "Cone Extraction" - this is an extension to the Database API and bases on the zdb command $db cone.
This is an implementation of a cone extraction algorithm, whose result can be sent to the GUI Cone window. It does not modify the database.
The cone extraction algorithm only returns meaningful results for gate level or block level designs.
Overview
Three major modes are supported:
$db cone options $start $db cone options -startList $list $db cone -reachable options $start $db cone -reachable options -startList $list $db cone -paths options $start $db cone definearccheck zdb cone options
The first mode extracts the Cone Of Influence between the start point and a set of (potential) end points.
The third mode (with -reachable option) computes a list of Reachable Targets.
The fifth mode (with -paths option) performs a Path Extraction between the start point and a set of (potential) end points.
The second and forth mode is equivalent to the first and third, but allows to specify multiple start points (multiple start points are not supported for -paths).
The start point(s) are specified by start-OIDs, either Net, Pin, Port or Inst (Inst is not supported for the -paths mode).
The potential end points (we call them "Targets") are specified by the Target Options below.
The algorithm checks the direction of the traversed pins and ports: inout directions are traversed in both directions and unknown directions are not traversed at all (unknown directions are usually created by the Verilog parser (or other parser) if undefined blocks are instantiated) - but option -unknown2IO changes this behavior.
With the last command global User Defined Arcs for the cone extraction can be defined. To Check the user defined arcs definition the definearccheck command can be used.
The Cone Of Influence
The cone extraction algorithm searches all paths from the given start points to all reachable Targets in O(n) (n is the number of searched nets, maximum all nets in the database). The search result is a list of pin-OIDs and port-OIDs describing all signal paths that form the "Cone". The result list may include some duplicate OIDs.
The Basic Options
|
Perform an input cone extraction (search the signals towards the input). |
|
Perform an output cone extraction; this option is mutually exclusive with
|
|
Ignore all directions while extracting the cone. |
|
Limit the search depth to the given number (number of combinational levels). If the extraction algorithm hits the given limit, then the result is most probably incomplete. Default is no limit. |
|
Don’t cross hierarchy borders: all module Instances will be treated like primitives without a known function, so the search won’t dive down into sub-modules and would not dive up. It speeds up both path- and cone-extraction. If a sub-module pin is reached the cone extraction will continue at the opposite pin. |
|
Empty modules are treated like primitives. If a cone extraction hits a pin of an instance of an empty module then the cone extraction will continue at the opposite pins. With this option the Cone extraction will not dive into empty modules. |
|
Don’t traverse the internals of Modules with a known function but directly jump from an input to output or vice versa. This can significantly speedup the search, but the search will not check any target/exclude flags inside those known Modules. See User Defined Arcs for exceptions. |
|
Normally, unknown pin directions stop the cone extraction, but this option makes them to be handled like IO pins. |
|
If the search was not successful, but the start-point(s) were pins, ports or instances, then add those start point(s) to the result list anyway. |
|
Specify a list of start points instead of just one (see overview). |
|
Exclude hierarchical pins in the result. |
|
Continue tracing the cone through power/ground nets. |
|
If the database was opened from a binfile using |
|
Additionally include net segments in the result. |
|
The callback procedure proc get called with $db and OID as arguments, for each OID in the result. If the function returns '-code continue', the OID is omitted from the result. |
|
Ignore paths through logical gate input if other inputs are connected to constants nets. |
The Target Options
The target options can specify multiple targets, the algorithm uses them as an
OR-combination of end points for the search.
Most target options can be repeated multiple times, but the -targetObj
option
can not.
|
This is a Boolean switch. If specified, then all top-level IO ports are targets (potential end points for the cone extraction). |
|
This is a Boolean switch. If specified, then all dangling nets (only connected to one pin) are targets. |
|
This is a Boolean switch. If specified, then all power/ground nets are targets. |
|
This is a Boolean switch. If specified, then all constant values are targets. |
|
This is a Boolean switch. If specified, then all unconnected pins (of the desired direction) are targets. |
|
This is a Boolean switch. If specified, then all unconnected ports are targets. |
|
This is a Boolean switch. If specified, then all reachable feedback loops are targets. |
|
Specify the given OID as target object (in addition to the targets specified
by other options - but this option can not be repeated).
Supported target object types are: |
|
All flagged objects (with the given 'flag' set) are
targets. Note: these flags are tree-based (not module-based as for
|
|
Specify all instances of the given cell to be targets. It is often used to specify latches - for cone extraction from an arbitrary start point to all latches. |
|
Like -targetCell, but the cellname search is case-insensitive. |
|
Like -targetCell, but a glob-style pattern is used to identify the target cells. |
|
Like -targetCell_glob, but the pattern is case-insensitive. |
|
All flagged instance-objects (with the given 'flag' set) are targets. Note: these flags are module-based (we don’t use the tree-based flat flags here) and therefore match all instance paths that lead to the given instance-object. |
|
All instances of flagged cells (with the given 'flag' set) are targets. Note: the cell flag "undefined" is set by the Verilog parser for undefined module or prim instantiations - this flag can be used here to make them targets. |
|
Like |
|
Like |
|
Like |
The Exclude Options
The exclude options can specify objects that make the algorithm stop searching (without finding a target in a given search branch). If the same object is both a Target and an Exclude object, then the target meaning has priority. Multiple Exclude objects are treated as an OR-combination of (non-successive) end points for the search. Each Exclude option can be repeated multiple times.
|
All instances of the given cell make the algorithm stop searching. It can be used to specify certain modules to be excluded from the cone extraction search. |
|
All instances of cells with this flag set make the algorithm stop searching (analog to the -targetFlaggedCell option). |
|
All instances with this flag set make the algorithm stop searching (analog to the -targetFlaggedInst option). |
|
All pins with this flag set make the algorithm stop searching (analog to the -targetFlaggedInst option). |
|
All ports with this flag set make the algorithm stop searching (analog to the -targetFlaggedCell option). |
|
All nets with this flag set make the algorithm stop searching (analog to the -targetFlaggedPin option). |
|
All flagged objects (with the given 'flag' set) make
the algorithm stop searching (analog to the -targetFlatFlagged option).
Note: these flags are tree-based (not module-based as for
|
|
Ports with a function (e.g. clock, reset, set, select) get flagged
internally and are ignored like |
Path Extraction
The path extraction algorithm searches all paths from the given start point to all reachable Targets and returns the -pathLimit shortest paths.
Internally, this algorithm first computes the Cone Of Influence and then operates on that data. This means, all cone extraction options above apply.
The search result is a list of paths - sorted by path depth (the shortest path is the first). Each path itself is a list of pin-OIDs and port-OIDs describing the signal path, but the first element is an integer (rather than an OID) storing the depth of the path.
More Options for Path Extraction
|
Limit the number of created paths to the given number.
If the extraction algorithm hits the given limit, then only the shortest n
paths are returned.
Default is 100.
If the given limit is 0 then up to 65535 paths are returned. |
|
If only the shortest path is wanted, this option can be issued, to use a faster breadth first algorithm, with a different implementation. Not all options make sense here. For the special case of multiple target nets the option -targetNet can be used multiple times here. |
|
The callback procedure proc gets called with $db and OID as arguments, for each OID in the result paths. If the function returns '-code continue', the OID is omitted from the result path. |
Reachable Targets
This mode is identical to extracting the Cone Of Influence, but the search result is a list of the target OIDs only; that is a list of pin-OIDs and port-OIDs of the end points of the search.
User Defined Arcs
If needed, Arcs for some cells can be defined in a global table. Four commands can be used to maintain this table:
zdb cone cleararc ?$cellName? zdb cone definearc $cellname $enterport $leaveportList ... zdb cone invertarc ?$cellName? $db cone definearccheck
cleararc clears the whole table or one given cell. definearc adds entries to the table. Multiple $enterport / $leaveportList pairs can be used in one definearc command. Use an empty $leaveportList to block arcs from the given $enterport. invertarc may be used to use all arcs which are not defined. The table is asked only if the cone -checkArcs option is used. The definearccheck command looks whether all or no ports are defined in the table. For Cells with only partial definitions a warning is issued, because missing port are treated like a complete arc to all possible ports.
Cone to Power/Ground
For a given start pin the coneToPG command tries to search a path to power ground nets through transistor devices.
With the -opposite option the opposite pin of $startPin is used.
With the -limit option only path with limited length are returned.
With the -connlimit option nets with more than the given number of connections are ignored.
With the -only option only supply nets with the given flag are targets.
With the -excludeFlaggedInst instances flagged with the given flag are not allowed in the result.
With the -excludeFlaggedCell instances of cells flagged with the given flag are not allowed in the result.
$db coneToPG $startPin ?-opposite? ?-limit num? ?-connlimit num? ?-only power|ground|negpower? ?-excludeFlaggedCell flag? ?-excludeFlaggedInst flag?