( ESNUG 176 Item 1 ) ---------------------------------------------- [2/9/93]

Subject: Testbenches
From: bandaru@en.ecn.purdue.edu (Krish Bandaru)

It's amazing what designers can do with this language VHDL and the best
thing about it is that things like test benches are written in the same 
language as the design model and thus completely compatible.

  - Krish Bandaru
    Purdue

                            ---   ---   ---

From: jcooley@world.std.com (John Cooley)

I'm curious; why can't one write testbenches in *any* HDL one's using to
design hardware in?  I've heard this claim about VHDL and always wondered
about it because I know quite a few people who've written testbenches
in Verilog for quite some time now.  I've also written testbenches for
my own designs years before using Verilog.

Am I missing something here?  Why is this considered so amazing?  Writing
testbenches is a programming technique that's fairly independent of either
Verilog or VHDL (or even in C for that matter.)

  - John Cooley
    the ESNUG guy

                            ---   ---   ---

From: gsmith@softsmiths.oz.au (Geoffrey J Smith)

I agree totally.  The "general technique" referred to as a testbench in VHDL
is independent of the language. I first saw it used in 1985 in a C language
based simulation environment. It's a great technique but it isn't special to
VHDL -- you can do the similar things in C, C++, Verilog or VHDL.  I guess
the good thing that VHDL has done is give the technique a catchy name.
 
  - Geoff Smith
    SoftSmiths Pty. Ltd.


( ESNUG 176 Item 2 ) ---------------------------------------------- [2/9/93]

Subject: (ESNUG 175 #6) "Synopsys 3.0c Dislikes Making Clocking Networks Now"

>Hello, John.  I am having problems with the balance_buffer command.  I have
>a design in which different clock nets have to be buffered.  The Design
>Compiler processes the circuit for a very short while...   But
>when I inspect the design, I notice that nothing has changed! - massive
>fanout violations everywhere and no buffers at all were inserted!

                            ---   ---   ---

From: jmcgoveran@aol.com (Jerry McGoveran)

If you have no buffers already existing in the design you run balance_buffers
on, Synopsys 3.0c apparently will not insert them for you.  You don't say if
you instatniated buffers and/or dont_touch'ed the network.  A dont_touch, of
course would prevent Synopsys from having any effect.  The balance_buffer
command is new for 3.0b and may have been modified in 3.0c.  I had to

          "set_drive drive_of(a weak device) input_port_name"

and re-compile the blocks in question in order to make Synopsys buffer things
up properly.  I suggest you try that followed by the balance_buffer command
as before.

 - Jerry McGoveran
   McGoveran Engineering Design

                            ---   ---   ---

From: uunet!fmicos!splinter!flieder (Jeff Flieder)

John,  I have also tried using the balance_buffer command in 3.0c and have
found it to be a pretty lame attempt by Synopsys at clock tree synthesis.  I
did get the command to do a little more than Mr. Paolini did, but not much
better.  I tried numerous combinations of set_drive, set_driving_cell,
set_max_fanout, and set_max_capacitance commands to try and infer the tree
that I wanted.  I also tried numerous dont_use and preferred attributes to
try and get the cells that I wanted, but Design_Compiler just seemed to do
whatever the hell it wanted to do, with little regard for my stated goals.
I did usually get some sort of clock tree, just not a very well balanced one,
and not one with the tree structure that I was looking for.

We finally decided to just analyze our circuits and build our own clock trees.
We then have a perl script that routes the clock tree branches around the
design.  We are hoping, however, that Synopsys will someday understand clock
tree synthesis so that we can abandon our post-processing methodology.

  - Jeff Flieder
    Ford Microelectronics


( ESNUG 176 Item 3 ) ---------------------------------------------- [2/9/93]

From: david@subasic.sciatl.com (David Burleson)
Subject: (ESNUG 173 #5 174 #2 175 #3) - "Xilinx synthesis with Synopsys"

>>We spent a couple of weeks recently taking a design that had been compiled
>>with Design Compiler and recompiling (from the source) with FPGA compiler.
>>What we got after a lot of pain was an even larger, slower design!
>
>I have done some 20 and 40 MHz designs as well as some DSP designs which
>include many arithmetic functions and found FPGA compiler to perform well.
>I believe FPGA compiler to be a more mature product than what Mr. Burleson
>found it to be.

Actually, we suspected our results were due to incorrectly using the product.
So we sent the design to Synopsys and Xilinx about two months ago.  They send
us status updates every now and then but they are getting the same results we
did.  Because of this I don't think our results were due to anything we did
wrong.

The difference between the results you see and what we are seeing may be due
to the structure of your designs.  Our designs tend to be control oriented
with lots irregular structures and counters and adders that are not nice
sizes (33 bits, etc).  FPGA compiler likes counters and adders that are powers
of 2 (2, 4, 8, 16, 32).  I don't know if the designs you are implementing
have more regular structures.

>We have several designs which utilize 90% of an XC4010.  These same designs
>were approximately the same size when done through the schematic entry
>method with a Xilinx library.

This seems hard to believe since even FPGA compiler is not able to use all the
features of the Xilinx CLB architecture.  I have to wonder how you were
creating your schematics.

  - David Burleson
    Scientific Atlanta


( ESNUG 176 Item 4 ) ---------------------------------------------- [2/9/93]

Subject: (ESNUG 175 #4)  Want More "Don't Care" Options In Synthesis

>John, I'm compiling behavioral verilog through Synopsys and would like to
>specify the output of a case statement as "don't care".  (Synopsys doesn't
>seem to recognize the 1'hx or any other form of don't care.)  When I run the
>same logic through Synopsys in a PLA format it works fine, but I'd like
>to be able to do it in verilog.  Here's an example of what I'd like to do:
>
>   reg [3:0] a;     reg out;
>
>   case (a) // full_case parallel_case
>           4'h5, 4'hc :  out = 1'h1;
>     4'h8, 4'h9, 4'hd :  out = 1'hx;  // specified don't care conditions
>              default :  out = 1'h0;
>   endcase

                            ---   ---   ---

From: uunet!telenet!maxi!dtozer (David Tozer)

John, thanks for the good work running ESNUG. I have learned many useful
ideas/work-arounds from you and the contributors.

In ESNUG 175 Item 4, Andrew Tao asks about synthesizing don't care conditions.

I compiled the sample code using the Synopsys class.db library and got the
following netlist:

  module test ( a, out );
  input  [3:0] a;
  output out;
      wire n93, n94;
      AN3 U30 ( .A(n93), .B(n94), .C(a[2]), .Z(out) );
      EO U31 ( .A(a[0]), .B(a[3]), .Z(n93) );
      IVA U32 ( .A(a[1]), .Z(n94) );
  endmodule

In behavioral Verilog, this is the equation:

           out = (!a[1] && a[2] && (a[0] ^ a[3]));

The Design Compiler was free to assign either "1" or "0" to the variable "out"
for the inputs 'h8, 'h9 and 'hd, and chose "0" for the best logic reduction.
Synopsys is not (I hope) going to produce logic which has an output which
really is "x", ie an undefined output for a defined input!

Also, a couple of pointers to the user's Verilog source code.  The comment
in the first line of the case statement should start with the word "synopsys"
so the Design Compiler reads the comment:

         case (a) // synopsys full_case parallel_case
                     ^^^^^^^^
The HDL Compiler gives a warning related to the "1'hx" used to declare the
don't care condition in the case statement.  Since the variable "out" is a
single bit, a better way to describe the don't care is "1'bx":

    4'h8, 4'h9, 4'hd : out = 1'bx; // specified don't care conditions
                               ^
  - Dave Tozer
    Alcatel Data Networks

                            ---   ---   ---

From: mulligan@brooktree.com (danny mulligan)

John, The set_flatten command is what is required here.  I've run a small
experiment with the example given and I can get it to take advantage
of the X as don't cares.

If I do ...

    dc_shell> read -f verilog esnug.v
    dc_shell> compile
    dc_shell> report_area

then Synopsys treats the X's as 0's I get an area of 5.0 gates.  If I use
the set_flatten command ...

    dc_shell> read -f verilog esnug.v
    dc_shell> set_flatten true
    dc_shell> compile
    dc_shell> report_area

then Synopsys takes advantage of the X's as don't cares and I get an area
of 3.5 gates.

Of course there are lots of implications / complications with using the
set_flatten command - if I had synthesized a carry look ahead adder then
the set_flatten command would eliminate the carry look ahead logic and
optimize my logic to a ripple adder.

  - Danny Mulligan
    Brooktree Corp.

                            ---   ---   ---

From: [Synopsys R&D] and [Synopsys Corporate Applications Engineering]

Hi John,

Andrew Tao's request to use "don't care" states is a valid one.  By utilizing
don't care states in the example design provided by Andrew, the area drops
from 6 gates to 3 gates in area.

In order to have Verilog and VHDL Compiler use dont_care states during HDL
synthesis and optimization, the Design Compler command "set_flatten"
command must be set on the design prior to "compile".

It turns out that PLAs are already "flattened" so their don't cares are
always used.

  - [Synopsys R&D] and [Synopsys Corporate Applications Engineering]


( ESNUG 176 Item 5 ) ---------------------------------------------- [2/9/93]

Subject: (ESNUG 172 #4) "Seeking A State Machine Rule-of-Thumb"

> Does anyone have a "rule-of-thumb" for the maximum size of a state machine
> before Synopsys gags?  Issues of readability aside, I was just wondering
> what size state machine causes compile times become excessive.

                            ---   ---   ---

From: sgolson@trilobyte.com (Steve Golson)

The answer is "it depends".  It mainly depends on how you code your state
machine.  Properly written HDL code can easily support state machines
with ~100 states.  I don't think there is any inherent limit.

If you want to use the Synopsys FSM tools, keep in mind that your design
*must* be capable of being flattened into a two-level representation.

  - Steve Golson
    Trilobyte Systems

 [ Editor's Note: Steve is going to giving a presentation on state machine
   design in Verilog and VHDL at this upcoming SNUG '94.  - John ]

                            ---   ---   ---

From: jcooley@world.std.com (John Cooley)

Back in the 1.3 and early 2.0 days I worked on a project that had made the
mistake of counting on the Synopsys FSM compiler to save at least 15% on our
gate counts.  (I had a boss who said that's what the Synopsys people claimed
as "average" area savings from using FSM.)  We were doing an awful lot of
state machines and felt that is was impossible for our simple 1,2,3 state
assignment to be anywhere near optimal.  But not to worry, FSM will do the
job!  (After all, FSM compiler was supposed to have all sorts of proprietary
algorithms that should beat any mere mortal's attempt at state assignments.)

But, when I ran my state machines through Design Compiler in one case and
through FSM compiler in the other case, using the same constraints, the gate
counts for the FSM generated designs were typically 30-50% larger!  (I
thought: "Isn't this theoretically impossible?  If I happened to get the
perfect state assignment, my gate count should match the Design Compiler gate
count.  If my orginal assignment wasn't perfect, then FSM should always be
saving gates with a much better state assignment.")  In one case I even found
an example where FSM compiler made a design 100% larger than from its Design
Compiler equivalent!

At the time Synopsys took my 100% larger design, my boss made a lot of noise
about it for a while and we never got a fix to that problem.  Mind you, this
was in the 1.3 and early 2.0 days -- haven't used FSM since then.  It could
be much improved or just as bad as it has always been.

  - John Cooley
    the ESNUG guy


( ESNUG 176 Item 6 ) ---------------------------------------------- [2/9/93]

From: rray@poci.amis.com (Russell L. Ray)
Subject: Synopsys Is Inverter 'Happy'!

John,

We have been anaylzing the buffering that is inserted into designs and have
found that two inverters are used consistently over a single buffer cell.  The
inverter combination has the same area as the single buffer but the buffer is
faster than the inverter combination.

Why does it consistently choose the inverters over the buffer?  And how can
I get it to choose the buffers?

  - Russell L. Ray
    American Microsystems



 Sign up for the DeepChip newsletter.
Email
 Read what EDA tool users really think.


Feedback About Wiretaps ESNUGs SIGN UP! Downloads Trip Reports Advertise

"Relax. This is a discussion. Anything said here is just one engineer's opinion. Email in your dissenting letter and it'll be published, too."
This Web Site Is Modified Every 2-3 Days
Copyright 1991-2024 John Cooley.  All Rights Reserved.
| Contact John Cooley | Webmaster | Legal | Feedback Form |

   !!!     "It's not a BUG,
  /o o\  /  it's a FEATURE!"
 (  >  )
  \ - / 
  _] [_     (jcooley 1991)