Editor's Note: I've got two big pieces of news this week:
1.) I just heard that "Electronic News" has killed its print edition.
It'll just be a web site now. Their EDA Editor, Gale Morrison,
told me that management laid off all 40 of their staff on Monday
(including Gale.) Its first edition was back in 1957. It's sad
that the industry is losing another set of eyes watching it.
2.) This is the first ESNUG post where I've obscured everyone's email
addresses to foil the email harvesters. When decoding, you might
want to first remove the duplicate animal -- and after that think
stuttering, backwards, and "what would replace a @?".
P.S. And think in rhymes for the "dot com" in everyone's address, too! :)
- John Cooley
the ESNUG guy
( ESNUG 403 Subjects ) ------------------------------------------- [11/20/02]
Item 1: WARNING change_names in DC 2002.05-SP1-1 Makes Random Disconnects!
Item 2: HSPICE, Cadence SmartSpice & Spectre with IBM's SiGe 5HP/7HP Kits
Item 3: Experienced IBM ASIC Customer Wonders About Switching To Toshiba
Item 4: ( ESNUG 400 #11 ) Well, Innologic's Technology Still Baffles Me!
Item 5: ( ESNUG 402 #5 ) HAL, LEDA, Verilint, HDLLint, Surelint, SpyGlass
Item 6: ( ESNUG 402 #8 ) User Prefers FormalPro Over Verplex & Formality
Item 7: ( ESNUG 401 #3 ) Monterey Says Their Old Bugs Have Been Fixed
Item 8: ( ESNUG 402 #1 ) Multilevel Voltage Problems In PrimeTime v2002.09
Item 9: Summit FastC / Visual HDL, Cadence SPW, "Cooley Is A Pompous Ass"
Item 10: A Quick Wrapup Of The 2002 International Cadence Users Group (ICU)
Item 11: I Need TetraMAX ATPG To Generate Contention / Floating Patterns
Item 12: User Pissed That DWPCI Cores Are Now Sold With A Royalty Attached
Item 13: ( ESNUG 402 #2 ) Running Wroute Stand-Alone Uses Up A PKS License
Item 14: Customer Runs Into Newbie PowerMill Problems; Seeks Others Help
Item 15: AMI Semiconductor Seeks IC Design Houses For Overflow Chip Work
( ESNUG 403 Item 1 ) --------------------------------------------- [11/20/02]
From: Russell Petersen <russp in subasic.sciatl hot calm sheepsheepsheep>
Subject: WARNING change_names in DC 2002.05-SP1-1 Makes Random Disconnects!
John,
You might want to make others aware that they should read the Solvnet
http://solvnet.synopsys.com/retrieve/003023.html
document. I just ran into a case where change_names in 2002.05-SP1-1 Design
Compiler produces bad code. The change_names command is actually causing
disconnects to occur throughout my block! Very bad. I'm surprised
Synopsys has not given out a general red alert about this to users given
that I'm sure everyone uses the change_names command at some point in their
flow. It could be that I just haven't seen it yet though or that they are
preparing to send it out as the document ID above had a last changed date of
10/22/02. In any case, I see this as a major problem since the end result
is incorrect logic. Suppossedly the 2002.05-SP1-E1 release fixes this but
I'm still waiting on download instructions for that code before I can
verify that.
- Russell Petersen
Scientific Atlanta, Inc. Lawrenceville, GA
( ESNUG 403 Item 2 ) --------------------------------------------- [11/20/02]
Subject: HSPICE, Cadence SmartSpice & Spectre with IBM's SiGe 5HP/7HP Kits
> I am using Cadence SmartSpice right now. The SmartSpice program is very
> similar to HSPICE. But the thing is my design kit doesn't have the
> SmartSpice model parameters inside. So everytime when I start to do the
> simulation, I must use:
>
> CIW->Tools->CDF->Edit->Browse Lib
>
> then choose the model and then input the parameters.
>
> The worst thing is these parameters can't be saved. When I close my
> Cadence program, I need to input all the model parameters again. If I
> have NFETs, PFETs, NPN, PNP in my schematic, I have to take 30 minutes
> to input the parameters!!
>
> Is there a good way to solve this problem? When I opened the HSPICE view
> of the NPN model, all the paramenters can be read immediately. So there
> should exit a way to save all the parameters in one file and then read
> it in Cadence SmartSpice. I just don't know how to do it.
>
> - Kuan Zhou
> Rensselaer Polytechnic Institute Troy, NY
From: Andrew Beckett <andrewb about goatgoatgoat cadence cot tom>
Hi Kuan,
Not sure why you need to edit the CDF, but presuming that you do, then you
should change the CDF type to "Base" instead of "Effective" before you make
the parameter changes.
That way, the CDF is changed on disk rather than just in memory. Of
course, this assumes that you have write access to the library containing
the component which you're editing?
Otherwise, if you don't have write access, set it up as Effective, and
then do in the CIW:
cdfDump("libName" "compName.cdf" ?cellName "compName" ?level 'user)
where libName and compName are the name of the library and name of the
component respectively. Then next time you should be able to do the CDF
changes just by typing: load("compName.cdf")
- Andrew Beckett
Cadence Design Systems Ltd
---- ---- ---- ---- ---- ---- ----
From: Kuan Zhou <catcatcat zhouk inside of rpi spot edu>
We are using SiGe design kit from IBM. The issue is Spectre simulator
doesn't support parallel simulation. So the simulation often takes a lot of
time and memory space. SmartSpice has one advantage that it runs the
simulation parallely. My professor told me it can devide the simulation
into several parts and every part can be run simultaneously.
This is why I have to figure out how to use SmartSpice.
SmartSpice has a little different from HSPICE. The IBM design kit doesn't
include the model files for SmartSpice. So I have to input all the
parameters for all the devices in the SiGe lib.
I checked my system. I don't have permission to change the CDF file. Is it
possible to copy the CDF file into my own directory and load this CDF file
into Cadence during initialization? It may be more convinient for me. Is
it possible to use Tools->CDF->Copy to do that?
- Kuan Zhou
Rensselaer Polytechnic Institute Troy, NY
---- ---- ---- ---- ---- ---- ----
From: Andrew Beckett <cowcowcow andrewb wandering ccaaddeennccee shot rom>
Hi Kuan,
You'll probably need to either do the load("compName.cdf") trick that I
suggested, or copy the component from the library into a local library, and
then you'll be able to edit the component from that library, change the base
CDF and so on CDF is stored as a property on the cell (you can see it in the
library manager by doing Edit Properties over the cell name - although don't
edit that way unless you feel like making life difficult for yourself!)
In that case, you'd need to make sure all your schematics use the
component from your own library rather than the original library though.
- Andrew Beckett
Cadence Design Systems Ltd
---- ---- ---- ---- ---- ---- ----
From: Kuan Zhou <zhouk inside of rpi spot edu pigpigpig>
I successfully put one device parameters inside one CDF file. Now I have
another problem: How can I make the SmartSpice simulator use my own CDF file
to run the simulation next time? Assume I close my Cadence and start it
again. So all the information stored in the memory is gone.
- Kuan Zhou
Rensselaer Polytechnic Institute Troy, NY
---- ---- ---- ---- ---- ---- ----
From: Andrew Beckett <bwerdna from ecnedac pot mom elfelfelf>
Hi Kuan,
I'm assuming you used the cdfDump method I suggested? If so, you can put
load("compName.cdf") in your .cdsinit file to get it to load the CDF each
time - however, this is really rather a hack; it would be better to fix the
base CDF somewhere, or have a copy of the library for use with SmartSpice,
which you have the base CDF changed.
- Andrew Beckett
Cadence Design Systems Ltd
---- ---- ---- ---- ---- ---- ----
From: Kuan Zhou <apeapeape zhouk near rpi lot edu>
I used the way you taught me. I put load("nfet.cdf") in my .cdsinit file.
It works fine. You are so excellent. Now I have a new problem. As I said,
I am using SiGe design kit from IBM. In the 7HP design kit, it doesn't
include the HSPICE model files. It only includes Spectre and SpectreS model
files for all the devices. The SmartSpice model files are similar to
HSPICE. So it's better to create the HSPICE model files first.
In 5HP (an older version of SiGe kit), we have the HSPICE model files. But
the format of HSPICE is quite different from Spectre. I found it very
hard to convert the model files from Spectre to HSPICE manually. Is there
a simple way to convert the SpectreS or Spectre model files to the HSPICE
format? I found in CIW window, if you click Tools->Conversion tool box, you
can find some ways to convert SpectreS model files to Spectre format. But
I can't find any way for HSPICE.
Do you have any suggestions?
- Kuan Zhou
Rensselaer Polytechnic Institute Troy, NY
---- ---- ---- ---- ---- ---- ----
From: Andrew Beckett <bwerdna of cowcowcow cadence not tom>
Hi Kuan,
We don't supply a translator from Spectre to anything else (I guess this is
not entirely unsurprising given that Spectre is a Cadence tool and HSPICE
is not ;->).
However, it wouldn't be that hard to write one using Perl or awk for simple
models. From my experience, the IBM models are pretty complex and have lots
of parameterized equations in them, so you'll probably have trouble
automating this.
You might want to contact IBM to see if they have HSPICE/SmartSpice models
available (perhaps they just don't ship them by default with their kit?).
Or the best solution - use Spectre? You're at a University, don't you have
Spectre available?
- Andrew Beckett
Cadence Design Systems Ltd
---- ---- ---- ---- ---- ---- ----
From: Kuan Zhou <zzhhoouukk near rpi hot edu moomoomoo>
I don't know whether Spectre can handle my simulation. As I said, Spectre
doesn't support parallelism. So the time for simulation is quite long. I
guess for my circuit, it would take 2 or 3 days to finish if the workstation
doesn't crash. In the manual of SmartSpice, it says it can simulate
parallely. So my professor wants me to try it. Do you know how to speed
up my SmartSpice simulation?
I have one idea now. I can generate the netlist file from Spectre, then
use some program to convert Spectre format netlist to SPICE format, just
like spp does.
You are absolutely right. IBM HSPICE model files have lots of formulas.
It calculates the parameters dynamically. Converting the Spectre to SPICE
format will be a big headache. Moreover, I can't gurantee the converted
files are correct. Since the HSPICE model in 5HP design kit doesn't
support VBIC model, I have to add VBIC model in 7HP design kit, which
means I don't have anything to follow.
- Kuan Zhou
Rensselaer Polytechnic Institute Troy, NY
( ESNUG 403 Item 3 ) --------------------------------------------- [11/20/02]
From: [ Curious George ]
Subject: Experienced IBM ASIC Customer Wonders About Switching To Toshiba
Hi, John,
Please keep me anon this time.
Right now we are looking at the advantages of working with Toshiba vs. IBM
as an ASIC vendor. We have some experience with IBM, but are being wooed by
the promises of cheaper pricing and support by Toshiba. Toshiba sure sounds
attractive (and I bet they have some pretty dense RAMs, too!) but I am
wondering if it is all smoke and mirrors. The grass always being greener
on the other side. I am sure Toshiba has skeletons as well! I'd like to
ask your readers what these Toshibia skeletons are.
IBM, well let's just say that from week to week they change their mind on
how they would like to support smaller ASIC customers, how they want to
treat us and also how much they want to tell us. With all of the walls
inside Big Blue, I am not sure that they even know how to talk to
themselves, let alone customers. Yet they do have undeniable technical
expertise and if you follow their rigorous process (and sometimes laborious
as well, have you ever comparer Einstimer to PrimeTime? IBM says it takes
one person to drive this one tool full-time for a single project -- and
they are right!!!) they do seem to be able to deliver a functional,
testable ASIC. Another question on IBM is will your support team even be
there next month. Layoffs and job reassignments seem to be the norm over
at IBM. We went through 3-4 major iterations of IBM support personnel on
our last ASIC alone!
Anyway, these are just some of the concerns we have. Overall areas that
I would like to learn more about for both companies in order to compare
them, is to find out about user's experiences in the following areas:
- the real Toshiba price points
- the Toshiba vs. IBM tool issues (standard tools vs. proprietary tools,
ease of use & integration, etc.)
- Toshiba capacity (or lack thereof)
- Toshiba availability (hot lots?)
- the fab cycle time at Toshiba
- process maturity (0.18u, 0.13u and below) for both Toshiba & IBM
- Toshiba handling of testability issues (embedded in the process, or
you do you do it on your own?)
- Toshiba level of support (especially for smaller companies)
- Toshiba vs. IBM issues supporting projects with lower production volumes
- access to Toshiba IP cores (PCI, GbE, processors, etc.)
- access to Toshiba embedded memory and density (SRAM, DRAM, CAM)
- Toshiba communications issues (Japanese language barriers, coordination,
"not my job", etc.)
- quality of local Toshiba support teams
- access to Toshiba technical experts & decision makers within the company
- sharing mask charges for protos (i.e., shuttle service) at Toshiba
As I said, I have some experience with IBM, but by no means have I hit every
boundary condition so I would really like to hear anything that anyone has
experienced with either Toshiba vs. IBM. I also think it would be a really
interesting topic in ESNUG.
- [ Curious George ]
( ESNUG 403 Item 4 ) --------------------------------------------- [11/20/02]
Subject: ( ESNUG 400 #11 ) Well, Innologic's Technology Still Baffles Me!
> It is quite interesting to read those comments on Innologic tools.
> From my experience, I think it's more a front-end tool for the back-end
> designers. I have been using ESP-CV from InnoLogic in my current
> company. We used it for equivalence checking of our SPICE netlist
> against our RTL model for the full custom design blocks including
> register files, memories, caches and etc. ESP-CV requires very minimum
> logic modeling effort for custom designed blocks. Most of the net-lists
> from schematic can just directly go to the flow, for circuit designers
> who usually are uncomfortable with modeling that is a big plus.
>
> - Dennis Yau
> T-Ram, Inc. San Jose, CA
From: John Weiland <jjwweeiillaanndd inside intrinsix wrought pomme>
Hi, John,
As for Innologic, I first saw them at DAC 2001. They were very
interesting - unlike any other tool I was familiar with. I actually went
back three times because each time I got an explanation I smiled and
nodded but later thought about it and realized I hadn't fundamentally
gotten what they were talking about. Once I finally got it, I talked to
other people who had actually attended their one hour demo (I had not)
and they had also done the smile and nod thing; it was clear they really
didn't understand the tool either. I told Innologic they needed better
examples and made specific suggestions on how to improve the ones they
had. I made up my own example for my 2001 DAC report (which you
reprinted) and wrote quite a bit more about them than about most other
vendors. There were no critiques last year about that section of my
report. One other thing to note: I asked one of their AEs at the booth
about where this tool would fit in the design flow, i.e. how would
people typically use their tool. He said it was a new tool and they
really didn't know exactly how people would use it. Their talk showed
no typical uses.
At DAC 2002, I was interested to see how Innologic was doing. The guy
at the booth told me that the majority of users are not using it for
symbolic simulation at all but rather just for normal binary simulation.
I'm not making this up; that's what he told me. I was disappointed.
Their technology is neat and I was hoping it would take off. As I said in
my report, there are three possible explanations for this:
1. there is something about the Innologic technology itself that makes
it very limited in what it can do (nothing you can do about that)
2. the Innologic technology is great but there is something about the
tool that needs to be fixed to make it more usable,
or
3. the tool is ready to use by most designers but Innologic just doesn't
know how to explain it.
I frankly am hoping that (3) is the case, but I don't really want to claim
that is true and blast their sales and marketing staff without proof.
Realistically, some tools are just harder to explain than others, and those
hard-to-explain ones seem to congregate in functional verification. I would
say this to the three pro-Innologics respondents - if you really love this
tool and want it to take off, I would suggest you contact your Innologic
salesperson and provide:
1. a simple and clear explanation of what the Innologic tool does
2. some simple and clear examples of how the Innologic tool can be
used by average designers
and
3. a simple and clear explanation of why this tool is better than the
alternatives. (I think Jason Su is headed in this direction).
I might also comment that having three users from such a small user
community respond to this report at least shows they have a good percentage
of loyal and enthusiastic users, which is more than many vendors can say.
- John Weiland
Intrinsix
( ESNUG 403 Item 5 ) --------------------------------------------- [11/20/02]
Subject: ( ESNUG 402 #5 ) HAL, LEDA, Verilint, HDLLint, Surelint, SpyGlass
> Our little company will soon be looking for a Verilog linter. We don't
> need a 5-figure, GUI-heavy "Design Analysis tool". We just want a
> linter. Preferably something straightforward and inexpensive (ideally,
> like Verilint before it was sold to Avanti.) I'm guessing there are
> some good tools out there filling the price/functionality space that
> Verilint left behind, but being from smaller outfits they may not be
> well marketed. I was wondering if anyone had any recommendations. I
> was also wondering what experience people have had with Cadence's "HAL"
> Linter.
>
> - Jeff Winston
> Engim, Inc. Acton, MA
From: Jim Avant <javant dogdogdog near mindspring fought bomb>
John,
I've also used VeriLint in the past but can't afford it today. ModelSim has
a -lint option built into it that Jeff might want to try. It's not as
helpful but better than nothing (especially if you already own ModelSim).
- Jim Avant
Mindspring
---- ---- ---- ---- ---- ---- ----
From: Dirk Niggemeyer <dirk niggemeyer in qquuaannttuumm pot mom hoghoghog>
Hi John,
One low-price linter that I can think of is HDLLint from Veritools. I saw
their demos at DAC and thought that the tool would provide sufficient
functionality for our own purposes at a reasonable price.
We are currently using Cadence HAL (Verification Cockpit) both in stand
alone mode as a first-shot linter during coding, and linked to NC-Verilog.
In the latter mode, HAL uses simulation snapshots rather than HDL input to
discover race conditions, e.g., due to register variable assignments in
multiple always blocks. We never used the feature in which you can program
your own checks. Older versions under Linux created sporadic core dumps
which we could never fully explain; using LDV 3.4, HAL appears to be very
reliable. The main drawback of HAL is that it comes with the full Cockpit
price tag.
- Dirk Niggemeyer
Quantum Corp. Shrewsbury, MA
---- ---- ---- ---- ---- ---- ----
From: Nathan Dohm <nightowlnightowl dohm inside of stargen wrought mom>
Hi John,
We are a startup company, and have been using HDLLint from from Everest
Design Solutions for the last 3 years. I posted a review in ESNUG 345 #2.
Since that time, they have continued to make improvements including VHDL
support (not used by us), Verilog-2000 support, and various other new
checks and features. They also have an interesting Perl package which gives
you hooks into your design if you want to write Perl scripts to manipulate
your RTL. It has occasional problems but it has been adequate for our needs
and the problems are generally addressed in a timely manner. The tool is
developed by a very small company, and is currently being distributed by
Silvaco International ( http://www.silvaco.com ).
You could also check out SureLint, I believe it is now owned by Verisity. I
have not evaluated this tool and I am not sure what it costs.
- Nathan Dohm
StarGen, Inc.
---- ---- ---- ---- ---- ---- ----
From: [ The Ivory Toad Of Shankar ]
John, you must keep me anon on this one.
Synopsys is still selling Verilint, but they steer you to LEDA because they
won't promise future Verilint development. (Only LEDA will receive
further development.) With all new new coding standards (Verilog 200x, etc.)
about to come out, this makes buying Verilint a foolish choice.
Essentially, Verilint is going to go the way of Motive, except that LEDA is
no Primetime. This leaves the linter market "up for grabs" as Verilog
extensions push all the existing Verilint seats into obsolescence. 2003
should be an interesting year for the linter business.
- [ The Ivory Toad Of Shankar ]
---- ---- ---- ---- ---- ---- ----
From: Laurent Claudel <sheepsheep laurent claudel from wavecom spot fr>
Hi John,
We've tried to use HAL here about a year ago and were not really impressed.
I couldn't pinpoint really precise examples but I remember finding it rather
awkward to use. One of the annoying thing was that you could do the linting
only on a snapshot (after compiling and elaborating the design with NC) and
not just on the Verilog. Since we don't do the compile/elab manually but
with a script controlling our simulation flow, it wasn't convenient at all
to fit HAL within that. I know that it is now possible to do some linting
directly on the Verilog but you've got only a small part of the features
while doing it that way. We eventually decided to get a Surelint license
and we're rather happy with it.
- Laurent Claudel
Wavecom France
---- ---- ---- ---- ---- ---- ----
From: Winston Worrell <elephantelephant wnotsniw fo tfosorcim not calm>
John,
Surelint by Verisity, unfortunately, they are 'end-of-lifeing' the
product, but you could proabably talk them into selling you a copy.
- Winston Worrell
Microsoft
---- ---- ---- ---- ---- ---- ----
From: Curt Beckmann <cbeckmann barking from rhapsodynetworks bought palm>
Hi John,
Regarding the request for a low-cost linter, we use Verisity's Surelint
tool. As a company with modest budget for tools, it has been great for us.
I believe the price was $15k for a single perpetual license a couple years
ago (plus maintenance, of course).
- Curt Beckmann
Rhapsody Networks
---- ---- ---- ---- ---- ---- ----
From: Bob Kerwin <bboobb atatat atrenta got bomb goldfishgoldfish>
Hi, John,
My name is Bob Kerwin and I am the Atrenta Account Manager in the East
Coast (based in the Boston Area). Based on Jeff's email, I believe we
may have a tool that will meet his needs. Our product is called SpyGlass.
SpyGlass is a RTL predictive analysis tool that contains linting rules
similar to Verilint and handles Verilint pragmas. In addition, to the
linting features, SpyGlass also contains "rule decks" specific to advanced
rules (i.e. identifying clocks and crossings, synchronization issues,
timing and area). SpyGlass has a built in synthesis engine that actually
synthesizes the design such that false warnings are eliminated. Custom
rules can be developed easily with the Perl interface. The tool runs in
both GUI and batch mode and contains about 2,500 rules "out of the box".
- Bob Kerwin, Sales
Atrenta Inc. Groton, MA
---- ---- ---- ---- ---- ---- ----
From: <goatgoatgoat frank li wandering silvaco slot psalm>
Hi, John,
Glint is our Verilog and VHDL code verifier which is provided by Everest
Design solution, Inc. a subsidiary of Silvaco International. Glint has been
in the market for a couple of years, and has a lot of customers as Agilent,
Broadcom, AMCC, Cisco, Flextronix, Ciena, TDK, LSI, etc. See
http://home.earthlink.net/~eds6/files/PDF/Datasheets/glint.pdf
In terms of price, we have two options. The perpetual license for Glint is
$15k per copy. The annual time based license for Glint is $5k per copy.
- Frank Li, Sales Manager
Silvaco International Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: Bob Ellis <moomoomoo bob ellis inside adesnart pot plomb>
John,
I noticed that Jeff was interested in linters, and thought I'd mention
TransEDA as a possible solution for him. Our software can be downloaded for
evaluation from our web site http://www.transeda.com .
- Bob Ellis, Sales
TransEDA Somewhere, NH
---- ---- ---- ---- ---- ---- ----
From: Louise Thorpe <louise|esiuol in veritable|elbatirev cot alm>
Hello John,
I saw Jeff's posting in ESNUG about his search for a low cost Verilog
lint tool. He might want to consider checking out Veritable's
Verity-Check Designer product:
http://www.veritable.com/verity-check.html
Verity-Check Designer provides low cost lint and rule checking
capabilities and also offers more complex RTL analysis, such as
formal clock domain boundary checking.
- Louise Thorpe
Veritable, Inc. Mountain View, CA
( ESNUG 403 Item 6 ) --------------------------------------------- [11/20/02]
Subject: ( ESNUG 402 #8 ) User Prefers FormalPro Over Verplex & Formality
> Thanks for publishing the comparison of Formality and Chrysalis in
> ESNUG 400 #15. I wonder if any user of both Mentor's FormalPro and
> Formality has published such a report? I would be interested in
> looking at it.
>
> - Mahesh Siddappa
> Atmel
From: Russell Petersen <russp of subasic sciatl got mom sharksharkshark>
John,
We also used to use Formality but got sick of the bugs and decided to dump
it in favor of something else. We tried out both Verplex Tuxedo and Mentor
FormalPro. We decided to go with FormalPro due to some past relationships
with Mentor and we also felt it was a better tool but I did not have time to
dig deep enough to prove that. In any case, we have been using FormalPro
now for about 2 months and so far we are very pleased. Mentor is very
interested in making us successfull so the support has been great. I wish I
had more time to run the tool personally (have not much really run it myself
since the eval) but I do recommend anyone looking into a formal tool to
consider the Mentor FormalPro tool.
- Russ Petersen
Scientific Atlanta
( ESNUG 403 Item 7 ) --------------------------------------------- [11/20/02]
Subject: ( ESNUG 401 #3 ) Monterey Says Their Old Bugs Have Been Fixed
> We've taped-out 1 real chip using Monterey's tools. The chip is a 3
> million gate Ethernet channel switch. It contains 700 K standard cells,
> ~80 RAMs, and 2 clock trees - the larger one with 66K flops. Our
> approach with this design was a flat methodology using Monterey's
> Dolphin system.
>
> - Jim Jensen
> LSI Logic Bloomington, MN
From: Wolfgang Helfricht <gnagflow atatatat mondes taught calm>
Hi John,
We learned a lot from this design - which was one of the earliest tapeouts
using Dolphin - and most of the issues brought up by Jim have been addressed
in the three releases of Dolphin that have been shipped since his chip was
taped out. In particular, we have put a lot of emphasis in improving
Dolphin's run times and memory requirements, and it now consumes less than
50 percent of the memory and at the same time it runs twice as fast as the
version used on the LSI chip.
Here are some other lessons we learned from this project:
- We encountered many problems that were the result of incompatibilities
between the netlist and constraint file. There were times when the
physical designers were working with a version of the constraint file
that did not match that of the netlist. We now recommend using Sonar
to validate that all constraints are achievable before starting a
detailed place and route run.
- Some DRC violations cropped up that were a result of incomplete or
erroneous DRC rules decks. Once the rules decks were corrected, many
of the DRC violations disappeared. We recommend that designers run
a small block from the design through the entire back-end flow before
tackling the entire design. This is a good way to shake out problems
without wasting machine cycles. It's also a lot easier to debug design
flow setup problems using a smaller dataset.
- During the course of this project, LSI requested many ECO features that
Dolphin did not support. Of course, good ECO capability is essential and
the lack of these features slowed down this project. We made providing
ECO features a big focus of our 2.1 release last spring to address this
significant deficiency.
Thanks for providing ESNUG. I hope some of my comments will be helpful
to your readers.
- Wolfgang Helfricht
Monterey Design Systems
( ESNUG 403 Item 8 ) --------------------------------------------- [11/20/02]
Subject: ( ESNUG 402 #1 ) Multilevel Voltage Problems In PrimeTime v2002.09
> We had an old custom cell library that we had used successfully for a
> while, but when we switched to PrimeTime v2002.03-SP1 (or v2002.09) we
> found that the SDF generated was very different from that generated by
> v2001.08-SP1-1. We were seeing net delays that were in the -100 ps range
> and quite a few RC-005 warnings. ...
>
> ... Another way to work around the problem is to use:
>
> set lib_thresholds_per_lib false
>
> but I hesitate to suggest it as a long-term solution as it could cause
> analogous problems when there *are* libraries with individual thresholds.
>
> - Joe Gilray
> Agilent Technologies Corvallis, OR
From: Russ Segal <rbsegal barkbarkbark wandering reshape mott psalm>
Hi John,
I am responding to which explains why
set lib_thresholds_per_lib false
may be important in PrimeTime version 2002.09. A few days ago, I found out
that the problem is much more extensive than initially reported.
Joe's mail suggests that old libraries, without default voltages may be a
problem for PT's new "threshold scaling" to handle. Actually, the problem
exists with up-to-date libraries too, if they have different voltages.
We are using the most recent Artisan/TSMC 0.18 standard cell library (nom
1.8 volts). We are also using the most recent TSMC I/O library (nom 3.3
volts). Even with up-to-date libs, you need to set lib_thresholds_per_lib
to avoid RC-005 errors during RC delay calculation.
There is also a problem which occurs "prelayout". That is, when you are
running timing without SPEF. This problem does not give an error, it just
gives incorrect timing.
When you don't have SPEF, PrimeTime is performing multi-voltage delay
scaling going into and coming out of I/O cells. But the library is
characterized assuming no external scaling. This makes the timing report
incorrect. Worse yet, a voltage scaling occurs between output pad drivers
and Verilog output ports (which are assumed to be a nominal 1.8 volts).
To check to see if you are having this problem, try the following. (Assume
your verilog output port is called rx_clk_pad, and your pad driver cell is
called io_digital/_rx_clk.)
report_timing -to rc_clk_pad -input -delay min
At the tail end of the report you'll see a mysterious negative delay; in
my case it's -0.236. Why it's there, I know not.
Point Incr Path
---------------------------------------------------------------------
io_digital/_rx_clk/OEN (PDT24DGZ) 0.037 1.347 r
io_digital/_rx_clk/PAD (PDT24DGZ) 0.845 2.192 r
rx_clk_pad (out) -0.236 1.956 r
data arrival time 1.956
Now try doing:
report_delay_calculation -from io_digital/_rx_clk/PAD \
-to rx_clk_pad -thresholds
You'll see this little beauty:
Signal level (rail voltage) from_pin: 3 to_pin : 1.62
Delay scaling rise: -0.236=3.83e-07+0.821*(1.62*0.5-3*0.5)/[3*(0.9-0.1)]
Delay scaling fall: 0.222 =3.83e-07-0.776*(1.62*0.5-3*0.5)/[3*(0.9-0.1)]
Rise delay = -0.236109
Fall delay = 0.223362
Unfortunately,
set lib_thresholds_per_lib false
doesn't fix this problem. But Haroon at the Synopsys support center was
able to chase down the solution. (Thanks!)
You also need to set:
set timing_prelayout_scaling false
If you are running PrimeTime 2002.09 and your I/O cells characterized at a
different voltage than your standard cells, I encourage you to carefully
check your I/O timing against PrimeTime 2002.03. Run report_timing with
"-input". It will make differences easier to see.
- Russ Segal
Reshape, Inc. Somewhere, CA
[ Editor's Note: Russ Segal was one of the original creators at Synopsys
of HDL Compiler and PrimeTime before he joined Reshape, Inc. - John ]
( ESNUG 403 Item 9 ) --------------------------------------------- [11/20/02]
Subject: Summit FastC / Visual HDL, Cadence SPW, "Cooley Is A Pompous Ass"
> Michael Lee of Lucent joined in. "Then there is the Summit FastC approach;
> which is to write the your RTL as either C, VHDL, Verilog and use Visual
> HDL to push it all out together," Michael said. "I think Summit's
> approach of using a mix of graphical and textual design entry and allowing
> you to mix up styles is good. The demo looked nice. Everything looked as
> good as usual with Visual. The proof of course comes when you actually
> try it out."
>
> - from "Back From The Dead" by John Cooley
From: FC Wolverton <weeweewee cwolvert whining from attbi fraught calm>
John Cooley is an over-rated, pompous ass. This silly article about a
company that will soon be a foot-note in the industry just underscores
how irrelevant he has become. He needs to go do some real work.
- FC Wolverton
FRCC
---- ---- ---- ---- ---- ---- ----
From: Frank Eory <user=p22212 domain=email.sps.mot splot palm>
Hi John,
You and I met briefly back at DesignCon (or SuperCon, as it was back then) in
'96 or '97, when I did a couple papers on Motorola's "system-to-silicon"
methodology for digital comm/DSP-oriented designs using the SPW tool from
Cadence. SPW was and is a graphical design entry and graphical simulation
tool -- although it is quite a bit different than Summit -- and we have used
it successfully for nearly 10 years now to design and verify a variety of
signal processing ICs.
I don't mean to toot Cadence's horn too much, but in this case, they took a
decent tool they acquired from another company and actually made it more
useful and valuable over the years. Who would've thought?!
As I have helped spread this methodology around Motorola over the years;
particularly to system designers who want and need to get closer to the IC
design process. I continue to run into ASIC engineers who have the attitude
that "real men write code" or "it looks too much like schematic capture."
As with Summit, SPW never really caught on with mainstream ASIC engineers,
although it has become very popular with our system engineers -- especially
those needing to build models of wireless comm links, including RF channel
effects and fixed-point precision effects. The rich libarary of system
modeling blocks alone makes it a very productive testbench development tool
for wireless and multimedia designs. For those of us who go all the way to
graphical RTL design in the SPW environment, we have discovered an important
ancillary benefit -- when you add a new engineer to a project in midstream,
or you have to resurrect and re-use someone else's old design, it is far
easier to come up to speed with a hierarchical block diagram than it is with
a directory full of hand-written .v files.
I appreciate the sentiment that such graphical tools are designed to "help
newbies become productive faster," but the productivity boost isn't only for
newbies. I remember being such a newbie, and at the time, my boss was
grateful that I rapidly went from being a systems guy who was clueless about
ASIC design to someone who could quickly make optimized RTL architectures
that were inherently synthesizeable with good QoR and DFT-friendly netlists.
Back in '93, working with machine-generated VHDL RTL from SPW, we tossed
VHDL RTL simulation from our flow because we consistently proved that the
faster C simulations in SPW were always cycle-accurate to the RTL and SDF
back-annotated gate level simulations. We didn't call it C-RTL back then,
but that's what it was. But never mind C-RTL -- code is code, and changing
languages does not necessarily elevate the level of design abstraction.
Systems guys don't want to write code anyway! Well, maybe an occasional
Matlab routine. What we really want is to draw pictures on our
workstations, just like we do on the backs of napkins in the cafeteria, and
just like we did in kindergarten, when an idea struck us and we quickly
wanted to sketch it out and see where it would lead us. From algorithm
verification to architecture optimization to synthesizable RTL is a fairly
smooth process in this graphical design & verification environment. The
code generation is language-agnostic: C, Verilog or VHDL are all just a
mouse click away. Once we established the trust and experience, many
designs ago, we lost interest in even looking at the code.
The criticism that graphical RTL capture tools are too restrictive is
indeed valid, but this restrictiveness also has its good points. When
working with multiple designers in different locations, we have minimized
integration headaches and variable QoR by ensuring consistent block
diagram construction styles among the different designers. Obviously, this
can be and is done with hand-written RTL designs, too, but it seems much
easier to guarantee the results when everyone works with a common set of
both primitive and high-level graphical RTL library components, an agreed
upon set of rules -- how to handle overflow and loss of precision, how to
do state machines, resource-sharing of multipliers, etc. -- and consistent
machine-generated code. When left to his own creative devices with a text
editor, each designer is more apt to re-invent the wheel in a different way
than when all designers are working in a restricted graphical RTL
environment. In any case, the SPW library of graphical RTL components
contains enough primitive blocks that you can create virtually any RTL
architecture in SPW that you can create in hand-written code. But its
strength is more in the higher-level RTL blocks that allow you, for example,
to make a digital filter that actually looks like a digital filter. After
gaining some experience, designers quickly learn to visualize how a
particular collection of graphical blocks will translate into gates, just
as experienced code-writers learn to visualize how thier code constructs
will map into gates.
The biggest headache with SPW-based designs has always been the control
logic. Despite the addition of a workable FSM bubble diagram editor a few
years back, many SPW users found themselves spending an inordinate amount
of time constructing graphical state machines. In those cases where a chunk
of Verilog can quickly be written to do the job, the tool accomodates
this nicely.
When used correctly, graphical RTL design and testbench development coupled
with a few dashes of hand-written code can indeed move the design process
to a higher level of abstraction and higher productivity. When used
incorrectly, it can degenerate into a quasi-schematic capture exercise. The
key, as with any EDA tool, is to understand the strengths and weaknesses of
the tool and to build a solid methodology around it that ensures a
productivity gain and smooth integration with the other tools in the design
flow. Then, even die-hard ASIC guys will recognize that the picture-drawing
skills they learned in kindergarten can be invaluable in ASIC design, and
they will toss out thier emacs windows and lint checkers wherever they can.
- Frank Eory
Motorola Semiconductor Products Sector
( ESNUG 403 Item 10 ) -------------------------------------------- [11/20/02]
From: Donna J Ducharme <xxxdjducharmexxx of xxxti.xxxcom>
Subject: A Quick Wrapup Of The 2002 International Cadence Users Group (ICU)
Fellow Cadence Users,
At ICU 2002 we had 330 Cadence users who attended the three-day conference
in San Jose. We also had more papers submitted for inclusion than previous
years; and for the first time we were able to publish papers in our
proceedings that we could not fit into our schedule. Thanks to all for a
very successful conference.
The following are the winners of the ICU MVP awards.
PCB Track
Charlie Davies Implementing Design Intent using the Constraint Manager
Kate Mayer Tips and Tricks SPECCTRA Classroom
Steve Durrill A Graphical Extension Language Solution for ConceptHDL
IC Track
John Gianni New SKILL API Standards, Tools & Processes
- an efficient approach -
Cliff Cummings The Fundamentals of Efficient Synthesizable Finite
State Machine Design using NC-Verilog and Build Gates
Paul Tuinenga Models Rush in Where Simulators Fear to Tread:
Extending the Baseband-Equivalent Method
Systems & Platforms Track
Fred Sendig Migrating to OpenAccess database from CDBA (DFII)
Michael Munsey The Case For a Simulation Server Farm
Derek May Utility for Extracting and Highlighting Net
Connectivity in Virtuoso
Please be sure to check out our website: http://www.cadenceusers.org
- Donna Ducharme, ICU Chair
Texas Instruments
( ESNUG 403 Item 11 ) -------------------------------------------- [11/20/02]
From: Vijay Bhargava <vijaybhargava around mmoottoorroollaa thought alm>
Subject: I Need TetraMAX ATPG To Generate Contention / Floating Patterns
Hi John,
I need to do floating node analysis. For that I need iddq/stuck-at patterns
which should include as much contention/floating conditions as possible. Is
there some way to force TetraMAX ATPG to generate such patterns so that they
have contetion/float conditions? I can change the severity level of
contention checking in TetraMax, but I am doubtful. This might just switch
off the messaging of contention conditions and it'll neglect to actually
generate contention patterns. Can somebody clear this doubt of mine?
- Vijay Bhargava
Motorola India Gurgaon, India
( ESNUG 403 Item 12 ) -------------------------------------------- [11/20/02]
From: [ Color Me Angry ]
Subject: User Pissed That DWPCI Cores Are Now Sold With A Royalty Attached
John,
Please keep me anonymous.
I just received an e-mail from Synopsys's IP marketing stating that Synopsys
is stopping "development of the DWPCI" cores. From their e-mail:
"This acquisition, however, does create some overlap in our product
lines. After careful consideration, we have decided to focus our
future engineering development of PCI on the fee-per-use cores that
we have recently acquired with inSilicon so that we can focus our
resources on a single PCI Core."
The inSilicon core-per-use cost is way more than a DesignWare license and it
has a royalty attached! This just plain sucks. DWPCI worked and it was
royalty free. How can Synopsys say this is good for their loyal customers?
How do we force Synopsys to rethink their IP strategy?
- [ Color Me Angry ]
( ESNUG 403 Item 13 ) -------------------------------------------- [11/20/02]
Subject: ( ESNUG 402 #2 ) Running Wroute Stand-Alone Uses Up A PKS License
> Yes, you can use wroute in stand alone. You give it the LEF, DEF and
> wroute.cfg. LEF gives it all information on the process technology,
> cells, memories and other stuff. DEF gives the placement of your cells,
> memories, pad, size of floorplan, the ring of alimentation and the
> netlist. Wroute.cfg indicates to wroute where to find the files, how
> you want to route and other stuff.
>
> - Regis Caillet
> DSP Factory Switzerland
From: Noa Safra <rm10192 wandering mmoottoorroollaa pot balm foxfoxfox>
Hi John,
In ESNUG 402 #2, Wroute as a stand-alone tool was mentioned. I just want
to notify ESNUG users that starting from Wroute version 2.3.35, when running
Wroute stand alone, Wroute takes automatically a PKS license!
In order NOT to take it, you should add to your wroute.cfg file:
licenseName Envisia_SE_ultra_place_route
If you run Wroute via SE, it doesn't take a PKS license.
- Noa Safra
Motorola Semiconductor Israel
( ESNUG 403 Item 14 ) -------------------------------------------- [11/20/02]
From: Jia Di <mrjiadi inside of hotmail|liamtoh lot mom catcatcat>
Subject: Customer Runs Into Newbie PowerMill Problems; Seeks Others Help
Hi, John,
I just started to use PowerMill for quick power simulation. I have two
problems on it:
1. When I tried to simulate a design, PowerMill asked me to provide SPICE
netlist of ALL modules used in my design. All my designs are written
in VHDL and synthesized by Synopsys Design Compiler/Analyzer. Then
they are saved in Verilog format. After converting to EPIC using
Vlog2e, these designs contain only Synopsys standard gates like AO5 and
EO1, etc. I think PowerMill should know what they are. But now I have
to provide the netlist of even AN2. Is there another way to do this?
It is hard to provide all of them because the libraries of Synopsys
are un-readable.
2. In simulating some designs, I got error message like "Bus error-Core
dumped". I have no idea of this error. I don't think its my design
that's causing this.
Any ideas, anyone?
- Jia Di
( ESNUG 403 Item 15 ) -------------------------------------------- [11/20/02]
From: Erik Comparini <inirapmoc_n_kire wolfwolfwolf in amis slot palm>
Subject: AMI Semiconductor Seeks IC Design Houses For Overflow Chip Work
Would you know of any IC design houses in the US or Europe that you would
recommend for overflow capacity arrangements? We are seeing a bubble in our
business and need to establish relationships with design house(s) that
(1) have their own design tools (front and back end preferrable),
(2) are proficient in 0.18um/0.25um/0.35um designs,
(3) have a critical mass of 5-10 engineers.
Let me clarify that we are not looking for turn-key design houses, but
rather design houses that can take an RTL design and implement it to gates,
preferrably through placed and routed gates.
I need feedback just as soon as possible. I realize that some of you may
work for this kind of organizations, or may have your own business tailored
around requirements (1) and (2) above, possibly not (3). If that's the
case, even better! Just let me know.
- Erik Comparini
AMI Semiconductor, Inc. Pocatello, ID
( ESNUG 403 Networking Section ) --------------------------------- [11/20/02]
Stockholm, Sweden -- Xelerated R&D seeks a senior engineer with required
experience in Avanti and Synopsys PhysOpt tools. http://www.xelerated.com
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,488 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.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
|
|
