Happy New Year, ESNUG readers!
I usually don't like to "cc" an entire prior post when replies to it
are going out on ESNUG, but since many of us (including myself) have
been away on vacation for the past 2-3 weeks, I'm "cc-ing" Post 97
Item 3 so we can all understand what the replies are talking about.
- John Cooley
ESNUG Moderator
( Post 98 Item 1 ) -------------------------------------------------------
Re: Post 97 Item 3 Confusion On What Does What In Compiling
>Can somebody explain briefly what is the difference between:
>
> 1. 'minimization' option in the 'set_flatten' command.
> 2. 'boolean optimization' option in the 'set_structure' command.
> 3. if 'compile' is done with neither 'set_flatten' nor 'set_structure',
> Synopsys' default is to do none of 1 & 2 above. What does Synopsys
> really do in terms of synthesising a circuit implementation from
> the HDL code?
>
>We found that when synthesizing a CASE statement in Verilog, with setup 3
>above,
>
> case (muxsel) //synopsys full_case parallel_case
> 00001 : databus = out0;
> 00010 : databus = out1;
> 00100 : databus = out2;
> 01000 : databus = out3;
> 10000 : databus = out4;
> endcase
>
>Synopsys makes an encoder which encodes 'muxsel' value to some 3-bit
>equivalent address and then a decoder to 're-decode' it into 5 separate
>select lines before going into AND-OR mux structure. This becomes redundant
>logic and upsets the timing we want. Of course it eats up your silicon too.
>
>So it seems that without the options, Synopsys just translate the HDL
>directly to logic. At one stage, we were not aware of the effects of these
>2 options and said Synopsys is rubbish.
>
>We made a 'work around' which uses :
>
> casex (muxsel) //synopsys full_case parallel_case
> xxxx1 : databus = out0;
> xxx1x : databus = out1;
> xx1xx : databus = out2;
> x1xxx : databus = out3;
> 1xxxx : databus = out4;
> endcase
>
>and we get what we want even if option 1 & 2 above are not used.
>So beware folks. Anyway, I would welcome some theoretical explanations.
>
>Kenny Chow
>Ericsson Australia Pty. Ltd.
>T/HGH APZ Hardware Design
---------------------------------------------------------------------
From: [ A Contributor Who Wishes To Remain Anonymous ]
I have been struggling to determine how the Synopsys tools handle
optimization of don't cares for some time now. I have receieved
conflicting responses from Synopsys on the questions that I ask
and have found peculiarities in the way the tools operate.
I think that the problem you have encountered relates to the way HDL
compiler handles logical don't care situations. I think that it has
nothing to do with the compile options used (from what I can tell by
experimentation).
I am assuming that by placing the full_case HDL Compiler directive on the
case statement which is not fully defined, you wish to have all the undefined
cases treated as logical don't cares. However, HDL Compiler does not
interpret it that way. The HDL Compiler interprets it to mean that the
output is assigned a logic0 for all the undefined case conditions. This
function which you did not define is what is causing the extra
circuitry to be built, which is not wrong, but is a sub-optimal optimization
of the don't care set.
The only way around it is to recode the circuit as you have shown using the
casex expression. Since the intended function of the first code fragment is
not being passed to Design Compiler by the HDL Compiler, there is nothing
you can do with the compile options to change it.
Unfortunately, this is not so easy for complex case expressions. I think
this is a bug that Synopsys needs to fix.
I have already logged the problem with their hotline some time ago. When
they finally got back to me, they suggested that I should recode the circuit
to get the right logic. I told them that was unacceptable, and asked them
to look at it again. I have had no response since then.
- - - - - - - - - - - - - - - - - - - - - - -
From: "Jan Decaluwe" <jand@easics.be>
Your example touches the general question of synthesis tool usage:
what to expect from the tool and what not ? My answer to this is
that, for the best results, you should give the tool as much
information as you have, through your HDL code.
It is not very difficult to make a synthesis tool behave "stupidly",
e.g when you synthezise something like
z = a - a;
you will probably end up with some logic.
Of course, no one will write it like that in this case. However, most
of the times it's much more subtle, as in your example. By specifying
don't cares instead of zeros in the case branches, you explicitly
give the tool much more information. You can see this by writing out
the boolean equations (or draw Karnaugh maps).
Of course, by playing with options and by using CPU-time, it is
sometimes possible to finally get the results you expect. However,
the better way is make sure you get what you want through your HDL
coding style.
For example, there is a nice Verilog coding style which expresses
even more clearly what you want, without having to rely on explicit
dont'cares:
case (TRUE) // synopsys parallel_case full_case
muxsel[0]: databus = out0;
muxsel[1]: databus = out1;
muxsel[2]: databus = out2;
muxsel[3]: databus = out3;
muxsel[4]: databus = out4;
endcase
Jan Decaluwe, EASICS, Belgium
( Post 98 Networking Section ) -----------------------------------------
AMDAHL Corp, Fremont, CA needs 8 experienced Verilog and Synopsys users for
Open System design. FAX to: (510) 770 0493 or E-mail: denny@key.amdahl.com
|
|
