Because today was such a nice day in Boston's extremely short summers, my
girlfriend & I decided to have lunch at a seafood restuarant known for its
outdoor patio. We noticed they had Maryland softshelled blue crab -- a
creature supposed to be eaten WHOLE (shell and all.) Because we're both
world travelers who take great pride haughtily laughing at those American
provincials who squirm at the thought of eating scary exotic foreign foods
like sushi & the likes, of course, we ordered blue crab for lunch -- even
though neither of us have had it before. Traveler's machismo or no, we both
forced ourselves about halfway through our respective crabs (right around
the point where I was learning more about internal crab anatomy than I ever
really wanted to know) when I blurted: "OK, I won't tell if you won't tell!
This is one *disgusting* meal!" She very quickly agreed, we paid the check
and we very quickly left. Yeeeeeach! :^(
- John Cooley
the ESNUG guy
( ESNUG 191 Item 1 ) ---------------------------------------------- [7/94]
Subject: (ESNUG 189 #4) "Synopsys & Bidirectional I/O"
>I'm having some trouble with bidirectional I/O's. Synopsys tells me that I
>can set all the following commands at once on any bidirectional I/O pin:
>set_load, set_drive, set_input_delay, set_output_delay. When I do this and
>generate a timing report for the pin when used as an input, I see this
>rather large delay at the pin. I assume this is because I've set a load
>because the problem goes away if I remove the load constraint. I was
>just wondering how the rest of the Synopsys community is handling
>bidirectional I/O pins. Setting all the above commands at once sure seems
>contradictory to me. Or is it possible that my library is not modeling
>bidi's correctly?
--- --- ---
From: Ann: ann@sioux.apple.com (Ann Nunziata)
This reminds me of some problems that I had with bidirectional problems.
I'm really unhappy with the way the Synopsys Hot Line told me to handle
bidirectional I/O's. My problem was that I was getting false paths because
DC3.0a insisted on wrapping the output back into the input pin and reporting
an input setup time error to an internal flip flop. DC would keep
reporting this path and not work on the real paths.
The Synopsys Hot Line (we call it the 'lukewarm' line) eventually told me to
set my output delays to the output pin of the output buffer instead. (My
ASIC vendor doesn't have I/O buffers, we have to tie an input and an output
together to make a bidi). While this does remove the false path, I find it
cumbersome. It caused a lot of problems when I tried to get accurate timing
reports for the overall design. I haven't had time to follow up, but I had
to abandon even getting semi-accurate timing for the bidi's. Maybe this
problem is related to the pin loading problem mentioned in ESNUG 189 #4. I too
am interested in learning how others are handling bidi's.
And, is anyone really using Synopsys as a static timing analyzer. I don't
find it accurate.
- Ann Nunziata
Apple
( ESNUG 191 Item 2 ) ---------------------------------------------- [7/94]
From: Brian Arnold <bka@hpesbka.fc.hp.com>
Subject: DC 3.1a Poorly Choosing Gates
John,
One especially obnoxious bug we have been running into with 3.1a is the
frequency which Synopsys is selecting suboptimal cells. What is meant by
this is Synopsys is choosing a cell with seven inputs (for example) when a
more appropriate choice would be a cell with four inputs. The remainder of
the inputs that are not used are then tied off to either logic0 or logic1
depending on the function. These cells that are being selected are specialty
cells with a complex function, not just AND or OR. The synthesized logic is
correct, but the area and delay are both greater.
One method I tried to erradicate this behavior is to insert two additional
cells into the library which represent the functions "0" and "1". When these
cells are included in the library they will be used instead of Synopsys'
internal cells, "logic0" and "logic1". I have attached to each of these cells
a tremendous amount of area so the cost of selecting them is great and
Synopsys would decide to not use a suboptimal cell where it would have to
utilize these large area cells to complete the function. This approach has
seen limited success but still insists on using suboptimal cells and tieing
the unused inputs off.
Has anybody else been dealing with this, and if so what is your solution?
- Brian Arnold
Hewlet-Packard
( ESNUG 191 Item 3 ) ---------------------------------------------- [7/94]
Subject: (ESNUG 190 #2) Any Traps w/ Synopsys Non Linear Delay Model?
>We are considering changing to the non-linear delay model. Is anyone using
>it? Does it yield accurate results (compared to the cmos2 model)? How
>badly does it affect the synthesis (optimization) performance (compared to
>the cmos2 model)?
--- --- ---
From: oren@waterloo.hp.com (Oren Rubinstein)
Yes, we have been using it for some time now. It is VERY accurate, provided
the library has enough points in the table.
The only drawback is the speed, which is 5-10 times slower than with the
linear model, IF you don't do anything about it.
What you can do is put in your script:
compile_use_low_timing_effort = "true"
This speeds up the compilation (almost back to the linear model speed),
at the expense of some accuracy, but it affects only the compilation, not
the reports, so if you end up with some violations, you'll know about them
and you'll be able to run an incremental compile with full precision (i.e.,
compile_use_low_timing_effort = "false")
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
--- --- ---
From: [ No Nothin' ]
Hi John -- No Name, No Address, No Nothin', I suffer from Synopsophobia, the
fear of corporate reprisials by Synopsys.
Now that mainline technology for ASIC is in the .5um range or smaller, the use
of the non-linear delay model is extremely important. At .5 um, capacitance
due to wireload is 3 times greater than the gate input capacitance. (As
opposed to the good old days of 6 um when the ratio was more like 1-to-3 for
metal) As fanout increases, the total wireload increases in a non-linear
fashion, primarily because the routing efficiency starts to degrade as the
size of the net increases.
The biggest "trap" of using a non-linear delay model is to make sure that
the model is not over optimistic compared to the silicon. I was a real
problem at the last ASIC company I worked because there was a tendency to
make the models "too" accurate to account for process variation. From the
logic optimization standpoint, it seems to improve things a lot. The
grotesque inverter chains and delay elements seem to subside somewhat.
- [ No Nothin' ]
( ESNUG 191 Item 4 ) ---------------------------------------------- [7/94]
From: victor@truevision.com (Victor J. Duvanenko)
Subject: Problems With A Special, But Useful Case of Faster Adders
John,
Once is a while a design will require you to do "a(19:0) + b(9:0)". [ That
is, add two numbers of greatly unequal bit lengths. ] Synopsys VHDL headers
(std_logic_arith) immediately expands the smaller addend to be as long as the
longer addend and then infers a 20-bit adder.
I've guessed for a while now that the following implementation may be faster:
sum(9:0) = a(9:0) + b(9:0)
sum(19:10) = a(19:10) + carry_out_from_the_addition_of_the_lower_bits
In other words, a smaller adder and an incrementor.
I just implemented a design that proved that this later implementation is
faster. Synopsys should please change all of the overloaded "+" VHDL
operators to do the "add and increment", since users will get better results.
- Victor J. Duvanenko
Truevision
( ESNUG 191 Item 5 ) ---------------------------------------------- [7/94]
Subject: (ESNUG 190 #3) Synopsys Benchmarking Stance
> And the big surprise is, "No more lawyers!" according to Aart de Geus at the
> EE Times Benchmarking Summit at DAC. The synthesis competition is free to
> publish independent benchmarks without the fear of Synopsys lawyers
> bothering them. Things are looking up. Thank you Synopsys.
--- --- ---
From: ritag@doc.com (Rita Glover)
Is that what Synopsys said? I was there and I didn't catch that. John,
what did you hear?
- Rita Glover
In-Stat, Inc.
[ Editor's Note: It was easy to hear "Open Benchmarking!" if you didn't
listen to *exactly* what Aart was saying. What Aart was reacting to was
a somewhat provocative question from Gabriele Saucier, the CEO of a little
known 18 month old French company, IST, that specializes in taking French
university developed synthesis software into the commercial FPGA synthesis
market. Aart's response was that benchmarking is difficult to do well
and terribly easy to misuse. He's not against being part of benchmarks as
long as they're done correctly. (That is, Synopsys will be a part of the
benchmarks it thinks are fair -- and this will be determined on a case by
case basis.) Plus ca change, plus c'est la meme chose. - John ]
( ESNUG 191 Item 6 ) ---------------------------------------------- [7/94]
From: brown@chdasic.sps.mot.com (Thomas Brown)
Subject: (ESNUG 184 #4) "Removing Backslashes from Verilog Output Files"
Highly Compressed Quoting of Technique Outlined in ESNUG 184 #4:
> 1. Set the io variable "verilogout_no_tri" true before writing out the
> design... 2. Set the compile variable "compile_fix_multiple_port_nets"
> true before compiling the design... 3. ... create a library element using
> the Library Compiler that represents a ground cell in a technology
> library ... add this new library to target_library variable (i.e.
> target_library = target_library + {pwr_gnd.db}) and recompile....
> 4. Set the io variable "read_array_naming_style" to the legal Verilog
> naming style "%s_%d" before reading in the design to get rid of baskslashes.
John,
In regards to ESNUG 184 #4, a technique is presented for getting rid of
tri wires, tran primitives, assign statements, and backslashes from the
verilog netlist created by the HDL Compiler when writing out Verilog
from Synopsys. Two resultant Verilog files are shown not using and using
this technique. I notice that the Verilog file using the technique seems
to have three additional instances ( is this the penalty for using this
technique or am I missing something?).
- Thomas Brown
Motorola
( ESNUG 191 Item 7 ) ---------------------------------------------- [7/94]
From: yinglir@lattice.com (Yingli Ren)
Subject: Synopsys EDIF Schematic Interface to Viewlogic and Valid
John,
When writing out EDIF schematics for Viewdraw and Concept from Synopsys,
some of the edifout_* options do not seem to work. "edif_out_no_array" works
well with netlist_only option set to true, but it does not have much effect
for EDIF schematics. (One work around is to write out a EDIF netlist with
no arrays, and then read back the same design.) Does anyone have a better
way to get rid of the arrays in the EDIF schematics from Synopsys?
- Yingli Ren
Lattice Semiconductor
|
|
