Editor's Note: Three weeks ago, Monterey finally let Richard Goering
actually *talk* to a real live Monetery user (Infineon) to confirm their
first Monterey user tape-out.
http://www.eedesign.com/story/OEG20011002S0084
Monterey seems to be a little slow on the uptake here. Over the past
year, I've counted at least 350 PhysOpt/Magma/SPC/PKS tape-outs versus
Monterey's 1 tape-out. I guess being a day late, a dollar short, and
firmly securing last place in the physical synthesis horse race is
better than not showing up at all!
- John Cooley
the ESNUG guy
( ESNUG 382 Subjects ) ------------------------------------------ [11/15/01]
Item 1: ( ESNUG 381 ) PhysOpt, Cadence PKS, Silicon Perspectives, Plato
Item 2: ( ESNUG 381 #6 ) Verplex LTX/LEC, Circuit Semantics Inc, Prolific
Item 3: ( ESNUG 381 #10 ) Some Gotchas When You Tranlate VHDL To Verilog
Item 4: ( ESNUG 381 #1 ) More On Crazy DC Net Names & Grouping In PhysOpt
Item 5: It's Time To Scrub Your Formality Scripts To Speed Up Verification
Item 6: Nassda, EPIC, Lawsuits, Avanti Hspice, Mentor Mach TA, Celestry
Item 7: ( ESNUG 381 #2 ) ECO's And Arcadia, LEF, DEF, GDSII, PrimeTime
Item 8: I Hate How Verilog-XL Screws Around With My Negative Timing Checks
Item 9: ( ESNUG 381 #3 ) PhysOpt, Scan Chain Order, And Using DFT Compiler
Item 10: ( ESNUG 381 #14 ) Parasitics And PrimeTime In Hierarchical Mode
Item 11: Eight More Sequence (Sapphire) Physical Studio Customer Tape-outs
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 382 Item 1 ) -------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 ) PhysOpt, Cadence PKS, Silicon Perspectives, Plato
> I've heard through the rumor mill that Cadence paid between $200 million
> and $300 million (partially in Cadence stock) for Silicon Perspectives.
> Now you might ask why would Cadence pay such a high price for SPC? From
> my viewpoint, it's a pretty easy decision. PKS, as a product, just hasn't
> caught on with users yet. (Compare those 250+ PhysOpt tape-outs to PKS'
> 13 tape-outs and you'll see what I mean.) ... Buying Silicon Perspectives
> lets Cadence back into the 'power user' design flow.
>
> - John Cooley
From: [ Trojan Man ]
Hi, John,
I hope your assesment on PKS turns out untrue. We're using PhysOpt for some
parts of our design and sometimes I think the tool creates more problems
then it solves. Synopsys has been very supportive in our using PhysOpt, but
we are mostly doing some things in a non-Synopsys recommended way:
1.- Using DC (not PhysOpt) to get from RTL to gates. (Maybe they do
recommend this for large designs. I'm not sure.)
2.- Have a lot of clock gating logic (for functionality not just power.)
3.- We use transparent latches in many cases.
Quite often Synopsys comes to us with a solution to our PhysOpt issues, but
they're so involved, we don't implement them. Instead we just stick to our
what works now workarounds. (I'm trying to say that I may not be giving
PhysOpt a completely fair shake here.) Our biggest PhysOpt problems are:
1.- Placement congestion -- Blocks that would route with SE placement
needed to be made larger by 10% to 20% to route w/ PhysOpt placement.
2.- Placement of clock gating elements -- their Tcl scripts to solve
this on SolvNet are incomplete.
3.- DEF out of db2def -- DEF headers and certain cell attributes are
not retained from the original input DEF. We are not able to take
the results straight into Warp Route without making modifications
to the file.
4.- Runtime -- 50 K instances used to take overnight. We had do more
floorplanning because of these runtime issues. It now takes 5 hours
to do 15 K to 20 K instances in PhysOpt. I guess that's OK, but it
required floorplanning our design into 20 K blocks.
5.- name_rules / uniquify bug -- PhysOpt behaves differently than DC; we
got multiple instances with the same name.
6.- PhysOpt doesn't automatically handle propagation of clocks through our
gating logic. It's not easy to get PhysOpt to understand our complex
clock gating logic. It's handles NANDs and NORS; anything bigger (or
more complex) and PhysOpt is lost.
Again, on some of these problems we have not fully explored the fixes from
our Synopsys FAE, but right now we are evaluating PKS. I think PKS would
probably help with 1, 3 and 5. PKS will probably score the same as PhysOpt
on issues 2, 4 and 6. We expect PKS will also definitely have other issues
that we have never seen as well. We just hope that PKS is available as a
back-up tool if PhysOpt fails to deliver. Please keep me anon.
- [ Trojan Man ]
---- ---- ---- ---- ---- ---- ----
From: [ Msg 10159 on Yahoo CDN ]
CDN's buy of SPC is brilliant not only in that it gives CDN a first-class
tool, but more in that it breaks up the purported SPC & Plato alliance.
Without SPC, Plato is "just another router" (albeit a very good one), and
its influence will be much dampened.
CDN's real intent is to prevent SPC + Plato from happening, as it'd pose a
powerful threat to CDN's (and AVNT's) core business.
My prediction? From now on CDN will start actively making SPC *NOT* working
with Plato. Too bad for Plato...
- [ Msg 10159 on Yahoo CDN ]
---- ---- ---- ---- ---- ---- ----
From: [ Msg 10162 on Yahoo CDN ]
Are we going to see the same kind of bail-o-rama that we saw when CDN bought
Ambit? Most of the talent from Ambit left in weeks (one friend at Ambit
told me he left as soon as humanly and contractually possible) or are there
"golden handcuffs"? Many of the SPCers are "former CDNers" so they are very
likely to become "former CDNers againers"...
- [ Msg 10162 on Yahoo CDN ]
---- ---- ---- ---- ---- ---- ----
From: [ Msg 10166 on Yahoo CDN ]
On the vesting schedule - It all depends on how good a negotiator the SPC
team was. I rank them among the best, especially with hindview of what
Prakash was able to do with Ambit. I've heard that much of the SPC vesting
is immediate with a small kicker for staying similar of Ambit, at least for
the executroids.
- [ Msg 10166 on Yahoo CDN ]
( ESNUG 382 Item 2 ) -------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 #6 ) Verplex LTX/LEC, Circuit Semantics Inc, Prolific
> We are trying to verify our standard cells by ensuring that vendor
> provided Verilog models are equivalent to the SPICE netlist. Using Tuxedo
> LTX, we tried extracting a Verilog model from the SPICE netlist and then
> verifing equivalency between the extracted Verilog model and golden
> Verilog model by running Verplex LEC. This flow failed to detect a
> previously known dynamic glitch caused by a pass transisitor in one of
> the standard flops. It appears that the only way to detect this kind of
> glitch is through SPICE simulation. I would like to know if there's an
> automated way to generate exhaustive input stimulus to verify
> functionality of sequential cells.
>
> - Dhruba Kalita
> Intel
From: Howard Landman <howard.landman@vitesse.com>
Hi, John,
In theory Dhruba would have to try all possible transition combinations (and
for SPICE, vary the relative timing of the changing signals as well.) There
are 2^n combinational input vectors for an n-input cell, so to look at all
possible transitions requires (2^n)*(2^n) = 2^(2*n) vectors. For a 6-input
cell that's 4K vectors, and it goes up by a factor of 4 for each additional
input.
But even that doesn't handle things like setup and hold time, which typically
are done by binary splitting searches. For each logic state for which you
want to get setup or hold info, such a search will take k simulations, where
k is the number of bits of accuracy you want in your result. (Assuming you
do it the standard naive way, see discussion below.)
There are companies which sell cell characterization software, such as
Circuit Semantics, Inc. (http://www.circuitsemantics.com), that claim to
handle all this automatically. We've had fairly good results with CSI's
software - there are some knobs that need to be set carefully and there are
some problems with generated Verilog models, but overall it seems to work.
Other companies with related products or services include:
Prolific, Inc. (http://www.prolificinc.com)
APT Software (http://www.aptsoftware.com)
Silicon Metrics (http://www.siliconmetrics.com)
Library Technologies (http://www.libtech.com)
Z Circuit Automation (http://www.z-circuit.com)
I think Compass had something in this area too, but I don't know what's
become of it.
None of the characterization software I've seen has handled the subtle
tradeoff between setup, hold, and clk-to-Q delay in a way I would consider
correct. Partly, this is a function of .lib format, which I feel is
fundamentally broken in this regard. If you do a 3-D plot of setup, hold,
and clk-to-Q for any given FF you will see that they trade off against each
other in roughly hyperbolic fashion. Most systems characterize setup at
infinite hold, and characterize hold at infinite setup, and then guardband
them using some fudge factor. But it's possible for that process to arrive
at setup and hold numbers such that, if you just barely meet the setup time
and just barely meet the hold time, the FF doesn't work! Plus, as you
approach the minimum setup or hold, the clk-to-Q delay increases. The .lib
format has no mechanism for expressing any of these tradeoffs, even if you
gather all the needed data. That forces the guardbanding to be unnecessarily
large, which in turn reduces the accuracy of timing analysis and synthesis.
- Howard Landman
Vitesse Semiconductor Longmont, CO
( ESNUG 382 Item 3 ) -------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 #10 ) Some Gotchas When You Tranlate VHDL To Verilog
> We need to do a design involving mixed VHDL & Verilog. Our 1st preference
> would be to translate the VHDL parts to Verilog (our standard language)
> for maintainability. I would like to question your readers regarding
> their experience with translation tools.
>
> - Daniel Szoke
> National Semiconductor Israel
From: "Alessandro Fasan" <alfa@synopsys.com>
Hi, John,
I answered this question when it came up in ESNUG 341 #10. I sent you a
paper that you posted at http://www.deepchip.com/downloadpage.fhtml, as #26.
In that paper I described that at my prior job, I worked on converting from
VHDL to Verilog a big portion of a MPEG2 decoder. I evaluated available
mixed HDL solutions and 3 VHDL-to-Verilog translators. Since our design
environment was based on VCS and our VHDL portion was big but very stable, I
ended up converting the VHDL to Verilog using the vhdl2verilog translator
from Alternative System Concepts, Inc.
My project was successful because I had access to my company's best R&D
resources (A. Fedeli, co-author of the paper, and U. Rossi) and to
Formality. Without equivalence checking you never know if your translator
did the right things!
That experience taught me that there are enough differences between VHDL and
Verilog that in most cases translation can not be done automatically while
maintaining the same quality of results or simulation performance. Only in
highly constrained design coding styles could you expect to get a good
automatic conversion. In most cases you would still need to do manual
translation of portions after doing equivalence checking (to guarantee
correctness) and simulation profiling (to preserve performance).
If engineering resources and time are critical factors for your project, and
if your VHDL code is not synthesizable or changes often, then I recommend
you look into simulating in a mixed HDL environment rather than performing a
language translation.
Here is some background on what kind of performance issues you should expect.
Today, all major simulators offer support for Mixed HDL environments. But
since these two different languages use separate simulation algorithms, there
will usually be some performance penalty when simulating two languages.
How much penalty depends on the simulation technology and how much the two
languages interact.
In the high end simulators, advanced compiler optimizations are applied
globally (i.e. across Verilog modules or VHDL processes) to increase sim
performance. But individual language semantics (VHDL delta cycle vs. Verilog
no delta) tend to restrict the scope of most optimizations to a specific
language. Basically this means that the more you mix & match the languages,
the less optimizations you can use.
If you do simulate using mixed VHDL/Verilog source, to maximize performance
remember to keep the interaction and boundaries between the two languages to
a minimum. Be cautious about where and why you plug in a different language.
Use it for large design blocks that cannot easily be rewritten. Mix the
languages closer to the top of the design (allowing more compiler-based
optimizations to be applied.) Mixed languages is still quite efficient if
used only for a few large IP blocks, or for plugging in some VHDL Vital
modules into a Verilog gate netlist.
And of course use a high performance compiler technologies, like those
found in VCS, NC-Verilog, Scirocco, and NC-VHDL.
- Alessandro Fasan
Synopsys, Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Alan MacKenzie <Alan.MacKenzie@nsc.com>
John,
I have been doing some work on this to convert the a design we have got from
a Danish company into Verilog. Up until now, we have just simulated with
ModelSim, but the majority of our simulations are done in Verilog, so we have
to maintain two environments which is a bit awkward.
I managed to find and evaluate two tools:
- xhdl from X-TEK, Inc.
- vhdl2verilog from Alternative System Concepts, Inc.
for the design I had. Both tools converted most of the code, but ASC's
vhdl2verilog was definitely the better of the two tools. Both tools made
mistakes, but the vhdl2verilog tool made fewer mistakes. The xhdl tool is
cheaper as a result.
In both cases the original VHDL was modified to make the tools job easier.
The resulting Verilog output had to be modified to remove the bugs the tools
each had added. If the VHDL design is going to be updated regularly and
then converted to Verilog each time, it is beneficial to change your VHDL
source code to absolutely minimise the amount of manual work required on the
Verilog. The design I used was 60 K gates, so it was pretty large and it
only required one major change to remove VHDL aliases plus about a dozen
other minor changes to the VHDL and then about half a dozen minor changes to
the resulting Verilog output -- so I don't want to give the impression that
it required a large ammount of effort or that it radically changed the
original VHDL design but this will inevitably depend on how you have coded
your design. Here is what ASC's vhdl2verilog couldn't handle:
- complicated reset logic had to be removed from a process statement.
Only a simple reset signal could be handled.
- Verilog has no equivalent to the generate statement. Both tools can
roll out generate statements but I tried converting a codec design
which had parameterised generate statements but this is not possible.
Not the tools' fault.
- couldn't handle multi-dimensional arrays of data. This can be handled
in Verilog with a single dimensional array but the conversion is not
simple and can't be done by the tools automatically.
- doesn't handle VHDL aliases. Claim to handle them but they don't.
- can't handle power operator because Verilog doesn't have one.
Supposed to be an update to vhdl2verilog so it can handle powers of 2
but I never used it.
One of the annoying things about the tool was that it wouldn't warn you of
VHDL constructs it couldn't handle. It just produced rubbish code!
Critical to using this tool reliably was we used Avanti Chrysalis formal
verification to compare the Verilog with the VHDL. This was a relatively
easy process and it picked out several issues that the simulations missed.
To answer Dan's specific questions:
> 1. What VHDL constructs are/were translated
All constructs except the ones I have listed above were handled, but the
design I had probably did not use the full language. ASC won't handle
testbenchs either.
> 2. Quality (readability) of the translated Verilog
ASC's output seemed to be OK. Maintained the comments. I didn't do any
work with the design after this so it is difficult to critize.
> 3. Compare synthesis of: VHDL -> gates VS. VHDL -> Verilog -> gates
Ran synthesis to check it compiled, but I didn't do a comparision. Assumed
that it would be the same or very similar because the designs were
functionally identical, but synthesis is a non-deterministic process, so I
guess this may be naive.
> 4. Compare sim of: mixed VHDL-Verilog VS. translated Verilog-Verilog
Not sure what Dan wants to know. Mixed signal simulation has some issues,
but the ModelSim tool works well. The main problem as mentioned above is
that two simulation environments had to be maintained and there is always
the problem of timing hazards that cause a problem with one version of
Verilog but not with another plus being forced to use a tool you aren't
familiar with.
For ASC vhdl2verilog we have had several different prices which tend to get
lower as the end of quarter gets closer. The last quote was $10K for a node
locked license but that offer ran out at the end of september. Typically
they price around $20K to $32K, with $4K to $5K yearly maintenance.
The xhdl tool was about $13K for floating and $11.5K for node locked.
- Alan Mackenzie
National Semiconductor Greenock, Scotland
---- ---- ---- ---- ---- ---- ----
From: Daniel Szoke <Daniel.Szoke@nsc.com>
Hi, John,
I know you like follow-ups from the people who post questions on ESNUG.
Here's my follow-up to my VHDL-to-Verilog translator tool question:
1) I started out this journey (before the ESNUG email) with a web link:
http://www.vhdl.org/comp.lang.vhdl/FAQ3.html#verilog2vhdl
We tried their "vhd2vl" tool on a block of VHDL and it failed on
many types of VHDL language constructs.
2) An EDA vendor suggested mixed Verilog-VHDL simulation. We do not like
this direction because:
a) We want to learn, modify and maintain the IP. To do so in VHDL
would mean too big an investment in a two language environment.
b) I heard at the Verisity Users meeting that there are a lot of
problems with the mixed Verilog-Vhdl simulations.
3) InterHDL (now in Avanti) have an internal effort to write a VHDL to
Verilog translation tool.
My past experience (in automatic Pascal to C translation) makes me a skeptic.
After all, why would there be Verilog/VHDL wars if translation was so easy?
Still, finding ways to minimize the pain of conversion is important.
- Daniel Szoke
National Semiconductor Israel
( ESNUG 382 Item 4 ) -------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 #1 ) More On Crazy DC Net Names & Grouping In PhysOpt
> ... oddities with DC 2000.11 and 2001.08-1 when going into our PhysOpt
> flow (gates-to-placed-gates). DC appears to keep multiple names of
> particular items within the database for nets and ports and may write out
> a different name to a Verilog file vs a .db file.
>
> What may be called port "foo" in Verilog could be referenced as "nm156"
> in the .db file. Your chances of finding the right one is about as lucky
> as hitting a home run into the right-field pool off Schilling or Johnson.
>
> - Gregg Lahti
> Corrent Corp. Tempe, AZ
From: "Gregg Lahti" <gregg.lahti@corrent.com>
Hi, John,
To recap, sometimes designs in PhysOpt need to get grouped into different
hierarchy for various reasons, such as feeding PhysOpt with a sweet-spot
gate count of about 150K gates or globbing designs into clock domains. DC
will allow grouping, but signal names may get changed into weird nXXXX
values. This makes downstream operations such as debugging, budgeting, etc.,
difficult. I posted the switches we used to keep this 'feature' of DC down
to a minimum using only Verilog netlists in ESNUG 381 #1.
However, using Verilog-only netlists isn't always feasible. Case in point:
working with scan or clock-gating designs. DC makes full use of the
attributes fields and attaches clock-gating attributes on the clock gating
cells of the netlist. Going to a Verilog netlist from the .db file
eliminates these attributes and will cause serious pain during an
"insert_dft" operation in PhysOpt when it fails to find a scan enable pin on
your clock-gating latch. The .db file(s) must be used when going from DC
to PhysOpt for G2PG operation, but that crazy naming issue still requires
resolution at grouping to yield a useful netlist.
A workaround is to: 1.) write out the top-level of the hierarchies that you
want to keep naming convention boundaries on into a netlist, 2.) remove
the design, and 3.) then read it back. This method works well in the case
of grouping designs together where DC forgets about the actual name and uses
the (infernal) internal nXXXX name. Sounds odd, but here's the steps:
current_design rush;
change_names -hier -rules layout_friendly_verilog -verb;
group -design_name signals -cell_name signals {neil geddy alex};
write -f verilog -o signals.v signals; #NOTE! no -hier option!
remove_design signals;
read_file -f verilog -netlist signals.v;
link;
write -f db -h -o rush.db rush;
The first change_names step is customized to our back-end layout tool. The
last write step is to write out the entire netlist, but with the hierarchy
boundary netnames and the cell attributes preserved. We write out the
clustered items out so we can separately send these through our PhysOpt flow
while taking the entire netlist through our layout tools or RTL floorplanner.
This also works pleasingly well in our DC/PrimeTime/DC/PhysOpt gyration when
applying constraints or budgeting in the PrimeTime operation, since the port
names are now set back to the original design. (It would sure be nice for
PrimeTime to write out a constrainted .db file and eliminate the step back
to DC.)
I've also used the above method to effectively remove unconnected ports in
sub-hierarchy designs. For those that haven't tried, DC will error on the
link command if you do a remove_port on an unconnected port of a sub-design.
(I found a STAR on this dating back to ver 3.0 with the resolution that it
wouldn't be fixed.) The design at that point may not even write out
correctly, and I've had it not write out the sub-design of the removed port
on a 'write -hier -f verilog' command. The remove_unconnected_ports command
didn't work in my situation since the design had multiple instances of a
design and wasn't non-unique.
- Gregg Lahti
Corrent Corp. Tempe, AZ
( ESNUG 382 Item 5 ) -------------------------------------------- [11/15/01]
From: Steve Lamb <slamb@synopsys.com>
Subject: It's Time To Scrub Your Formality Scripts To Speed Up Verification
Hi, John,
This summer we made a significant change was made to the way Formality works.
The 2001.06 release of Formality introduced a combination of flat and
hierarchical verification flows. (I'll skip the details and reference
the interested reader to the "Hier-IQ" white paper we published on our web
site.) From a user's perspective the important thing is that we moved away
from the automatic bottoms up hierarchical flow that had been the default.
As a result some of the variables users have gotten used to setting to
overcome the shortcomings of that approach are no longer needed (and in fact
slow the tool down.) These changes were in the 2001.06 Release Notes, but 5
months later I still see these "legacy" variables in many user's scripts.
I'm now asking Formality users to PLEASE scrub their scripts! Here is a
list of the common culprits:
1) Stop using 'set_parameters -flatten'
To protect users from false negatives due to boundary optimization,
Formality would automatically gradually flatten the design stopping
at each level to recheck the design. A nasty runtime penalty was
paid in those cases. Many users set this "flatten" parameter to take
Formality out of this hierarchical mode and force it to verify the
designs flat. This saved users from occasional long runs but also
prevented them from realizing very quick ones as well, not to mention
always maximizing memory consumption. Many users did not like to be
in the game of predicting which designs to flatten and which to leave
alone and just flattened them all.
In the new methodology, compare points are considered in their entire
(flat) context. So Formality no longer verifies designs bottoms up.
However, it does now make use of some hierarchical information to
achieve the performance and memory advantages of a hierarchical
verification run. The trouble for existing users is that the -flatten
option prevents the tool from taking advantage of this information.
In other words don't set this parameter any more (especially at the
top level of the design.) It can only slow the tool down.
In limited cases -flatten may improve performance if strategically
used on lower-level blocks with extensive boundary optimization.
2) Stop using 'set_equivalence -propagate'
Another shortcoming of the old Formality bottoms up hierarchical flow
is that some times top down knowledge is needed to understand "one to
many" port mappings of the sub-blocks following clock tree insertion
or the buffering of reset and test enable lines. Looking from the
bottom up, the tool would see numerous port mismatches on the sub-
blocks and be forced to gradually flatten the design to understand how
they should be resolved. To get past this problem without having to
flatten the entire design, the user could use the 'set_equivalence
-propagate' command. By setting these at the top level Formality would
essentially pre-verify the buffer trees and note the sub-block port
implications prior to beginning the bottoms up hierarchical flow.
Now that designs are verified in their flat context with the new
technology, this command should no longer be used for top-level
verification since it will merely result in wasted CPU cycles.
The 'set_equivalence -propagate' command is still available for
verification of lower-level blocks in isolation while using the full
design context to propagate constraints.
3) Stop setting up manual hierarchical verifications
Many users got used to the memory required when 'flatten' was set.
As a result, they adopted a manual hierarchical flow. That is, they
did many smaller manual Formality runs instead of one large Formality
run. The process of setting these multiple verifications up is time
consuming and not much fun.
The new Formality uses less memory. Users can now expect to verify
~2K gates/MB of RAM. In other words, somewhere between 6 and 8 million
gates of synthesizable logic can now be verified in a 32 bit machine
with 4 gig of RAM. This means many designers can now verify their
whole chip in one run with minimal user intervention required. Yet I
still see many users taking a manual hierarchical approach. Please
check the memory consumption on your next Formality run; it may be able
to do it in one chunk, saving you lots of work and multiple runs.
If your designs exceed 6-8 million gates, we do have a 64 bit port of
Formality for those that want to acquire those workstations. (Worse
yet, you'll probably butt heads with the physical designers in your
company who are already using every 64 bit machines your company has
already!)
4) Other switches that are no longer needed now that designs are verified
in their flat context:
verification_override_inout_port_direction
verification_block_timeout_limit
verification_remove_passing_subdesigns
These commands are now obsolete and should also be removed from
your Formality scripts.
I hope this letter helps our existing Formality users noticably speed up
their verification runs.
- Steve Lamb
Synopsys, Inc. Marlboro, MA
( ESNUG 382 Item 6 ) -------------------------------------------- [11/15/01]
Subject: Nassda, EPIC, Lawsuits, Avanti Hspice, Mentor Mach TA, Celestry
> Thank God, for the near-SPICE guys. If you're willing to be 1% to 5% off
> from a true SPICE sim, the near-SPICE guys will give you a 100X speed-up.
> EPIC pretty much owned this niche throughout the 90s. They were the "hot
> technology find" of DAC'94. Synopsys aquired EPIC in 1997 for $440
> million. Most of the original EPIC team left Synopsys within 2 years.
>
> Now there's a new near-SPICE company, Nassda, that's trying to steal this
> niche from Synopsys EPIC. "The Epic tools are getting pretty old when run
> against new designs," wrote John Szetela of AMD. "Nassda looks very good
> if you just want a super SPICE."
>
> - from "Back To The Future" column
From: Peter Denyer <peter.denyer@sun.com>
And now, John, we have Synopsys trying to stamp out Nassda as a competitor
by saying these ex-Synopsys folks misappropriated Synopsys IP. It's
getting to the point where an EDA developer can't take on a new job without
threats of lawsuits. What's this EDA industry coming to?
- Peter Denyer
Sun Microsystems
---- ---- ---- ---- ---- ---- ----
From: "John Lee" <jolly@avanticorp.com>
Hi John,
Good article; I enjoyed it! But you forgot to mention Avanti Star-Hspice
was the biggest player in this market. The Dataquest numbers give us 78%
market share.
Also the new "fast-SPICE" simulators (like Star-Sim and Nassda) rely upon
hierarchical techniques to get speed. The key issue is not how to solve a
large number of transistors quickly, but how to handle post-layout
parasitics that are:
a. Flat in nature, hence destroy the notion of hierarchy.
b. Necessary for any timing, power, IR, EM or noise analysis.
c. Overwhelm simulators in volume of parasitics.
d. Confound users, because the flows are so difficult to set-up. Ask
people how much time they can spend setting up a post-layout
back-annotation flow into schematic netlists.
So the issue is not how to simulate transistors --- we've known how to do
this for a while --- but how to simulate transistors with flat layout, while
preserving the benefits of hierarchical simulation. Star-Sim plus Star-RC
is our solution to this problem. We've been hierarchical for 2 generations
now, and we've focused on is how Star-Sim handles parasitics faster.
- John Lee
Avanti Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: "Daniel Payne" <daniel_payne@mentorg.com>
Hi, John,
I agree with your observations on the Spice world.
Mentor also has a big, fast Spice tool, called Mach TA. Our customers have
seen it perform 4X faster than Hsim on PLLs and any design that has
extracted RC interconnect.
- Dan Payne
Mentor Graphics
---- ---- ---- ---- ---- ---- ----
From: "Ed Hepler" <elh@ece.villanova.edu>
John,
You may have forgotten about Lsim from SCS (later acquired by Mentor). It
had Adept mode switch level simulation back in the mid-late 80s that was very
good. Since Lsim was "mixed-mode", part of your circuit could be at the
transistor switch level, other parts could be at the transistor adept level,
while other parts could be described using their behavioral language (M). M
allowed one to do things that are still not possible with VHDL or Verilog.
Later a VHDL front end also became available. Since M was really a superset
of C, you could say that it was the first C based simulation language. :-)
If you wanted "real" SPICE accuracy, you could tell Lsim to send that part of
your circuit to HSPICE (either running on the same host machine or some other
one on the network.) All the results were reported back in the same waveform
displays through Lsim.
Many of the SCS tools were way ahead of their time. Unfortunately, I don't
think Mentor knew what they had purchased and many of them "disappeared" in
favor of "Falcon based" tools that didn't have all of the nice features.
- Ed Hepler
Villanova University
---- ---- ---- ---- ---- ---- ----
From: Tom Arns <tarns@SandCraft.com>
Hi John,
Mentor is also a player in the near-SPICE market with Mach-TA. We have a few
copies here, and are able to simulate fairly large datapaths with it. It's a
step up from ADM, which is now owned by Avanti, and called Star-SIM. Avanti
had not been keeping ADM up-to-date, and lost a lot of the business to Nassda
and Mach-TA. They have recently come out with a version of which is intended
to compete with Nassda, but I haven't benchmarked it.
We have benchmarted Nassda, but didn't see enough advantages over Mach-TA to
get any licenses. Nassda's fairly expensive.
With these new high speed SPICE simulators, the limiting factor is often
extraction, rather than simulation capacity. Who cares if you can simulate
your cache in a few hours if it takes 3 weeks to run a detailed enough
extraction?
- Tom Arns
SandCraft
---- ---- ---- ---- ---- ---- ----
From: [ Vault 713 ]
Hi John,
Interesting timing of your Gadfly "near-Spice" article. We are looking at
Celestry's UltraSim and there was no mention about them. We're planning to
evaluate the tool in the near future. Unfortunately, our evaluations are
often far too brief and only tell us part of the story. If we get any
meaningful data, I'll let you know.
I checked your DAC '01 write up and found no quotes from actual users of
Celestry. The only quotes were from people who have seen their demos and
presentations. Is there any chance of soliciting data from actual Celestry
users in you next ESNUG mailing? Celestry was willing to give us user
references, but I prefer ESNUG information than that of handpicked
vendor references.
As usual, if you quote me, please keep my name anonymous.
- [ Vault 713 ]
( ESNUG 382 Item 7 ) -------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 #2 ) ECO's And Arcadia, LEF, DEF, GDSII, PrimeTime
> In our sign-off procedure we use Arcadia and PrimeTime. We use Arcadia
> for RC extraction, and Primetime reads the DSPF file generated by
> Arcadia for static timing analysis. In our regular flow, the input
> to Arcadia are the LEF and DEF files. When we're doing a manual ECO, the
> data of the ECO is in GDS2 format only. To extract the data, we need to
> run LVS on the GDS2 data and then invoke Arcadia. The output DSPF
> generated by Arcadia (in this case) is in transistor level, while PrimeTime
> annotates only gate level DSPF!!! This is a very severe limitation! The
> timing on the ECO nets cannot be verified.
>
> - Eyal Landesberg
> Zoran Israel
From: Ken Maples <maples@synopsys.com>
John,
The fundamental problem Eyal has is that once his database has been
converted to GDSII, all the LEF/DEF information has been lost. There is no
way for any extractor to know what the gate level primitives are such that
they could be reformed at the gate level and fed back to a gate level timing
engine like PrimeTime.
There really are only two solutions to such a problem.
The first would be to not smash the LEF/DEF data into GDSII. His ECO edits
would need to be made on the LEF/DEF data. The other solution would be to
run a transistor level static timing engine such as PathMill. I'm not
trying to get Eyal to buy more Synopsys tools - it's just that the flow he
is proposing is trying to merge a gate level tool to a polygon level
database. It just won't fit.
If Eyal would like to discuss this with us in more detail, we'd be happy to
discuss alternate ways to implement his ECO's. Tell him to feel free to
contact me directly.
- Ken Maples
Synopsys, Inc. Mountain View, CA
( ESNUG 382 Item 8 ) -------------------------------------------- [11/15/01]
From: Stefan Griebel <sgriebel@audiologic.cirrus.com>
Subject: I Hate How Verilog-XL Screws Around With My Negative Timing Checks
Hi John -
This Verilog-XL "bug" shows up when back-annotating an SDF file with negative
hold times and using the +neg_tchk option. Verilog should use the negative
hold times correctly, but instead will set the negative values to zero
without issuing an error or warning.
The problem is caused when an SDF file has 2 or more timing checks w/ respect
to an event edge, (like posedge clock) and the violation regions created by
these timing checks do not overlap each other. This condition causes
the negative timing check algorithm not to converge. Verilog-XL forces
convergence by setting negative values in the timing check to zero.
Verilog-XL sets one value to zero and then checks to see if the timing
converged. The process is repeated until the timing converges or all the
negative values are set to zero. Example:
....4....3....2....1....0....1....2....3
_______________
clock ________________________/
Positive and negative timing checks in SDF file
....4....3....2....1....0....1....2....3
___________________________________
d(pos) ____/____/
___________________
d(neg) \____\____________________
(TIMINGCHECK
(SETUPHOLD (posedge D) (posedge CK)
(4.000:4.000:4.000)(-3.000:-3.000:-3.000))
(SETUPHOLD (negedge D) (posedge CK)
(2.000:2.000:2.000)(-1.000:-1.000:-1.000))
)
Positive and negative timing checks in Verilog-XL after convergence. Both
negative hold values set to zero.
....4....3....2....1....0....1....2....3
___________________________________
d(pos) ____/___________________/
________________________
d(neg) \_________\_______________
After annotation:
$setuphold(posedge CK, posedge D, 4, 0);
$setuphold(posedge CK, posedge D, 2, 0);
Test data changes at (0.5)
....4....3....2....1....0....1....2....3
______________________ _________________
d ______________________X_________________
The SDF file has a violation region of (4, -3) for the positive edge of (D)
and (2, -1) for the negative violation region. After convergence both
negative hold values get set to zero, (4, 0) for positive edge and (2, 0)
for negative edge.
During simulation the (D) input is changed (0.5) time units before the
postive edge of (CK). This should be a good time, but a setup time
violation is issued.
Solutions to bypass this problem (from Cadence):
1). You have to make the violation regions overlap a little bit. This
way Verilog-XL will converge. The SDF file has to be edited by hand
to change the values in the timing check so that the violation regions
overlap. Scripts can be created to help automate to the editing
process. (We do not have a script for this purpose.) You can avoid
this non-convergence by hand-editing the timing checks in the HDL or
in the SDF file to create some overlap.
2). If you use NC-Verilog from the LDV3.3 or LDV3.2 (with latest ISR),
NC-Verilog has two new options address this non-convergence issue.
a. -EXTEND_TCHECK_Data_limit <percent_relaxation>
b. -EXTEND_TCHECK_Reference_limit <percent_relaxation>
The -extend_tcheck_data_limit option changes the hold or recovery
limit in the timing checks so that the violation regions overlap by
at least two units of simulation precision.
The -extend_tcheck_reference_limit option changes the setup or removal
limit in the timing checks so that the violation regions overlap by at
least two units of simulation precision.
The percent_relaxation argument in both is the maximum percentage
increase allowed in the timing violation window to achieve the overlap.
Both of these solutions offered by Cadence only bypass the problem, possibly
making it worse; they do not actually fix it! These solutions change the
actual timing characterization of the particular cell in question rather than
going to the root of the problem which is that Verilog-XL can't handle
non-overlapping violation regions. When I inquired as to whether this
"convergence" issue would be fixed, I was told, "No. That is how Verilog-XL
will continue to work". Has anyone else run into this before, and possibly
come up with a better solution? Are there any opinions as to how major of
an issue this really is? Any feedback would be greatly appreciated, but
I'm also happy just to share my findings.
- Stefan Griebel
Cirrus Logic
( ESNUG 382 Item 9 ) -------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 #3 ) PhysOpt, Scan Chain Order, And Using DFT Compiler
> For us, the end of a scan chain is a flop that is also a primary Output,
> so we don't need a MUX. Why would one want a lockup latch at the end of
> a scan chain? Well, we know what those things are used for, shifting
> reliably across different clock domains. But I associated the "end of
> the chain" as the primary scan out, and where's the other domain after
> that?
>
> - Paul Schnizlein
> Agere Systems Austin, TX
From: Lars Bo Graversen <larsg@mips.com>
Hi John,
One use of having a lockup latch at the end of your scan chain(s) is if the
design you are inserting the scan chain in is not a full chip, but a piece
of IP (soft- or hardcore) which other users will integrate in a SoC and then
connect the scan chains in the IP with the outside scan chains. In this
case, the flop connected to the IPs primary scan out could be in another
clock domain. In this case, having a lockup latch at the end of the scan
chain inside the IP is very useful.
- Lars Bo Graversen
MIPS Denmark
---- ---- ---- ---- ---- ---- ----
> If you are starting with a scan stitched design and you set the scan state
> to scan_existing, will PhysOpt know to ignore the scan chain connections in
> it's placement? This seems a very important issue; if PhysOpt does not
> ignore these connections then the placement will be non-optimal. PhysOpt
> should be able to do this because it has all the information it needs. It
> knows the scan chains are stitched and it knows what nets are involved.
> However if PhysOpt does not use this information when it does the placement
> it is not doing as good of a job as it could.
>
> I would be interested in knowing what PhysOpt does in this case.
>
> - Paul Fletcher
> Motorola Chandler, AZ
From: Vandana Kaul <vkaul@synopsys.com>
Hi John,
PhysOpt will not do anything special for scan nets when you bring a scan
stitched netlist into PhysOpt/DFT Compiler. It will consider them for
placement, as well as design rule fixing. You can disable design rule
fixing on these nets by specifying them as ideal (via the "set_ideal_net"
command), but PhysOpt will not ignore these nets for placement during
the "physopt" command. Therefore, as Paul suggests, the placement will
not be optimal in this case.
There are additional items to keep in mind when bringing a scan stitched
Verilog netlist into PhysOpt/DFTC:
1. You need to tell PhysOpt about any non-scan flip-flops in the
design using the command "set_scan_element false."
2. You need to identify the scan ports using the "set_signal_type"
command.
3. When you run "insert_dft -physical" after running the "physopt"
command, PhysOpt/DFTC will not repartition the scan chains. In
other words, scan reordering will occur within a chain, not
across chains.
I hope this helps Paul!
- Vandana Kaul
Synopsys, Inc. Mountain View, CA
( ESNUG 382 Item 10 ) ------------------------------------------- [11/15/01]
Subject: ( ESNUG 381 #14 ) Parasitics And PrimeTime In Hierarchical Mode
> By the way, I would also be really interested in knowing if others are
> able to run PrimeTime in a hierarchical mode using detailed parasitics.
> This involves using read_parasitics -increment to read in each block
> level dnet.spef file and then the top level. I have tried this and
> the tool gives a load of false errors since it has not gotten the full
> RC network yet. ... The report_annotated_parasitic command does not
> work well, so you have to write tcl scripts to figure out if all the
> parasitics are annotated. ... The compete_net_parasitic command is also
> error prone and should not be a global command.
>
> - Bruce Zahn
> Agere Systems Allentown, PA
From: Sumir Kalucha <kalucha@synopsys.com>
Hi John,
The false errors that Bruce Zahn is commenting about is due to the default
behavior of the read_parasitics command in PrimeTime.
During parasitic backannotation, PrimeTime checks to make sure there are no
nets that are incompletely backannotated with R's and C's. If there is an
incompletely backannotated net, PrimeTime will issue an error message,
specifically DES-026.
In the case of a hierarchical design, there are multiple parasitics files
that are incrementally read in one by one and stitched together by PrimeTime
(read_parasitics -increment). As these parasitic files are read in, an
incomplete backannotation check is performed. Naturally, all of the boundary
nets may be incompletely backannotated nets since other segments may reside
in parasitics files that have not been read in yet, so there will be a lot
of false error messages. The question is how can these false errors be
suppressed.
The suggestion by Al Jacoutot to use read_parasitics -quiet option works but
with the caveat that this will suppress both the false messages and the
valid messages. To check for valid messages, the following is a better fix:
read_parasitics -quiet -increment block1.spef
read_parasitics -quiet -increment block2.spef
read_parasitics -quiet -increment top.spef
report_annotated_parasitics -check
This flow allows the messages to be suppressed during the reading of
parasitics and still allows for a check of incompletely backannotated nets
after all files have been read in.
- Sumir Kalucha
Synopsys, Inc. Mountain View, CA
( ESNUG 382 Item 11 ) ------------------------------------------- [11/15/01]
From: George Serhan <gserhan@mmcnet.com>
Subject: Eight More Sequence (Sapphire) Physical Studio Customer Tape-outs
John,
I wanted you to update the statistics on the tape-outs with the Physical
Studio of Sequence/Sapphire. We've completed four 0.18 um, 100 - 200 Mhz
tape-outs. We expect another 250 Mhz, 0.13 um tape-out soon, too.
- George Serhan
AMCC
---- ---- ---- ---- ---- ---- ----
From: Reza Hariri <Reza.Hariri@SiliconAccess.com>
Hi John,
I understand you're tabulating tapeouts again so here are a couple more to
add. These are cumulative, i.e. they include the previous ones I
reported last year:
Two designs in TSMC 0.18, 133MHz
One design in TSMC 0.13, 233 MHz
Our flow uses Silicon Perspective for chip-level floorplaning, chip level
CTS, rule based repeater insertion, and occasionally to do block level cell
placement and first pass timing closure on some blocks. We use Sequence
Physical Studio for all blocks and chip-level timing closure and noise
closure. We used Avanti Apollo for block cell placement (ones not placed
by SPC), route, CTS and chip level route.
- Reza Hariri
Silicon Access, Inc.
---- ---- ---- ---- ---- ---- ----
From: Tom Arns <tarns@SandCraft.com>
The Sequence (Sapphire) folks wanted me to mention that we had done another
tape-out with Formit. I'm not sure if you're still tracking this, but
everyone in the timing driven placement business is still very focused on
your tape-out count.
The tape-out was in March 2001, UMC 0.15, 52.6 million transistors, at
600 MHz. We also used Synopsys FlexRoute on the design. It is working
at speed.
- Tom Arns
SandCraft
============================================================================
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
|
|
