( Post 79 Item 1 ) -------------------------------------------------------
From: markg@ichips.intel.com (Mark Gonzales)
Subject: Synopsys accepting Illegal VHDL Constructs
We have found Synopsys' VHDL compiler accepts a few illegal VHDL-1076
constructs, which is a problem if you are trying to write portable code.
These are bugs/problems that we have found while writing performance
models. They probably don't affect synthesis users.
1) Synopsys does not require that a process drives all elements of a
resolved composite type when it drives any element of that type. [LRM
4.3.1.2, p4-6 para4]. The simulator usually (but we suspect not always)
leaves undriven elements unchanged.
The queueing package (vhdlq.vhd) supplied in the examples is a good
example of this.
2) Synopsys allows a generic parameter's default value to be a function
call (Vantage does not):
entity foo is
generic (bar: unsigned := conv_unsigned (bvtoi (X"0FFFFFFF"), 32);
-- etc.
I can't find anything in the LRM that says whether this is legal or illegal
VHDL, though some of the interpretations hint that this may be legal.
Mark Gonzales markg@ichips.intel.com
Not speaking for: Intel Corp. (503) 696 4551
( Post 79 Item 2 ) -------------------------------------------------------
> From: Jeff Wolford Re: Post 65 and Post 78 Item 3
>
> It boils down to having "a" and "!a" going into the same gate, thus when
> there is a X on "a", you have a X coming out of the gate, even though
> the simulator COULD know what the value is -:).
>
> I wish there was a option in Synopsys to turn off this feature that
> uses "a" and "!a" to do logic reduction... in most of my cases the
> 1 or 2 gates that it saved does not justify the huge amount of time
> it takes to find this problem, reverse engineer a Synopsys schematic
> to figure out what these signals REALLY are, and then twiddle the HDL
> to get rid of this (Usually a loop of several times)
From: "Terrence.Bygate" <bygate@ncrcol.columbiasc.NCR.COM>
We have seen a similar problem, but I do not believe it is related
to Synopsys using the inverted form of a signal. Our problem occurs
when Synopsys performs optimization on the next state equations. The
problem occurs when there is a signal which goes unknown at some point.
The original next-state equations would not use the signal when it is
not known. The 'optimized' equations use the signal at inappropriate
times (e.g. - it might be used as the input to a mux, so that when it
goes unknown, the output goes unknown).
Now that I think about it, the above example (a Mux), basically takes
a signal and generates an inverted form of the signal for the select. Hmmm.
Our workaround was to gate off the signal, and only allow the signal
through to the next-state equations during periods/times when the original
signal was valid. Then we put a DONT_TOUCH on the gating logic. This
method does require instantiating a gate, but is able to 'transcend' the
different versions of Synopsys.
What would be a good solution? That is not easy to decide. Since RTL
synthesis only deals with one clock edge, it would be difficult to describe
to Synopsys (or any tool) periods during which the signal would not be
valid. You could indicate to NOT use a particular signal in optimization
(or restrict how it is used as indicated in the last post), but then you
may restrict the tool too much. It is not possible at this point to place
DONT_TOUCH's on unmapped instances/signals, so this is not possible, yet.
Terry.
Terrence A. Bygate 803-791-6492 | "A problem is nothing but an
Multiprocessor Systems Business Unit | opportunity dressed in work
NCR Corporation - 3500 Module Development | clothes" -borrowed
|
|
