( Post 78 Item 1 ) --------------------------------------------------------
From: rm@hoy.nsc.com (Robert Marshall)
Subject: muxes (Post 75 Item 2)
>From: dan@emulex.com (Dan Pinvidic)
>
>Question: Can a verilog description of a 2-1 mux which has one data
>input grounded get mapped to a 2-1 mux from the library. All efforts result
>in a nor gate controlling EMO. EMO and FMO must have matched path delays.
>Compiled with flatten & structure set to "false", -map_effort low fails.
>I really don't want to instantiate a mux.
As far as I am aware, Synopsys will always act to remove logic on
"supply" inputs. Only suggestion I have for you is that, depending
on how you organise your design flow, you might want to replace your
1'b0 case default with a signal name, (e.g. "bogus_input"?) and make
"bogus_input" an input port to the module. Set "bogus_input" to 1'b0
in the module above (or higher). If you then synthesise each module
seperately, you'll get your mux.
Robert Marshall, Telecom Design Group,
National Semiconductor (UK), Greenock, Scotland
( Post 78 Item 2 ) --------------------------------------------------------
From: venus!jgais (J.Gaisler)
Subject: paranthesis bug
I've been using Synopsys VSS for about a year know and would like to join
the ESNUG. Have so far only found one bug in the simulator, concerning the
CASE statement. It goes like this :
While this following statement is valid:
CASE some_signal IS ...
The following doesn't seem to be valid:
CASE (some_signal) IS ...
Synopsys doesn't seem to like the paranthesis around the expression, which
according the reference manual is legal.
Regards, Jiri Gaisler
- - - - - - - - - - - - - - - - - - - - - - -
Editor's Note:
Jiri, your contribution begs the question of: "Exactly what are you
using as "some_signal" when you see this problem ? Is it an individual
signal?, a vector?, a constant?, a complex expression?"
-John
( Post 78 Item 3 ) --------------------------------------------------------
From: Jeff Wolford
Subject: Re: Posting 65 (Synopsys use of unknowns and inverse pairs)
Can use my name, leave my employer's name and my email address out...
I have seen this too... Since I deal mostly with state-machines I see
it in the next-state equations.
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 -:).
However, it is never the case of just having a inverter or a "bubble"
on one of the inputs and "a" going to both inputs... it usually spans
several gate levels, thus it would take a VERY sophisticated simulator
to carry the equation/relationship of a signal forward in time...
Synopsys seems to do this when it wants to "negate" the use of the
a signal in a equation for a certain period of time.
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)
The residual problem with this is that every time you change the HDL
code, you get in a new version of the synopsys library or you try out
the newest change level of Synopsys, this problem can come back...
- Jeff Wolford
|
|
