The user is warned of edge times exceeding a user defined threshold, however, rather than record every long edge, the output only records the worst edge time for each node that produced an edge longer than the threshold time.
In addition the tool may be configured to ignore edge times on certain signals which are known to have long edge times. For example internal nodes in some gates may be disconnected when the gate is in certain valid states. The logic level on these isolated nodes will slowly decay giving rise to a long edge. It is convenient to be able to ignore these legitimate long edge times.
To avoid having to name every single slow node in the design in the list of nodes to be ignored, regular expressions may be used to match any node of whose name matches a particular pattern. For example, all nodes whose names end in ".and.n4" could be specified with a single regular expression. This fits in well with the practice of using standard cells, since every instantiation of the cell will have a similar name and can thus be matched easily using a regular expression.
edges threshold tracefile [ignorefile]
Searching for edges >= 0.5 ns in file test.out (11:06 18/10/95) Looking for ignored signals in test.eignore (14:52 30/10/95) There were 5 nodes with edge times >= 0.5 ns. 1.500 ns ack1 1-u-0 224.500 ns 1.500 ns xmy.xheir.req1 0-u-1 216.500 ns 1.000 ns req2 1-u-0 236.000 ns 1.000 ns ack2 0-u-1 244.000 ns 0.500 ns data1 0-u-1 216.000 nsAs can be seen, the output is sorted to show the slowest edge times at the top of the list. For each node with a slow edge, the worst edge time for that node is shown, as is the direction of the edge and the time at which that slow edge occurred. For example the slowest edge on the signal ack1 was a falling edge (from '1' to undefined to '0') and it reached the '0' state 224.5 ns into the trace.
The regular expressions used are full Perl regular expressions and are thus very powerful. Some points should be taken into consideration:
;Example edges ignore file ;Anything ending in .n[digit] or .p[digit] \.[np]\d$ ;the xtest1.di bus ^xtest1\.di\[
For the purposes of this program, the edge time is defined to be the time between the signal leaving one defined state and entering another, as shown in the diagram. The logic thresholds and consequently the undefined region are determined as part of the TimeMill® process. The edges tool is only able to observe whether a signal is '1', undefined or '0' and the times at which it changes state.
The TimeMill® trace file sometimes shows a signal changing state directly from one defined level to the other, without passing through the undefined state. This occurs where the transition was too fast to be observed at the resolution at which TimeMill® was run. Such transitions are regarded as being instantaneous and will therefore not appear in the edge time analysis. For suitable edge time checking to be possible it is necessary to select a resolution for TimeMill® commensurate with being able to observe the expected edge times.
Sometimes TimeMill® produces 2 statements of the state of a particular signal without any change between them. The duplicate state indications are ignored since they would otherwise compromise the edge time calculations.
Some signals may be observed to move from one defined state into the undefined state and then back to the same defined state. These transitions are not included in the edge time analysis.
Any edges that start at the begininning of the simulation and pass through the undefined state to a defined state are ignored since they reflect the initialisation of the simulator rather than a valid signal transition.
This software was developed as part of the OMI HORN
project at the University
of Manchester Department of Computer Science, funded as part of
the European Union ESPRIT initiative (project number 7249).