( Post 74 Item 1 ) --------------------------------------------------------
From: landman@xpoint.com (Howard Landman)
Subject: duplicate timing arcs in 3.0 beta1 Library Compiler
To: hotline@synopsys.com
Cc: jcooley@sequoia.com
SUMMARY: Errors "LBDB-242" and "DBVH-4" indicate you should examine
the timing_sense in your library.
In several cells in the Crosspoint library (for example XOR gates
and MUXes), there are "non_unate" timing arcs which are actually
the union of a "negative_unate" arc and a "positive_unate" arc
which have different timing. In 2.2b this was OK (except that
it generated warnings during "write_lib -f vhdl"), but now it
gets warnings even in Library Compiler itself. I would like to
argue that this construct is natural and correct, and should be
acceptable to (and correctly handled in) all of the tools.
An example (from a half-adder cell sum output):
pin (S) {
direction : output ;
function : " ( A * ( ! B ) ) + ( B * ( ! A ) ) " ;
timing () {
related_pin : "A" ;
timing_sense : positive_unate ;
intrinsic_rise : 1.9441 ;
intrinsic_fall : 2.335 ;
rise_resistance : 0.29765 ;
fall_resistance : 0.14442 ;
slope_rise : 0 ;
slope_fall : 0.2586 ;
}
timing () {
related_pin : "A" ;
timing_sense : negative_unate ;
intrinsic_rise : 2.283 ;
intrinsic_fall : 2.816 ;
rise_resistance : 0.29763 ;
fall_resistance : 0.14426 ;
slope_rise : 0.2477 ;
slope_fall : 0.0121 ;
}
...
}
Splitting the arc this way provides useful information to design_compiler,
and allows more accurate timing analysis. It's quite clear that these two
arcs are completely independent due to their opposite timing_sense: there's
no way they could ever be in conflict with each other. However, this cell
gets the following warning message from read_lib:
Warning: Line 5326, This timing arc (for the pin 'S') has the same timing_type
and related_pin set as the timing arc on line 5316. (LBDB-242)
The test here apparently fails to check whether the timing senses overlap
before reporting a warning. All pairs of timing senses overlap EXCEPT that
positive_unate does not overlap negative_unate:
POS NON NEG
POS Yes Yes No
NON Yes Yes Yes Table 1: Do two timing_senses overlap?
NEG No Yes Yes
Essentially, the conceptual error in the current tool is equivalent to assuming
that this table contains all Yes answers. However, we can see from this that:
A. The most timing arcs it ever makes sense to have is 2, and
B. It only makes sense to have 2 timing arcs if one is positive_unate and the
other is negative_unate; otherwise, only one timing arc should be allowed.
Later, during write_lib -f vhdl, I get:
Warning: The pin 'S' on cell 'HA1' has duplicate timing arcs.
Only one of them is used. (DBVH-4)
This warning is OK if it reflects a real limitation in VHDL translation.
However, it seems to me that it is possible to write VHDL models which
correctly embody the split-arc timing as given. Since this timing is more
accurate than any averaged or worst-cased model, Synopsys should endeavor
to support it. This will probably require enhancements to VHDL library
generation, not just tweaking the warning test.
Howard A. Landman
Sr. Member of Technical Staff
Crosspoint Solutions, Inc.
landman@xpoint.com
408 988-1584
|
|
