Subject: ( ESNUG 357 #1 ) Three DW Bugs Affecting 5 Foundation Parts
> Per our voicemails yesterday, here are descriptions of the DesignWare
> bugs that we have recently uncovered. We would like to get the
> information about these bugs distributed as widely as possible within
> our user base. We would like to have them included in the next
> edition of ESNUG, if possible...
>
> - [ Synopsys DW R&D ]
From: David Bishop <david.bishop@kodak.com>
Hi, John,
Please thank the wise man or woman within Synopsys who thought of sending
out those 3 DW bugs on ESNUG. I expect software to have bugs. It's part
of life. What aggravates me is painfully rediscovering these bugs on my
own. My current work involves many DW parts and I know that getting this
note _beforehand_ has probably saved me one or two weeks of debugging.
While I wouldn't want to get swamped in ESNUG with every little nothing
bug that comes up, it's nice to see that there was at least one person
in Synopsys DW R&D who understood the wisdom of widely diseminating in
ESNUG common bugs that impact large portions of their customers. On
behalf of DW users everywhere, I thank you, whoever you are. You're one
very enlightened EDA person in a world of EDA vendors obsessed with
trying to look good.
- David W. Bishop
Eastman Kodak Rochester, NY
P.S. Now, John, what would _really_ be cool would be if you could get
the other groups inside Synopsys (plus Cadence, Avanti, Mentor,
Synplicity, etc.) to do the same bug reporting with their commonly
used tools... You can always dream, can't you? :)
[ Editor's Note: If you're going to the Boston SNUG gathering this
September, you should read Item 5 in this ESNUG post. - John ]
( ESNUG 358 Subjects ) ------------------------------------------- [8/23/00]
Item 1 : Strange Cadence 4.4.3 Virtuoso/Spectre Crashes On HP-UX 10.20
Item 2 : Sun's StarOffice Stupid Hidden File Messes Up Multi-User Install
Item 3 : ( DAC 00 #39 ) The Unisys 1.5 Mgate IBM ASIC PhysOpt Tape-Out
Item 4 : ( ESNUG 355 #18 ) Cheap/Free/Shareware GDS-II Win95/98/NT Viewers
Item 5 : Boston SNUG Hotel Rate Goes Up From $169 To $259 On Wednesday!!!
Item 6 : Customer Resents Cadence Insistance On Using E-mail Support Forms
Item 7 : Synopsys DW PCI Core Doesn't Work For Both FPGA And ASIC Designs!
Item 8 : ( ESNUG 353 #5 ) A Characterization Guy Sells Characterization
Item 9 : ( ESNUG 357 #12 ) Well, At Least Veritools Supports C++ Debugging
Item 10 : ( ESNUG 357 #6 ) A Useful DC Tcl Script To Fix Hold Violations
Item 11 : ( ESNUG 357 #5 ) How To Initialze An Array Of Constant Integers?
Item 12 : ( ESNUG 357 #9 ) Not Wanting Instantiated MUXes In Clock Gating
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 358 Item 1 ) --------------------------------------------- [8/23/00]
Subject: Strange Cadence 4.4.3 Virtuoso/Spectre Crashes On HP-UX 10.20
> We have a problem w/ our Cadence version 4.4.3 on HP workstations (HP-UX
> 10.20). It is not running stable. Very often it crashes w/ the message:
>
> "segmentation fault"
>
> The crash happens unpredictably; particularly w/ Virtuoso (layout editor)
> and Spectre simulation. Anybody got an idea on what might be wrong?
>
> - Ursula Poepperl
> University of Kaiserslautern Kaiserslautern, Germany
From: Edward J Kalenda <ed@kalenda.com>
More information would be helpful. Does the CDS.log file, or the shell
window, have a stack dump? If so, post it. Do you know what is being
done at the time?
Of course, there is always the ever popular "contact customer support".
- Ed Kalenda
---- ---- ---- ---- ---- ---- ----
From: Ursula Poepperl <poepperl@rhrk.uni-kl.de>
Hi, Ed,
There's only a core file which is too large for posting. Essentially the
crash happens by editing the layer properties directly in the layout.
We think that there's a problem with the Xserver of the HP workstations
because using the software with a linux pc as xterminal there is no crash.
> Of course, there is always the ever popular "contact customer support".
Yes, but normally there should be no problem with Cadence tools and HP-UX
10.2. ;-)
- Ursula Poepperl
University of Kaiserslautern Kaiserslautern, Germany
---- ---- ---- ---- ---- ---- ----
From: jdl@user2.teleport.com (Jay Lessert)
Since you're not doing anything bleeding edge, there is a very good chance
your problems will go away if you:
1) Install a recent QSR.
2) Install all the recommended OS patches.
Both available without off Sourcelink, http://sourcelink.cadence.com.
- Jay Lessert Portland, Oregon
---- ---- ---- ---- ---- ---- ----
From: Ursula Poepperl <poepperl@rhrk.uni-kl.de>
Thanks, Jay, but we have already done this. The recent QSR that we can get
is QSR3 and our system administrator has installed all OS patches which are
necessary.
We get our Cadence software from Europractice (software for european
universities) and not directly from Cadence, so we don't have access to the
Sourcelink.
Thanks for your answer. At the moment we solved the problem by using Linux
PCs as Xterminals instead of the HP workstations. Don't ask me why it works
there.
- Ursula Poepperl
University of Kaiserslautern Kaiserslautern, Germany
( ESNUG 358 Item 2 ) --------------------------------------------- [8/23/00]
From: [ The King Of Prussia ]
Subject: Sun's StarOffice Stupid Hidden File Messes Up Multi-User Install
John, keep me anon if you use this.
Have you tried installing Sun's StarOffice?
The download is a single executable file. One runs this file & it installs
the program. However, the default installation is a single user, which
seems a pretty stupid default for any Unix or Unix-like machine. You would
think that Sun would know this!
The installation program creates a file with installation instructions (yes,
the instructions are only there AFTER running the install!) Their install
instructions tell you how to perform a multi-user install. HOWEVER, what
they don't tell you is that the first installation created a HIDDEN FILE in
your home directory which prevents further installations from being run.
What were they thinking at Sun when they created this?
- [ The King Of Prussia ]
( ESNUG 358 Item 3 ) --------------------------------------------- [8/23/00]
Subject: ( DAC 00 #39 ) The Unisys 1.5 Mgate IBM ASIC PhysOpt Tape-Out
> Click on http://www.deepchip.com/items/snug00-18.html and you'll find the
> April 2000 score board of known physical synthesis tape-outs for everyone:
> Magma, Monterey, Cadence PKS, PhysOpt. The data for everyone there, other
> than PhysOpt, still holds true for July 2000. That is, no customer to
> date, has yet to use Magma, Monterey, nor PKS to make a real chip. In the
> PhysOpt table, add another tape-out in April by nVidea (the MV12 chip),
> plus a new PhysOpt user tape-out by Unisys for July. The Unisys chip is
> a 1.5 million gate, 0.18, IBM fab ASIC with three clocks at 100, 133, 200
> Mhz. Ken Merryman of Unisys is the designer. This means that PhysOpt
> now has a total of 10 confirmed customer tape-outs as of July, 2000.
From: Ken Merryman <kenneth.merryman@unisys.com>
Hi, John,
I saw that you referenced my tape-out in the PhysOpt part of your DAC Trip
Report so I thought I'd share with you the details of that tape-out.
Before using PhysOpt, our standard flow for IBM chips at or below 0.5 um
was to rely heavily on floor-planning plus lots of manual placement. On
a single design we have one main backend guy who focuses on manually
floorplanning, manual placement, re-buffering, manual drive strength
adjustment, and doing re-timing in parallel along with the logical
verification. We also have three other guys who (respectively) do clocktree
synthesis, IBM routing, and Einstimer runs. We also have the last guy who
does synthesis (that's me.)
This process was very ECO friendly because the team would retain the same
net names throughout every stage and revision of the design. (We worked
very incrementally, holding registers and I/O constant so we wouldn't have
to rework our clock trees and the placement.) It could easily take 2 to 8
weeks to finish the physical work on a design. After we were done, IBM
would take our design, run their DRCs on it, and fab it.
This methodology generally worked very well for us with 0.5 and 0.25 micron
IBM ASICs, but started choking at 0.18 and 0.12 microns. The usual wire-
rule-based optimization solutions (which didn't account for the higher
percentage of foil delay) were just not adequate starting points in many
cases. Our standard floorplan/re-buffer/re-size flow couldn't close these
0.18 designs. We ran into trouble with the largest ASIC in our ES7000
Enterprise Server design. It was an 0.18, 1.5 million gates, 325,000 cell
instance, 5 clock, 100/200 Mhz mixed latch and flip-flop IBM ASIC. The
physical design team had been trying to solve the last thousand timing
problems for two months while the other ASICs in the chip set were finishing
logical verification. Worst negative slack was still 1.2 nsec (on a 5 nsec
path) and it didn't look like timing closure was going to happen any time
soon.
To summarize our 0.5 to 0.25 um flow:
- basic flow
1.) DC
2.) Internal "Name Retain" Tool
3.) IBM Booledozer
4.) Internal FP
5.) IBM ChipBench
6.) Clocktree
7.) Einstimer
8.) HDP/Proprietary FP used for placement
9.) RC extraction with Chip Edit
- internal design budgeting solution
- Highly Incremental
- Stacks and hierarchical floor-plan of blocks 10-40K instances
(avg. ~250 per design)
- Flat placement
- Synopsys verified that this approach was realistic and consistent
with their recommended CWLM approach.
- NO timing driven layout
- Flow caused many iterations between P&R and synthesis
- 10 - 15 Iterations due to pre-vs-post timing varied wildly
(most we don't go back to DC; once we're in the backend, we
tend to stay in the backend.)
- Manage to hit target performance at cost of delayed schedule
- Required much custom tools and hand tweaking to achieve closure
At that point Synopsys agreed to help us run it through their PhysOpt. It
took us about a month to get a gates-to-gates PhysOpt process up and running
although the majority of our early work was dealing with the lack of IBM
libs and getting file format differences worked out. Since this was a very
new tool, we had to write our own tool to translate IBM's SA12 lib (in IBM
VIM format) to LEF (which is PhysOpt useable.) We used PhysOpt's lef2plib
conversion utility to get the SA12 data into PhysOpt.
I've heard that IBM now gives out SA12 LEF or Synopsys .pdb libs for PhysOpt
(I'm not sure which).
We also had to work out the PhysOpt SA12 fudge factor for IBM's Einstimer.
You have to tweak PhysOpt R & C values to agree with Einstimer because it's
trying to correlate two different timers (PhysOpt's and Einstimer's.) We
had to find the SA12 metal layer "multipliers" ("multipliers" are an
erroneous Synopsys name -- they're actually replacement values for extracted
R's and C's for PhysOpt sorted by metal layer.) PhysOpt has about a dozen
"*_multiplier" variables/commands for the veritical and horizonal R and C
values. To be sure that PhysOpt is using your overrides for R's & C's in
each metal layer, look for (GR-4) and (GR-5) messages in your PhysOpt log:
Information: Using user specified R and C coefficients. (GR-5)
Information: Cap - horizontal: 3.7e-07 vertical: 3.9e-07 (GR-4)
Information: Res - horizontal: 0.0006 vertical: 0.0005 (GR-4)
Otherwise it crafts its own localized RC values. After this calibration,
our PhyOpt timing correlated within 2% of IBM SA12 Einstimer timing.
Synopsys has now automated this calibration process, but when we used
PhysOpt, we had to do it all ourselves.
Also included in our month long PhysOpt ramp-up was some training time
since two of us working on this chip had little experience w/ the physical
design process and the file formats used to exchange data.
We primarily used PhysOpt in single pass "-post_route" mode. We mostly
experimented with different sets of fixed placement since, out of
cautiousness, we did not want to destroy the physical work already done to
the design. Basically we started with a fully placed *flat* design that
our physical design engineer had been struggling with.
Our PhysOpt optimization script was basically:
1. setup libraries, paths etc
2. read_edif
3. read_pdef
4. source the back annotated capacitance file
5. read_sdf
6. report_design
7. source clock script
8. source the top level constraint file
9. physopt -check_only
10. set the capacitance and resistance multipliers
11. report_timing for initial state of the design
12. physopt -post_route -incremental
13. report_timing for results
14. write out the results - pdef, db, EDIF
The PhysOpt compiles ran from 7 to 24 hours and brought our Worst Negative
Slack down to around 200 pico-seconds. We still had a few problems
requiring manual attention mostly caused by our fixed placement directives.
Our lead physical design guy said that the problems left over by PhysOpt
were difficult or impossible to fix. (i.e. His way of saying "PhysOpt did
a really good job".)
To summarize our 0.18 to 0.12 um flow:
- HDP/PhysOpt/HDP
- Top level floor-plan stayed the same
- No regioning required
- Inputs/outputs to PhysOpt: plib, PDEF3, db, SDF, EDIF, and cap files
- Converted VIM/PDEF3/EDIF from HDP to plib/PDEF and back for IBM HDP
- Converter work only required a few simple tweaks
Improvements in our PhysOpt constraints and fixed placement filters let us
tape-out the chip on schedule.
Gotchas
-------
The most important gotcha we ran into with PhysOpt was to NOT do the old
Design Compiler habit of margining and/or slightly over-constraining our
design. In fact, practically all of our PhysOpt issues had something to do
with mis-constraining our design. PhysOpt will do a number of crazy things
if you lie to it or try to get it to do the impossible by overconstraining.
For example, we got burned by IBM's "I/O affinity cells" in PhysOpt. These
IBM cells need to near the chip's I/O cells. Since we didn't constrain the
I/O properly, PhyOpt very naturally moved the "affinity cells" away from
the I/O to make room for other logic. Einstimer complained horribly. Once
we eventually figured out the problem and accurately constrained all our
I/O's in PhysOpt, it then worked like a charm. Most of our flow is hacked
together with our many of own tools mixed with IBM tools. My PhysOpt
interactions were pretty simple; I only used a 50 line script to do all of
its work. I've heard that in the new flow in the IBM design kits, the
required floorplan is generated automatically via some scripts and it takes
into consideration the I/O placement and affinity info, fat wire creation,
filler cells, RLM placement, hole-punching for I/O cells, etc. If this is
true, it should simplify the data transfer from HDP to PhysOpt.
Another PhysOpt constraint-sensitivity example was that we didn't have all
our design's timing exceptions set. This caused PhysOpt to take off into
lala land with very, very long runtimes. The tool was basically going nuts
trying to fix timing on things that didn't need fixing. Once we got our
timing exceptions in, PhysOpt settled down to realistic (>24 hour) runtimes
working on stuff that actually needed work.
We also found that when running the entire ASIC flat in PhysOpt, the run
time seems to be more dependent on the number of timing problems it has to
fix, rather than the size of the design. (Synopsys says for 32-bit
machines, the upper limit for memory usage is 3.8 gbytes; our design was
2.2 to 2.4 gbyte.) Using our standard physical process to get close to the
timing goals then letting PhysOpt finish the job worked well for us.
Although our plan is to decrease our need to do so much manual placement
and increase the work the PhysOpt does.
We also ran a 0.12 micron, 133Mhz - 9 clock design, with a 266 MHz
interface, 170,000 placeable cells and lots of RAM. We tried running this
ASIC flat doing very minimal initial placement like RAMs and I/O's and
found the run times to be excessive (on the order of over 7 days.) That
design started with TNS of 251,000 nsec and 32,546 violating paths and WNS
of 34 ns. After establishing a good starting point with good constraints,
some floor-planning and register placement, the design starts with WNS 6 ns,
TNS 7,200, and 10,000 violating paths. It runs in PhysOpt in a day and a
half to two days and finishes with a few pico-seconds of negative slack
which is better results than our manual process.
Good, *accurate* constraints and a little bit of floorplanning make a *big*
difference in successful PhysOpt runs.
One final gotcha that became apparent after using Phyopt was how it affected
our ability to do a metal-only ECO on our design. Doing the entire ASIC
flat in PhysOpt in a "-incremental -postroute" mode destroys a lot of
hierarchical names. This makes it very difficult to correlate the gates to
source code when doing a manual metal-only ECO -- since once we flatten the
ASIC, we're then forced have to operate on the *entire* ASIC. I know
Synopsys is planning to phase out ECO Compiler, but we still need a solution
to this problem. We typically back-fill unused areas on our chips with
gate array cells so we can do last minute metal-only changes. We need a
PhysOpt "ECO mode" that leaves current cells placed and uses only available
back-filled gate array cells to make the changes. Basically, John, we need
ECO Compiler or its capability added to PhyOpt.
We are currently working on developing our RTL-to-gates process which
includes budgeting and "divide and conquer" hierarchical process for our
larger ASICs.
- Ken Merryman
Unisys Minneapolis, MN
( ESNUG 358 Item 4 ) --------------------------------------------- [8/23/00]
Subject: ( ESNUG 355 #18 ) Cheap/Free/Shareware GDS-II Win95/98/NT Viewers
> Could anyone give me any pointers to GDS file viewer for WIndows95/98/NT?
> Freeware is preffered, but shareware is OK. I know there are commercial
> ones which cost me $500 and up.
>
> - Sonny
From: Michael Stabenfeldt <stabie@jump.net>
John,
I sell a gds2 viewer for $39.00 that runs on linux. Considering it has
loaded & viewed stream files in excess of 400MB on reasonable PC's (450MHz
/256MB Ram) and large stream files (in excess of 2GB) on sun boxes, I think
my customers have thought its a pretty good deal. Sorry, no windows though.
- Mike Stabenfeldt
Stabie-Soft http://www.stabie-soft.com
---- ---- ---- ---- ---- ---- ----
From: Pallab Chatterjee <pdec@earthlink.net>
John,
The only real one I have found that is usable for production work in a PC
environment:
ICEditors - http://www.iceditors.com has a real 12+ year in production
product that works quite well on the PC to large data base sizes - (I have
opened 600MB files on a machine with 384MB ram). Their full editing
version sells for about $3-4K but they have a free download of the product
for eval that is a great view only tool. I have been using the product
since 1987 and have recommended it to about 70+ other users who use it and
love (some are full time offsite layout contractors)- only drawback is it
still uses a "dos" looking GUI - by the polygon data is about the fastest
you have ever seen.
If you are NOT looking for a Free tool but a real production big chip tool
(I have opened up to a 1.3GB gdsii file on a 400MHz PII with 384MB RAM in
under 10 min) with a configurable GUI and documented API - try the Expert
layout editor from Silvaco ( http://www.silvaco.com ). The tool works
great - it auto builds tech files, read existing Cadence tech files, reads
Dracula DRC/LVS decks and has some really cool hierarchy viewing treelists
tools. The tools are 15K+ but it is worth it - especially if you want an
inexpensive debug seat for DRC/LVS/Antenna/ERC for your top level. It
yields better performance on a <$5K PIII system than you can get with
Virtuoso XL on a J5000 or a Sun 4500.
I am an independent consultant; my recommendations are based on using the
tools to assist in 350+ tapeouts in my career - these tools actually work.
- Pallab Chatterjee
P&D Engineering Consultants, Inc. Livermore, CA
---- ---- ---- ---- ---- ---- ----
From: [ Sonny from Japan ]
Hi John,
I am the original poster of the article. I have tried some freewares as
well as try-and-buys after the post. Then I ended up with buying a
commercial one called "SView-PC" sold by a Japanese company. Pls refer to
http://www.astron.co.jp/sviewdata2.html .... no English page ;-(
This software is faster than GDSVU, and is ~$2K for a floating license.
- [ Sonny from Japan ]
( ESNUG 358 Item 5 ) --------------------------------------------- [8/23/00]
From: Joanne Wegener <jwegener@synopsys.com>
Subject: Boston SNUG Hotel Rate Goes Up From $169 To $259 On Wednesday!!!
Hi, John,
I thought you might like to warn your readers that the Boston SNUG hotel
room rate at the Boston Marriott Newton Hotel will go up from $169 per
night to $259 per night after this Wednesday, August 30th. The hotel
reservation phone # is: 1-617-969-1000. For more details, go to our web
page at: http://www.snug-universal.org/boston/boston.htm#travel
Also, Boston SNUG pre-registration closes September 1. The registration
fee is $500 for three full days of sessions, plus two evening events.
How to Register:
1. Web: Complete the Web registration form. Include full payment info.
This is a secure system. All credit card numbers are encrypted.
2. Phone: Call 1-800-344-SNUG. When you call, please have all the
necessary information ready (refer to the web registration form.)
3. FAX: Fill out the registration form, and fax it to SNUG Registration,
Attention: Heidi Michelson, 1-650-584-4987
4. Mail: Fill out the registration form and mail it with your payment to:
Attention: Heidi Michelson
SNUG Registration
700 E. Middlefield Road
Mountain View, CA 94043
You may also register on the day of the conference, but be sure to arrive
early to ensure your registration is processed prior to the conference.
Please bring your credit card for registration payment. Sessions are
filled on a first-come, first-serve basis.
Local Transportation:
The Boston Marriott Newton hotel is a 45 minute cab ride from Logan
International Airport during rush hour. Off hours it will only take 20 - 30
minutes. The cost of cab is $40 - $50. Shuttle service is available for
$20.00 (with US Shuttle). It will take approximately 1 hour and 15 minutes
to get you to the hotel. Reservations are not necessary (but recommended)
from Logan -> Hotel, but ARE necessary from Hotel -> Logan. Please call 8
hours in advance to reserve: US Shuttle Service 800 714 1115 or (local) 617
889 3366.
For traveling within the area there is subway transit called the "T".
There is no hotel shuttle to and from the "T", which is 2 miles from hotel.
You must take a cab which is $6.00. The number for a local cab company
which the hotel uses is: 508 494-1015.
- Joanne Wegener, SNUG Program Coordinator
Synopsys Mountain View, CA
( ESNUG 358 Item 6 ) --------------------------------------------- [8/23/00]
From: "Russell Petersen" <russp@subasic.sciatl.com>
Subject: Customer Resents Cadence Insistance On Using E-mail Support Forms
Hi, John,
About Cadence support: They truly are a pain to use. One thing I abhore
is that they absolutely force me to use their stupid email template
when submitting even the simplest question and refuse to answer me unless
it's filled out correctly. I can't stand that. Synopsys has something
similar on the web they would like you to use I guess, but they don't ever
seem intent on forcing me into it. As long as my emails are clear and
complete Synopsys is usually pretty good about responding ASAP.
- Russell Petersen, ASIC Engineer
Scientific Atlanta Inc. Lawrenceville, GA
( ESNUG 358 Item 7 ) --------------------------------------------- [8/23/00]
From: Angel Ramiro <angel.ramiro@ds2.es>
Subject: Synopsys DW PCI Core Doesn't Work For Both FPGA And ASIC Designs!
Hi, John,
We're looking for a soft PCI master-target core. The idea is to implement
it in Xilinx Virtex, test it, then migrate it to ASIC. The frequency we
need is 33 MHz and the bus width 32 bits. We tried with Synopsys DWPCI.
Unfortunately, we were unable to implement it in the Virtex.
At first I used the constraints files and synthesis scripts provided by
Synopsys, and later I changed the scripts to try different options and
strategies. After a lot of tries, I got, in the best case, a pad-to-setup
slack of -20 ns (after place and route). As for the synthesis software, I
used both FPGA Compiler (Design Compiler for FPGAs) and FPGA Compiler II
(the results were very alike in both cases). It seems there is a lot of
combinational logic at the inputs, and, as you might imagine, I am somewhat
disappointed.
Does anybody know a good PCI soft core that can be implemented in FPGA and
later migrated to ASIC?
- Angel Ramiro
Systems on Silicon, Inc.
( ESNUG 358 Item 8 ) --------------------------------------------- [8/23/00]
Subject: ( ESNUG 353 #5 ) A Characterization Guy Sells Characterization
> Another key area is in achieving concurrent timing/noise closure. While
> we hear stories of success in correlation between the Synopsys frontend
> and backend Avanti tools the bottom line is different estimation, timing,
> and routing engines never will correlate unless they are the same piece
> of code. Sure we will hear of the few cases where it was "close enough".
> Trust me on this one _your_ design will not be one of them.
>
> - [ Tall Thin Dude ]
From: [ "A Small EDA Vendor" ]
John,
Please make me anon.
It should be intuitively obvious that, even if you apply the same .lib or
.tlf source to the end applications, with different delay calculators and
unique interpretations of the data, results will be different. Isn't this
one of the reasons why we're currently seeing sub-180nm closure becoming
increasingly difficult? Do I hear a collective ESNUG "well, du-uhhhh"?
Hence the rush to merged logical/physical construction. My concern about
this head-long rush to yet one more "holy grail" is that timing analysis is
still being performed with simple static abstractions of cell behaviours;
sure, you should get consistent timing results, and you might have fewer
iterations and get to tape-out sooner. But if your library has guardbands
on top of conservatism on top of fudge-factors on top of some arbitrarily
applied bench constant you're leaving ~25% performance on the table. And
yet still paying for it...
> Oh, and that over-constraining you end up doing? Bigger designs? Ever
> thought about the impact on yield? And do you ever have any hold-time
> problems?
And when VDD drops to around 1.2V, IR drop becomes critical (200mV is now
16%), while the input switching/linear region is rarely more than 40-60%
(where we've been using 20-80% for a decade or more). Couple that with an
increase in other non-linearities (driver admittance for one; resistive
shielding for another), and it's clear the consistency and correlation of
different timing calculators is about as likely as Gerry Hsu offering his
wrists to the San Jose D.A. with the words "he's a fair cop, guv, it was
me what done the deed".
Now (and here's my caveat and disclosure) I'm a long-time characterization
guy, working for a company with the very strong belief that these dynamic,
instance-specific behaviours force the requirement that timing calculation
be performed within the model itself.
In short, merged logical/physical tools are good. Feeding them with simple
static pre-defined operating point data is bad. And getting worse.
- [ "A Small EDA Vendor" ]
( ESNUG 358 Item 9 ) --------------------------------------------- [8/23/00]
Subject: ( ESNUG 357 #12 ) Well, At Least Veritools Supports C++ Debugging
> Debug Environment: We have added some waveform dumping capabilities but
> these are not anywhere as easy as in Verilog, and require in-house
> support. I would have preferred to use C-Level's process. They are
> just now putting in automatic parsing of the C++ code and dumping of
> variables and structs to a VCD file. This is also nowhere near to the
> point where the Verilog tools are.
>
> - Dan Joyce
> Compaq Austin, TX
From: Robert Schopmeyer <schop@vt3.veritools.com>
Hi, John,
In response to Dan Joyce of Compaq, Veritools demonstrated at DAC a complete
wave form and source code debugging capability for C++ type designs. We
currently support SystemC but can easily support any of the C++ design
environments. Our current capabilities include wave form viewing, with a
compression of 7-20 times for the wave form data, while at the same time
allowing for the almost instantaneous loading and display of signals even
from hugh files, along with the stepping and display of the C++ source code
under test. This is in addition to our standard Verilog and VHDL support.
- Robert Schopmeyer
Veritools, Inc.
( ESNUG 358 Item 10 ) -------------------------------------------- [8/23/00]
Subject: ( ESNUG 357 #6 ) A Useful DC Tcl Script To Fix Hold Violations
> I would appreciate hold-fixing strategies from you/your readers. One of
> our designs showed up several hold problems between FFs that had no
> intermediate logic in the Q-D paths. We're now trying to address this
> issue in synthesis land...
>
> The option we're considering is using 'connection_class' in Library
> Compiler to prevent Design Compiler from connecting one FF directly to
> another. This is obviously a drastic measure, but I couldn't think of
> another way to ensure no two FFs were 'directly' connected. Area is not
> a big concern for our design, so we're not as concerned w/ additional
> gate count.
>
> - [ No Names Here ]
From: Al Czamara <czamara@asic-alliance.com>
Hi, John. I hope all is well with you.
I've done the following in the past for hold-time fixing:
1) Change every flop in the design to a _hold module, which
contains the original flop plus a buffer or series of buffers that
guarantee no hold problems. This is a brute-force approach that
obviously will increase the gate count beyond what's required for
fixing the hold problem.
2) Use Synopsys. In dc_shell there is a 'set_fix_hold' attribute you can
put on a clock. This will cause dc_shell to add a hold-fixing step,
which will solve your flop-to-flop problem. If you're not careful
with module contraints, you can end up with lots of extra gates,
unfortunately. What I've done in the past to get around this problem
is to do a top-level compile for fixing hold ONLY. Since all the
modules are there with a top-level compile, there are few (ASIC I/O
only) missing contraints that could cause lots of extra gates.
Putting a set_dont_touch on the very top level will eliminate that
problem.
3) Manually fix EACH violating path, by adding buffers. I've done this
by hand or with Perl.
I prefer (2) above unless I'm required otherwise by the design process, ASIC
vendor, or where I am in the ASIC release flow.
- Al Czamara
ASIC Alliance
---- ---- ---- ---- ---- ---- ----
From: "Gregg Lahti" <gregg.d.lahti@intel.com>
Hi, John,
Here's a Tcl script that we had to use to correct hold violations before
going into layout so our router didn't choke and cause yet more problems:
# filename: P_proj_insert_buffers.tcl
# author: Doug Hergatt, Gregg Lahti
# created: 06/26/00
####
# description: This procedure is used to fix HOLD violations by inserting
# strategic buffers in the scan, data or both paths of the design. It is
# intended to be invoked pre-layout to reduce the number of violations.
####
# Usage: P_proj_insert_buffers lib_cell_name inst_string fix_hold_mode
proc P_proj_insert_buffers {lib_cell_name inst_string fix_hold_mode} {
# Generate list of violators & filter on VIOLATED
# Hack! Must dump this to a tmp file because the report_constraint
# command output can't be set to a variable! Bad Synopsys! Bad Synopsys!
redirect tmp { report_constraint -min_delay -all };
set violator_list [exec sed -n -e "/VIOLATED/p" tmp];
sh rm tmp;
# Check for no violations
if {$violator_list == ""} {
echo "#INFO: No MIN violations in current design";
return;
}; # end if
set si_violator_list "";
set d_violator_list "";
# Now filter on "/SI" & create list
foreach violator $violator_list {
if [string match */SI $violator] {
set si_violator_list [concat $si_violator_list $violator];
}; # end if
if [string match */D $violator] {
set d_violator_list [concat $d_violator_list $violator];
}; # end if
}; # end foreach
# Build the list to fix
if {$fix_hold_mode == "scan"} {
set all_violator_list $si_violator_list;
} elseif {$fix_hold_mode == "data"} {
set all_violator_list $d_violator_list;
} elseif {$fix_hold_mode == "both"} {
set all_violator_list [concat $d_violator_list $si_violator_list];
} else {
echo "ERROR: Incorrect Fix Hold Mode. Please specify scan, data or both";
}; # end if
# Reset cell counter (used to create a unique instance name
set cell_cnt 0;
echo "#INFO: Fixing Hold violations on the violator paths.";
# Fix all the violations for the violator list
foreach reg_cell $all_violator_list {
# Get the instance name of the violator
regexp {(.*)/.*} $reg_cell var1 var2
set inst_name [file tail $var2];
# Get the hierarchy path to the violating register
regexp {(.*)/.*} $var2 var1 hier_path
# Increment the cell counter
set cell_cnt [expr $cell_cnt + 1];
# Find everything connected to the pin of this register
set orig_net [all_connected [get_pins $reg_cell]];
# Create new instance name (HOLD delay cell)
set new_cell ${inst_name}${inst_string}${cell_cnt};
# Create new net name (net inserted between new HOLD cell & register pin)
set new_net ${new_cell}_net;
# Disconnect the orig net & create the new cell & net
disconnect_net $orig_net $reg_cell;
create_cell -instance $hier_path $new_cell $lib_cell_name;
create_net -instance $hier_path $new_net;
# Add the hierarchy path to the new net & cell vars
set new_net [file join $hier_path $new_net];
set new_cell_in [file join $hier_path ${new_cell}/A];
set new_cell_out [file join $hier_path ${new_cell}/O];
# Connect the nets
connect_net $new_net $reg_cell;
connect_net $new_net $new_cell_out;
connect_net $orig_net $new_cell_in;
}; # end foreach
echo "#INFO: Added $cell_cnt HOLD cells to the design.";
}; # end proc
# document the procedure!
define_proc_attributes P_proj_insert_buffers \
-info "PROJ: Procedure to fix HOLD violations inserting strategic buffers" \
-define_args {
{lib_cell_name "Library Cell Name to insert" lib_cell_name string required}
{inst_string "Instance String to insert in the new cell" inst_string string required}
{fix_hold_mode "Fix Hold Mode: scan, data, or both" fix_hold_mode string required}
}
This isn't, by far, the best approach to doing hold time corrections, but
this script got the job done and it provides a nice baseline example for
tackling the problem above in Tcl. The script could be easily modified to
look for FF-to-FF connections and insert buffers accordingly.
- Gregg Lahti
Intel Corp Chandler, AZ
[ Editor's Note: This is one example from the paper/presentation at Boston
SNUG '00 (Sept 20-22nd) Gregg will be giving called "Tcl: The Good, The
Bad, and The Ugly". Tim Wilson (also of Intel) will be presenting
another paper at Boston on Tcl-based synthesis called "TOPS". - John ]
( ESNUG 358 Item 11 ) -------------------------------------------- [8/23/00]
Subject: ( ESNUG 357 #5 ) How To Initialze An Array Of Constant Integers?
> I need to inizitalise a quite large array (up to 256x256) with an array of
> constant integers returned by a function (the function generates the
> constants dependant upon some parameters in a generic list.)
>
> My problem is I believe Synopsys will only allow constants to be assigned
> integers during elaboration. Is this correct and/or is there anyway to
> get around this?
>
> - Jonathan Ferguson
> ARC
From: [ Elvis Lives! ]
Hi John,
(keep me anon)
I am previously a VHDL user. Now I am using Verilog and started facing
problems.
I wanted to instantiate an array of components. I did not find any better
way of doing that in Verilog other than instantiating each component
individially. "array of instances" is supported by simulators, but not
Synopsys.
Another problem is, in VHDL I could have a generate statement with a
generic, and instantiate any number of components during simulation.
In Verilog, I have to hardcode, because I have to indiviaually instantiate
them.
Following is an example in VHDL, I wanted to know how it can be done in
Verilog.
ENTITY comp_check IS
GENERIC (
WIDTH : integer := 3
);
PORT (
DataR : IN std_ulogic;
Addr : OUT std_ulogic_vector(Width DOWNTO 0);
Data : OUT std_ulogic_vector(Width DOWNTO 1);
);
END comp_check;
Dummy_WIDTH : FOR I IN WIDTH DOWNTO 0 GENERATE
Dummy : TECH_Dummy
PORT MAP(
A => DataR,
O => Addr[i],
AX => Data[i+1]
);
END GENERATE;
Any kind of help is appreciated.
- [ Elvis Lives! ]
( ESNUG 358 Item 12 ) -------------------------------------------- [8/23/00]
Subject: ( ESNUG 357 #9 ) Not Wanting Instantiated MUXes In Clock Gating
> Thank you very much for your offer. What I tried to avoid is to
> instantiate a technology/vendor specific MUX in my RTL code in order
> to make the code technology independent and portable in future. The
> best solution I have found from solvit is to instantiate a GTECH MUX.
> I am still not very happy for this solution either.
>
> - London Jin
> Toshiba San Jose, CA
From: [ Hurricane Floyd ]
John - (anon pls)
We have had this problem before, though not quite for the same reasons. As
many of the commenters suggested, I think it is best to not allow synthesis
to muck with your clock trees, and therefore you should hand-instantiate
the MUXes, since it gives a controllable "handle" on the instance name if
you need to refer to it later. However, this is very difficult to balance
against the portability of the design to other cell libraries, which is
something we do a lot.
What we normally do is add one layer of abstraction (similar to GTECH) like
module mux2by1hi (in1,in2,sel,out);
/* hi-drive-strength 2-by-1 mux */
/* here instantiate your vendor's appropriate mux cell */
endmodule
Even better is to use the "//synopsys translate_off" and "`ifdef" suggested
by someone else to prevent simulation speed penalties.
In your top-level module, you would instantiate mux2by1hi where you are
currently using GTECH cells.
Then, you can put all the mux2by1hi.v files in different directories
organized by vendor, and just point to that one directory for simulation
or synthesis. We use this method for fan-out repeater structures that we
want to hand-instantiate, or for hand-crafted adder blocks, etc.
Trying to keep the design "only RTL" is not possible, that I know of, since
you have to do something with the IO cells, right? Therefore you will have
to link/compile with some vendor's cell library at simulation/synthesis time
anyway. Using GTECH is just Yet Another Library you will have to carry
around (particularly for simulation), so why not just use a vendor's
library? This is also probably better for formal verification.
- [ Hurricane Floyd ]
---- ---- ---- ---- ---- ---- ----
> My design is a multiple clock domain design. In scan mode, however, there
> is only one clock: master_clock from chip pin. In order to balance the
> clocks, I need to MUX all clocks including the master_clock.
>
> wire scan_clk = scan_mode ? master_clk : master_clk;
>
> Design Compiler recognizes that this is feedthrough logic, and thus no
> MUXing logic is generated at all. I talked to Synopsys tech support, and
> was told that there was no way to generate MUXing logic with the above
> code. I seeks for designers' help.
>
> - London Jin
> Toshiba San Jose, CA
From: [ A Synopsys AE ]
London, this will definitely be a problem with the code you present. Since
a synthesizer's job in life is to optimize away logic, it's hard to
convince it otherwise. :)
The way that comes to mind is to write your block so that the synthesizer
*doesn't* know it's the same clock:
module clockgen (scan_mode, clock1_in, clock1_test, clock2_in, ...)
...
clock1_out = scan_mode ? clock1_in : clock1_test;
clock2_out = scan_mode ? clock2_in : clock2_test;
clock3_out = scan_mode ? clock3_in : clock3_test;
This will create three muxes when you synthesize. Now you can simply
control which clocks are which by how you connect them at the next level up.
- [ A Synopsys AE ]
( ESNUG 358 Networking Section ) --------------------------------- [8/23/00]
Sunnyvale, CA -- BrightLink.com seeks engineers w/ Vera, Verilog, Perl exp.
for verification; DC & PrimeTime exp. for design. "sherria@brightlink.com"
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
