My girlfriend & I were quite happy to welcome 43 adults & 31 children to
my farm on Earth Day. We got a mix of DEC, Raytheon, Cabletron, Draper
people for users plus ViewLogic, Exemplar, Mentor, Chronologics (and even a
Cadence guy!) for EDA types. Although I made it a point to phone the local
office the day before to make them feel welcome, no Synopsys people came.
One postive effect was a lamb's life was saved. It's bad news when a mama
sheep gives birth to 3 lambs because she can't produce enough milk to feed
all three. As a result, mama will single out the smallest (the runt) and
starve it to death so the remaining two can survive. During the Earth Day
tours I found a newborn triplet w/ runt. I was sad because I had to leave
in two days & therefore couldn't bottle feed her (the runt) for the first
few weeks until she could eat grass. While the most of the lambs were
jumping & playful, she moved very slowly from dehydration & starvation.
Experience told me my poor little Auschwitz lamb was about 18 hours from
death. Unexpectedly, Scott Winick, a sales manager for Exemplar, and his
wife who had a newborn child of their own, volunteered to bottle feed the
runt for the needed 4 - 6 weeks! ("Hey, we already have to get up every
three hours to feed one baby; what extra trouble is it to feed two?")
When my girlfriend found out she did the happy crying thing because it was
so much the "right thing to do." And at PLD Con '95 I enjoyed watching the
surprize on Ewald Detjens' face (the CEO of Exemplar) when I told him that
my goats "Aart" and "Harvey" now have a runt lamb friend named "Ewald"!
- John Cooley
the ESNUG guy
( ESNUG 217 Item 1 ) ---------------------------------------------- [5/3/95]
Subject: (ESNUG 216 #1) Buffer Insertion Script From SNUG '95
> buf.ss ... This dc_shell script adds buffers to an input port. By calling
> it multiple times you can build a balanced buffer tree, with complete
> control over the type and number of buffers at each level.
From: eric@xenon.chromatic.com (Eric Baden)
John,
That is the most ridiculous thing I have practically ever seen. I'll bet
you could have done it by hand and gotten it right many, many, times, before
figuring this out! Just because something is automated doesn't make it
better, or even good.
- Eric Baden
Chromatic
---- ---- ---- ----
From: sharp@xilinx.com (Steve Sharp)
John,
Concerning the buffer insertion script: Thank you!, Thank you!, Thank you!
- Steve Sharp
Xilinx, Inc.
( ESNUG 217 Item 2 ) ---------------------------------------------- [5/3/95]
Subject: (ESNUG 215 #2) Extremely Cheesy Windows Graphics With HDL Advisor
>We have a demo copy of HDL Advisor, and we are very disappointed in the User
>Interface. Maybe you prefer (clunky) windows apps., but I am afraid that we
>are Mac and Motif snobs. HDL Advisor looks like Synopsys paid someone to
>write it for them on a PC...
From: lester@ixtapa.eng.hou.compaq.com (Robert Lester)
Funny you should say this. My understanding from talking to people at
Synopsys is that they did in fact develop the GUI on a Windows 3.1 platform.
- Allan Lester
Compaq Computer Corp
---- ---- ---- ----
From: ann@sioux.apple.com (Ann Nunziata)
Hi John,
Since we last sent our HDL-advisor experiences in ESNUG 215 #2, our Synopsys
FAE informed us that we were missing a Sun patch that repairs the problems
with menus pulling down and damaging the text re-draw underneath. (I don't
know UNIX that well and didn't follow what the FAE did to retrieve the patch
from SUN -- but this might be useful info for your readers.)
The remaining bad news is that Synopsys is planning to change all their tools
to the Windows GUI. Have you heard anything about this? As I understand it,
it will be really slow because Windows will be running on top of X???
- Ann Nunziata
Apple Computer
( ESNUG 217 Item 3 ) ---------------------------------------------- [5/3/95]
Subject: (ESNUG 214 #6 215 #1) Seeking Tools To Translate VHDL To Verilog
>
> Hi, John, -- do you know of any tool that translates VHDL to Verilog?
>
From: peetj@hp7001.ecae.stortek.com (Peet James)
Vender Translation Tools:
About a year and half ago I tried a couple of the then available Verilog to
VHDL translators. All translated the model functionality fine, but timing
info (specify blocks) and comments were ignored. The translators also made
assumptions about mapping from various bit and bit vector specifications
into similar VHDL packaging specs. This made the resulting VHDL models
functionaly usable, but the timing and bit definitions were off. I found
the translation was a good place to start (I was translating a small
library at the time) and saved time -- but I had to heavily hand modify the
resulting VHDL to make it useable. These translators have been updated
several times since then, and some other players have also added new
translators. They might do more now.
Synopsys Library Compiler:
Later when I had to do the same thing on a larger library, I used the Library
Compiler to make functional equivelent VHDL models. Again, the embedded
timing info in the Verilog was lost, but in my case I did not need it (I was
using VHDL only on the RTL side of Synthesis, and Verilog on the gate side).
The resulting VHDL models had some compile problems with various simulators,
due to language interpretation differences, but that was easily fixed. The
bummer was that each time I got an updated version of the new library, I had
to recompile and re-fix all the little language differences. I scripted it
to make it easier, but each time it took a little manual intervention. If I
had to do this with adding timing info each time, it would have been to time
consuming to be usable.
Synopsys Design Compiler:
I have on various occasions, read in Verilog or VHDL RTL code, synthesized,
and then generated structural gates in the other. (In fact Reading in VHDL
and generating Verilog was our standard methodology.) Of course you need to
have purchased all the proper input and output compilers and generators
to do this. Fine if you have all of them like we do, costly if you do not.
Thought inquiring minds might want to know,
- Peet James
StorageTek
P.S.: Wished I could have been there to meet "Aart", "Harvey" & the sheep!
( ESNUG 217 Item 4 ) ---------------------------------------------- [5/3/95]
Subject: (ESNUG 214 #5 215 #5) Specific Reasons Why Synopsys Sucks!
>Someone should hit that user over the head with a two-by-four... I can
>sympathize with the man but comparing ease of use of any synthesis tool with
>a simulator is like comparing a Stealth to a Tonka Truck! Someday, it will
>be simple (and probably obsolete). We'll look back, shake our heads, and
>say "Work? You don't know what work is! I can remember when it used to take
>three days to synthesize 500K ASICs from HDLs!" -- but that day isn't now.
From: rudis@intrinsix.com (Romas Rudis)
John,
Most ESNUG users would agree that Synopsys is a powerfull tool with lots of
features & options. However, it is precisely this flexibility that can solve
difficult synthesis problems which makes it cumbersome to learn and use for
novices (not unlike a finicky sports car). Synthesis tools from Exemplar are
much easier to learn and use in this respect. He has a point in that Synopsys
could make their user interface more friendly like Exemplar's for novices,
while still retaining its features for advanced users.
- Romas P. Rudis
Intrinsix
---- ---- ---- ----
From: myhui@thlayli.newport-beach.ca.us (Michael M.Y. Hui)
John,
It is not difficult for a logic designer to learn how to write high quality
synthesizable code. But it is very hard for even a computer science M.Sc.
w/ ample E.E. CAD tool exposure to learn how to use Design Compiler properly!
The fault is in the inflexable design database, unclear commands, apparently
random (Bill Gates' famous phrase) naming of options & attributes, overly
complex component library system, and of course, bugs galore.
However, let's not bite the hand too harshly that feeds some of us.
1. Synopsys has large market share.
2. Design Compiler is very hard to use.
3. Synopsys Gurus are rare, and they command high salary.
It's like the classic positive feedback scenario where everyone is using
MicroSoft Windows -- even though it's the worst GUI in current use. Why
not keep the status quo, and let those gurus live on?
- Michael M.Y. Hui
Rockwell International
( ESNUG 217 Item 5 ) ---------------------------------------------- [5/3/95]
From: prz@hprnd.rose.hp.com (Paul Zimmer)
Subject: How To Handle Timing Through Bidirectional Ports?
John,
How do other people handle timing through bidirection I/O's -- especially
to/from an external RAM?
I'm doing a design that accesses an external RAM. In the vendor library I'm
using, bidi's are implemented by inst'ing an input pad and an output pad,
and hooking them together in the netlist.
This creates a whole load of bogus loop paths through the bidi's (I don't
generate write data and clock it back in!). disable_timing only works
to disable paths WITHIN a cell, not between cells. set_false_path only
works on path endpoints, so I can't just disable the piece of wire connecting
the input pad's input to the output pad's output.
A doc I retrieved from SolvIt recommended doing set_input_delay and
set_output_delay on the pins of the cells involved.
This works, but it has a nasty side effect. Apparently, this works by
creating a path endpoint on the pins, which breaks the loop. Unfortunately,
you have to do the set_.._delay relative to a clock, which now makes the
timing relative to an IDEAL clock.
Why is this a problem? Because I now cannot cleanly check the path:
clk_pin -> clk_network -> clk_pin of addr reg -> q of addr reg ->
ram_addr pin -> ram addr/data delay -> ram_data (bidi) pin ->
ram_data d input
I'm doing this by budgeting the clk->addr time, then using this budget
plus the RAM access time as the input_delay of the data.
The problem is that clk_network piece. Since it is approx'ly the same
for the addr_reg clock pin and the data_reg clock pin, it really
doesn't add anything to the path (it just shifts the clock cycle over,
but doesn't squeeze it). But, since the output is checked relative
to the propagated clock (other timing checks require propagated clocks),
and the input is (due to the bidi problem) now checked relative
to an ideal clock, the clk_network delay now squeezes the clock cycle.
Dang!
One possibility is to throw the clk_network delay into the budget, but this
will require hand checking of the clock timing when we get back-anno info
(since the budget has to take into account any difference between the two
clock paths).
Another possibility is to create my own synopsys library component for
the RAM, and do timing checks from the chip + RAM level. This would
also solve the WE checking problem (which I'll send as a separate post,
since John likes to restict the postings to a single topic). Will
I need a library compiler license to do this (OOOOOUCH!)?
The whole goal of this would be to turn the path into a clk-clk path. Would
the set..delay stuff to handle the bidi's make this not work anyway?
How do other people handle external RAM timing????
- Paul Zimmer
Hewlett Packard, Roseville
( ESNUG 217 Item 6 ) ---------------------------------------------- [5/3/95]
From: prz@hprnd.rose.hp.com (Paul Zimmer)
Subject: Checking Timing Relative To An Output
John,
How do you check setup/hold timing of your outputs relative to another
output YOU generate?
The specific case (and this must be very common), is a write_enable
strobe to an external RAM. You'd like to somehow create a clock object
at the write_enable output pin, and have synopsys calculate the timing
based on the prop delay. This doesn't appear to be possible.
What I'm doing now is budgeting. I pick a number for the min and
max arrival time of the write_enable signal, check this number,
and create two virtual clocks (one min and on max) based on this number.
The timing is then checked relative to the virtual clocks.
So far, this seems to work. But having to budget the signal timing
when synopsys KNOWS the actual timing is clumsy. Also, I expect it will
quickly become unwieldy when I start checking best-case as well as
worst-case timing. Anybody find a better way?
- Paul Zimmer
Hewlett Packard, Roseville
( ESNUG 217 Networking Section ) ---------------------------------- [5/3/95]
Bay Area ASIC Specialist w/ Verilog, Synopsys, VHDL, C, DFT, DSP, graphics,
MPEG, JTAG, Verif. Please, No Headhunters. Ed Paluch "paluch@netcom.com"
Allentown, PA -- AT&T Bell Laboratories seeks perm Synopsys Applications
Engineer to support our ASIC customers. No Agencies. "mbr@aluxpo.att.com"
|
|
