( Post 62 Item # 1 ) ------------------------------------------------------
From: jaa@mongoose.ess.harris.com (John Auer)
Re: Post 58 Item # 1
> From: bygate@ncrcol.columbiasc.NCR.COM (Terry Bygate)
>
> Anyway, a gotcha which we have encountered (in Verilog, which I have not
> seen discussed on ESNUG), involves the use of signals which do not always
> have known values. Synopsys does not "understand" invalid/floating inputs
> and it can create a hazard with what is normally considered synchronous
> logic.
#include Verbose_Description
I have encountered a problem which is similar to this; however, this
problem is not specific to VHDL/Verilog. It revolves around the fact
that Synopsys represents every cell's output as a boolean function.
While this is true for the vast number of library cells (with a
little added twist for sequential cells--boolean after a certain
input event), this is not ALWAYS correct. It is analogous to
your problem, since every node in your circuit cannot be
represented by a boolean equation (it isn't always 0 or 1,
sometimes its unknown...) Synopsys is missing one of the
states in digital logic (0, 1, Z, and...X)
My problem was a tristate buffer with dual enable lines (SELECT
and SELECT_BAR). In order for the gate to operate properly (and
not burn up) the selects MUST be complementary (i.e., otherwise
its output is unknown.) However, there is no way to stipulate
this in a boolean equation for the library element. One
"three_state" equation is "(!SELECT) & SELECT_BAR. Basically,
the Synopsys engine thinks the gate is driving for a 00, 10, and
11. But, alas, the gate floats or burns up on two of these three
conditions. Describing the "three_state" equation as "!(SELECT &
!SELECT_BAR)", Synopsys thinks its okay to use 00, 01, or 11 to
tristate the gate. Once again, two out of three are harmful.
In practice, Synopsys will tie SELECT to power (or tie SELECT_BAR
to ground) and use the other input to control the driving/three_state
function. Saves gates, what the hey! :-(
I filed this as a bug (ahem, STAR), and it is considered an
"enhancement request", i.e., it will be fixed if they can find
a clever, albeit, easy solution. I haven't heard anything on
it in many months.
There aren't any pretty solutions, other than having an
"artificial" one-enable three-state buffer, and swapping
in a subcircuit containing a local inverter after optimization
is complete. The gate count suffers, however, since one large
inverter could drive the SELECT_BAR's for a bank of tristates,
instead of each having their own inverter. A similar problem
existed with a 2-to-1 mux with dual select lines. This is left
as a casual exercise for the energetic :-) Your solution to
the problem in the case you discussed is likely the only
way to handle that particular variation.
Hope this sheds a little light on what you were seeing. Maybe
it will be fixed in the next major revision.
John Auer
Harris GASD
jaa@mongoose.ess.harris.com
(OK to use name)
|
|
