> John, I was looking through some of my old email for your DAC'98 Trip
> Report, and I see part 1 of 2, but no part 2 of 2. Is there someplace
> I can get part 2?
>
> - Cliff Whitmore
> Intense3D, Inc.
From: "John Cooley" <jcooley@world.std.com>
Cliff,
I'd like to publically apologize for this. While most engineers reading
one of my trip reports usually finds them fun and informative, for me,
writing a trip report is one of those things I take *VERY* seriously
because of the impact I've seen it have on the industry. I literally
spend a man-week getting ready for a conference, then a full week at the
conference, and then another ten working days afterwards writing the trip
report itself. I take *nothing* lightly about it. It's an exhausting
process of surveying users who attended, phone interviews, pouring over
old EE Times, sorting through EDA marketing propaganda, web searches,
digging in old ESNUGs, and checking with a number 'insiders' to make sure
*all* the facts presented are accurate. It's a hell of a lot of work.
For example, in that SNUG'99 Trip Report, you got three user benchmarks
with all sorts *detailed* hard numerical user data on Chip Architect.
It didn't come to me that way! I was originally given a thoroughly
'sanitized' blurb from Synopsys Marketing that consisted of fluff and
their typical 'success story' conclusions. It took me a two trips to
California (the product announcement plus being at SNUG'99) plus making
around 40 pestering phone calls over a 5 week period to get that data.
It was exhausting, but I knew users would want this *real* data instead
of spin from Synopsys Marketing on this. And this was a very significant
change in the way chips would be designed in the not-so-far future, so
I felt it was worth the effort.
And then there was all the other data to be collected about Formality,
Test Compiler, Ambit vs. DC, VERA, DesignWare libs, Eaglei, FPGAs, VCS,
Linux, DC99.05, Tcl, BC, ECO Compiler, Module Compiler, Power Compiler,
PrimeTime, ...
And then, after all this research, I'm stuck brainstorming ways to
write-up all this data so it's not a snooze to read.
Cliff, last year, I did this enough to write that part 1 of the DAC'98
Trip Report, but I got so overwhelmed with consulting work after that,
I couldn't get part 2 written.
And I shamefully apologize for this. Sorry.
- John Cooley
the ESNUG guy
( ESNUG 322 Subjects ) -------------------------------------------- [6/99]
Item 1: ( ESNUG 319 #8 321 #3 ) Disgust At The Avant! VeriLint 'Upgrade'
Item 2: Who Needs SETI? I Can't Find Intelligence On The Synopsys Hotline!
Item 3: Collett's Take On The Current North American Verilog/VHDL Market
Item 4: Cadence Pearl Static Timing Analysis Interface Has Improved
Item 5: ( ESNUG 321 #10 ) A Module Compiler Trick That Synopsys AE's Hide
Item 6: Log, Square Roots, & Other Advanced Mathematics In Verilog Sims
Item 7: ( ESNUG 321 #8 ) MUX Models Must Be Redundant To Handle 'X' Selects
Item 8: ( ESNUG 320 #3 321 #4 ) We Found Equivalency Checking Useful
Item 9: ( ESNUG 317 #10 ) The Scoop On The Remade DesignWare PCI Module
Item 10: ( ESNUG 321 #7 ) DC's Wrecking My Scan Chains During Incrementals
Item 11: ( ESNUG 319 #12 321 #9 ) Want To Remove Tied-off/Dead Flip-flops
Item 12: ( ESNUG 320 #11 ) Designing High Speed FPGA Multipliers
Item 13: ( ESNUG 317 #6 ) Propagate_constants Doesn't Work Like You Think
( ESNUG 322 Item 1 ) ---------------------------------------------- [6/99]
Subject: ( ESNUG 319 #8 321 #3 ) Disgust At The Avant! VeriLint 'Upgrade'
> Although perhaps not quite as strongly as Sparticus, I also object to the
> way Avant! is handling the InterHDL/Verilint "upgrade". We have three of
> the hold time licenses and have found them useful in our design flow.
>
> I have tried to explain to Avant! that the tool is not a $45K tool, but
> they seem unmoved. I wonder how many of their customers are really going
> to take them up on their offer to upgrade, and how many are going to go
> with a permanent key, drop maintenance, and not give them another dime?
>
> It is particularly annoying that they want to charge maintenance based on
> the $45K price of the tool. This means our yearly maintenance would be
> almost $7,000 --- what we paid for each license originally.
>
> It looks to me like their strategy is to move their Verilint customer base
> to their Nova-Explore-RTL product. This product requires you to run
> interactively in a multi-window GUI type environment. Just like every
> other EDA vendor, they want to have the Holy Grail of EDA Software. That
> is, a tool that a designer is going to sit in all day long while doing code
> development and debug. I don't think Nova-Explore-RTL is it.
>
> - Tom Loftus
> Hughes Network Systems
From: [ The Man In The Iron Mask ]
John,
I thought I'd bring to your attention a couple of more issues about the
Avant! Verilint powerplay. Politics say I must remain anon.
1) Avant! warned me:
"YEAR 2000: Nova-Verilint 4.3 uses FLEXlm Version 5.12b and is fully
Y2K compliant. Older versions of our [Avant!'s] software (which uses
the Elan license manager Version 4.x) have a known minor Y2K problem
in the ilmrpt license usage reporting utility"
This is a clever ploy by Avant! who realizes that it may be less
hassle for me to pay the upgrade fee than to explain to my management
how I'm going to remain Y2K compliant. Y2K compliance folks tend not
to want to hear: "its only a useless reporting utility that's affected"
2) Avant! also warned me:
"Verilint-XL has a unique feature that 'holds' a license for a
particular user for a 27 minute period. Having moved to the FLEXlm
license manager, this type of Verilint license is no longer
available."
This feature is hardly unique. This feature is available with FLEXlm
as "linger" and was implemented by BSO Tasking a Dedham, MA vendor of
RISC compilers. For the information for your users, both Elan and
FLEXlm treat a "user" as a username/hostname/DISPLAY value 3-tuple.
So if you want to "fake out" the license, you need to keep all three
the same.
Free enterprise and competition is the only way to keep Avanti "honest"...
(and okay the Cadence people can stop laughing now.) A colleague passed on
to me the following URL for a Verilint competitor. I do not have any
experience with this product but would be interested in feedback from any
of your readers on ESNUG who do: http://www.dualsoft.com/reviewver.htm
- [ The Man In The Iron Mask ]
---- ---- ---- ---- ---- ---- ----
From: Billy Vitro <bvitro@cisco.com>
John,
I just saw an ad for the Proton Rule Checker -- a lint-like tool from ASC
Inc. (http://www.ascinc.com), and was wondering if anyone else had used it
and what they thought of it in comparison to Verilint. It looks like it's
time for capitalism to fix this little problem.
- Billy Vitro
Cisco
---- ---- ---- ---- ---- ---- ----
From: "Janick Bergeron" <janick@qualis.com>
John,
If you were using Verilint solely as a syntax checker, than you were missing
it's most useful feature: a LINTER.
I recommend using linter as the *first* line of attack in debugging Verilog
models. I have *personally* run Verilint only on a large RTL model
(synthesized to 2.2M gates) for two weeks and found and fixed between 3 to
8 *functional* bugs a day, without running a *single simulation cycle*.
The RTL model was not even close to be simulatable (someone else was getting
the simulation environment ready during those 2 weeks). In my book, that
comes out as more valuable than the simulator in terms of productivity.
It is still beyond my understanding why anyone would find Verilint expensive
at $47k for what basically becomes a site license. It pays for itself, in
terms of engineering productivity, during a single ASIC project. My
recommendation: cough up the upgrade cost but demand the new features (such
as configurability) that will be found in Nova...
One thing engineers have to realize: these tools cost money to develop and
maintain and one should expect returns according to the *benefit* they
provide. With a tool that runs in seconds, a useage-based licensing that
has historically worked in the EDA industry does not work: a single license
will support any number of users. Why should a company with 150 engineers
using that license pay the same thing as the 3-engineer start-up? They are
getting 50x the benefit. Qualis faced the same decision with VMK, our
makefile generator for VHDL models -- and came up with a similar solution
(albeit marketted differently as a 'day-user': the license is held until
midnight).
Globetrotter uses a different model: the more money you make selling the
tool licensed using their product, the more it costs (e.g. Synopsys
may pay $1M for the *exact* same software we paid $7,500 for -- but they
are getting a *lot* more benefits from it than we do). The customer's
(mis)perception of a held license forced Avanti to try to change their
model... to everyone's apparent disadvantage. Be careful what you wish for.
Of course, a little bit of competition in the linter field would be welcomed.
> It looks to me like their strategy is to move their Verilint customer base
> to their Nova-Explore-RTL product.
They are not shy about this. A rep told me exactly that in their booth at
HDLcon last April. Personally, I'll take a command-line batch tool over
an interactive GUI any time....
BTW, while I have your attention... does anyone else find "// verilint #
on/off" cumbersome and dangerous? Not only does it clutter your code with
two directives for each check you want to turn off, but creates a region
where a check can be inadvertedly left OFF. I suggested to Eli long ago to
have a "shut up for this line only" directive:
someVerilog code here; // verilint # ok
And be "sticky" to the object when put on a declaration
reg [4:0] my_state; // verilint ... ok ( Turn off warning about
inferred FF)
Never seen that feature make it in....
- Janick Bergeron
Qualis Design
( ESNUG 322 Item 2 ) ---------------------------------------------- [6/99]
Subject: Who Needs SETI? I Can't Find Intelligence On The Synopsys Hotline!
> Essentially, SETI is the Search for Extra-Terrestial Intelligence and the
> people doing it have a massive amount of raw radiotelescope data to
> process. Their solution? Distribute PC and workstation screensavers that
> process chunks of data when your computer is idle. Novel idea! And
> currently over 500,000 computers are partaking in this project. So,
> instead of letting your unused CPU cycles go to waste, I urge you to go
> to http://setiathome.ssl.berkeley.edu and let that unused processing power
> go towards a really cool project! Nanoo! Nanoo! - John
From: David Simmons <simmod@taec.toshiba.com>
John,
Having encountered the Synopsys hotline, I have no interest in contributing
to any further search for extraterrestrial intelligence. As Meriweather
Lewis (of the explorers 'Lewis & Clarke' fame) put it, referring to his
expedition's encounters with the grizzly bear, "We have entirely satisfied
our curiosity with respect to this animal".
Sorry,
- David Simmons
Toshiba
( ESNUG 322 Item 3 ) ---------------------------------------------- [6/99]
From: Ron Collett <ronc@collett.com>
Subject: Collett's Take On The Current North American Verilog/VHDL Market
John,
Let's move the discussion forward and talk about the role of the two
languages in the core of the North American IC and ASIC design markets:
computers, communications and semiconductors. While it's not our usual
style to disclose research findings to public audiences (otherwise, there
are no $Millions to be earned, real or imaginary), you've stirred a debate
and I'd like to contribute with results from a recent study. In these chip
design markets, Verilog is clearly the dominant modeling language with 67
percent of design teams using it in North America. VHDL, however, is
holding its own in these markets in North America, with 37 percent using
it. Worthy of note is that a 16 percent of these teams use BOTH languages
in the same design project. And 17 percent use neither Verilog nor VHDL.
I think that we've reached detente. The "hard core" Verilog users (i.e.
use only Verilog) represent about 46 percent of this industry group and
the staunch VHDL users (i.e. use only VHDL) represent 21 percent. That's
the way it is today in these market segments -- but in the defense and
aerospace market, the industrial control market, medical electronics and
other market segments, the story is different.
As for trends, I don't think it's an issue. Both languages are here to
stay, and the discussion will rapidly move on to whether C, C++, C2,
extended Verilog, VHDL or SLDL or some other language will prevail in
the next generation of "advanced design."
- Ron Collett
Collett International Santa Clara, CA
( ESNUG 322 Item 4 ) ---------------------------------------------- [6/99]
Subject: Cadence Pearl Static Timing Analysis Interface Has Improved
> How I can make a static timing analysis (critical path extraction) with
> Cadence's 97A version? We are in Cadence Virtuoso with the routed view
> of the circuit (after a P&R). I can extract SPF, SDF... but if try to
> calculate all delays .... the window not show any path (delay).
>
> - V. Puente
From: Ed Chester <ed@chester.net>
You can use Pearl, the command-line based unfriendly tool included with
Cadence 97A onwards. It is actually a pretty powerful static timing
analyser that doesn't need stimuli, but it's horrible to use. Read the
on-line documentation in "Openbook" about it: IC Tools, Timing Analysis,
Pearl. You're on the right track, you need the SDF/SPF and whatnot.
- Ed Chester
University of Newcastle UK
---- ---- ---- ---- ---- ---- ----
From: Alan Barclay <abarclay@terasystems.com>
I can't say as to when (or whether) it will be released, but I was
working on integration of Cadence's Design Planner with the Pearl GUI when
I was laid off from Cadence in Nov98. The Pearl GUI was also being
integrated with Silicon Ensemble.
The Pearl GUI was a pretty nice piece of work, written in Tcl/Tk, allowing
you to winnow through the possibilities according to various criteria,
then display each one with both a tabular view of the delays, and a
drawn-on-the-fly schematic. Massive usability improvement...
- Alan Barclay
Tera Systems
( ESNUG 322 Item 5 ) ---------------------------------------------- [6/99]
Subject: ( ESNUG 321 #10 ) A Module Compiler Trick That Synopsys AE's Hide
> I have been given the task of evaluating Module Compiler. After cruising
> along the learning curve quite well, I came to a roadblock. The ALU
> datapath I was implementing as a test case had the use of intermediate
> carry bits from the 32-bit adder. I have yet to find in the documentation
> how one gets access to these bits or if it is even possible. Any help
> from ESNUG would be appreciated.
>
> - Barry Williams
> Rockwell Avionics
From: [ Casper, The Friendly Ghost ]
John,
Please keep me anon, but the Synopsys AE's are always trying to keep people
from using a very powerful feature of Module Compiler -- it used to be in
the documentation, but they even took it out of there!
For carry save arrays, there is a way to access the carry and sum terms
prior to the final add. This is great if you want to control the pipelining
yourself, instead of hoping that MC finds the right place for your regs.
The example below does a simple multiply, but registers the values prior
to the the final add.
module TEST (Z, X, Y);
input [w-1:0] X, Y;
output [2*w-1:0] Z;
wire [2*w-1:0] PRODS, PRODC;
directive local (carrysave="convert", pipeline="off");
wire [w*2-1:0] PROD = X*Y;
csconvert(PRODS, PRODC, PROD);
PRODS_reg = sreg(PRODS);
PRODC_reg = sreg(PRODC);
Z = ACC0+ACC1; //Adding the two terms together, or to another
//signal brings um back together.
endmodule
You can use this to create superfast accumulators or if the Multiplier feeds
other adders you can often save a carry propagate add.
To be fair to the Synopsys AE's, this approach has 2 drawbacks:
1. Hard to verify
2. if you try to do any logic on these outputs seperately, you can
really screw yourself (like trying to check if they are zero...)
At my last company we used this feature to get great results!
- [ Casper, The Friendly Ghost ]
( ESNUG 322 Item 6 ) ---------------------------------------------- [6/99]
Subject: Log, Square Roots, & Other Advanced Mathematics In Verilog Sims
> I would like some mathematical functions within a verilog simulation.
> For example, my verilog model has data values in a linear scale. I would
> like to display those values at various times throughout the simulation in
> a logarithmic scale. Ideally, something like this:
>
> always @(eventWhatever)
> $display(" The log of %d is %d", x, log(x) );
>
> The verilog simulator I am using is Cadence Verilog-XL. Is there a set
> of verilog extensions out there somewhere which I can use to do this type
> of thing? Square Root would be nice also ...
>
> - Jeff Streznetcky
> Lockheed Martin Federal Systems
From: andi_carmon@my-deja.com
Jeff,
You need a PLI function to solve your mathematical functions. All the
mathematical functions, including those you mention are gathered in one of
the ready-to-run examples in http://www.angelfire.com/verilog
- Andi Carmon
( ESNUG 322 Item 7 ) ---------------------------------------------- [6/99]
Subject: ( ESNUG 321 #8 ) MUX Models Must Be Redundant To Handle 'X' Selects
> One advantage of this style of mux model (as opposed to a behavioral "if"
> or "?:" model) is that it will propagate X values. (The Verilog language
> spec requires an if statement to treat an X as if it were a 0.) However,
> there's a subtlety that many people miss. You want it to be the case
> that, if your select is X, but both data values are the same, then the
> output is the data, not X. (You can trust me on this, or learn from
> painful experience. :-)
>
> Therefore, your mux models need to include a "redundant" term. Here's an
> example (the "a & b" term is redundant for 0-1 values):
>
> module mux2 (z, a, b, s);
>
> output z;
> input a, b, s;
> reg z;
>
> always @(a or b or s)
> begin
> // redundant term to get correct behavior when s is X .
> q = (~s & a) | (s & b) | (a & b);
> end
>
> endmodule
>
> I *STRONGLY* recommend all behavioral mux models be written in this manner.
>
> - Howard A. Landman
> SiTera, Inc. Longmont, CO
From: Kim Flowers <kimf@translogic.com>
John, I saw this message in the ESNUG mailing list. What happens if you
do not model MUXes in this manner? This is actually a practical
question for us -- we need to model various mux-like cells and I would
really like to know the reasoning. Thanks!
- Kim Flowers
Translogic Technology
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
John,
If you don't model MUXes redundantly, then under some circumstances you will
get an X as the output of the mux when in reality the value is known. This
can sometimes cause problems in simulation. A typical issue can be failure
of a chip to reset -- once certain signals become stuck at X, it may be hard
to force them to 0. This is especially true in synthesized netlists where
reset may be buried far back in a cone of logic.
- Howard A. Landman
SiTera, Inc. Longmont, CO
---- ---- ---- ---- ---- ---- ----
From: Shalom Bresticker <shalom@msil.sps.mot.com>
Hello, Howard,
You lump "if" and "?:" together. However, "?:" does propagate X values.
And if the select is X, but both data values are the same, then the output
is the data, not X. That's our experience, at least in Verilog-XL.
- Shalom Bresticker
Motorola Semiconductor Israel, Ltd. Herzlia, Israel
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
Hi Shalom,
Actually, I think what's happening here is that Verilog treats the X on
select as 0, so it chooses the second value. If both values are the same,
this of course is the same as the first value.
But if the values are different, then ?: gets the wrong answer.
"1'bx ? 1'b1 : 1'b0" should evaluate to X to be safe, but Verilog makes it
0, which may not be correct and will probably not match gate-level sim.
So, the problem with "if" and "?:" is not when the values are the same, but
rather when they are different (and select is X). The problem with the
gate level model (without redundant term) is when the values are the same
(and select is X). Sorry if I was unclear.
- Howard A. Landman
SiTera, Inc. Longmont, CO
---- ---- ---- ---- ---- ---- ----
From: shalom@msil.sps.mot.com (Shalom Bresticker)
Sorry, Howard.
I just tried it on my Verilog-XL in all sorts of modes, and got x each
time, just as it should, not 0. If you have a test in which Verilog-XL
gives you 0, please send it to me so that I can check it.
In the meantime, I stand by my statements.
- Shalom Bresticker
Motorola Semiconductor Israel, Ltd. Herzlia, Israel
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <HowardL@SiTera.com>
Hi Shalom,
I don't have XL here, but VCS also behaves as you describe. So, you're
right and I was wrong -- the "?:" operator propagates X's correctly. I
ran all possible 0-X-1 combinations and they all behaved identically to
the model I recommended.
The "if" operator, on the other hand, gets the wrong answer in several
cases.
- Howard A. Landman
SiTera, Inc. Longmont, CO
( ESNUG 322 Item 8 ) ---------------------------------------------- [6/99]
Subject: ( ESNUG 320 #3 321 #4 ) We Found Equivalency Checking Useful
> Equivalence checkers work hierarchically, so large designs aren't
> a problem if they have matching hierarchy. The main problems are:
> ... RTL to gates if there is not matching hierarchy. But flow can solve
> this. Use an RTL to hierarchical-gates proof, then a hierarchical to
> flat gates proof,...
>
> - Mike Bartley
> STMicroelectronics Bristol, UK
From: damianf@s3two.ie (Damian Finnerty)
I'm evaluating Chrysalis at the moment and I've just come across this
problem. I'm awaiting a response from a Chrysalis AE but I'd like to hear
from somebody who is actually using one of these tools.
I'm trying to compare RTL to Flattened-Gates.
Usually when doing an RTL to Gate comparison, I break the design up into
sub-blocks and do the equivalency check hierarchically. But, with a
flattened netlist this does not seem to be possible. You have to compile
and compare the whole design. This is not viable when working with a
1+ million gate design as I am. The ONLY solution appears to be to do
what you said above...
RTL to Hier-Gates
Hier-Gates to Flattened-Gates
Is this correct?
- Damian Finnerty
S3 Dublin, Ireland
---- ---- ---- ---- ---- ---- ----
From: Mike Bartley <bartley@bristol.st.com>
Damian
Yes - I would say that the only way to really do this is
RTL to Hier-Gates
Hier-Gates to Flattened-Gates
But that shouldn't be too much of a problem.
- Mike Bartley
STMicroelectronics Bristol, UK
---- ---- ---- ---- ---- ---- ----
From: Chrystian Roy <croy@lsil.com>
Hi John,
I was very surprised about Don Mills' assertion that equivalence checking
is useless. We have had quite a different experience at LSI Logic.
Just as an illustration, my latest project was to help on the formal
verification of a design in a RTL signoff (this was a "give us your RTL
and we will fab you a chip" deal). The specs were:
- G10 technology (0.35 um)
- flip chip package, close to 1000 leads
- 100 MHz clock frequency
- 460 Kgates (whole chip, not counting rams)
- 230 Kgates (without cores)
- 200 Kgates (without cores and pads)
The synthesized logic (200 Kgates) was verified against the RTL in one
block in 1.25 hour (including reading in the designs). Memory usage was
615 Mb. The memory limit under Solaris 2.6 is around 3.7 Gb. We were not
even close to that.
Gate-to-gate verification required 0.35 hour and 695 Mb (this was for the
final netlist against the synthesized gates, with scan chain disabled and
wihtout cores). Two bugs were caught using equivalence checking. One of
them would have been quite difficult to find using other methods. The run
time of the full gate level simulations on a compute farm was 2 weeks.
This is compared to 21 minutes for equivalence checking on a single CPU.
All benchmark data is from a dual CPU (200 MHz) Ultra 2 with 2 Gb of RAM
and is very design dependent of course. Every equivalence checker is
going to choke on a large multiplier for example.
We found formal verification to be very useful to check that any
transformation performed on a netlist (scan, JTAG, and BCT insertion,
IPO, hand edits, scan reorder, place and route, etc.) does not introduce
errors. Some of those comparisons (e.g. edits in layout) can be totally
push-button.
It took 6 weeks to go from final RTL to tape out for that design.
Equivalence checking saved us at least 1 to 2 weeks.
- Chrystian Roy
LSI Logic
---- ---- ---- ---- ---- ---- ----
From: Mohammad Imam <mimam@micro.ti.com>
John,
I also do not agree with Don Mills. We have used Chrysalis a lot for past
year and half or so.
We have found it out very useful, in many respect. RTL-> GATE comparision
is no problem for us now, as we have automated it almost compeltely. Of
course due to hierachy problems some times we have difficulties, but with
open eyes writing correct rules is easy. :-)
We have used it for different purposes too. In multiple instances, we were
very close to PG and bugs were discovered, and there was no time to
resynthesize the block, we made changes in RTL, and corresponding gates
changes were done, and using Chrysalis, we were able to fix and prove
the netlist very fast.
- Shahid Imam
Texas Instruments
---- ---- ---- ---- ---- ---- ----
From: Tom David <tomd@silogix.com>
Hi John,
With respect to the equivalency checking thread on ESNUG 321, folks should
check out Verplex's tuxedo suite of tools... I understand they're much
faster than Chrysalis and can handle things like precharge-evaluate logic
and hierarchy mismatches between RTL and gates, etc.
- Tom David
SiLogiX, LLC.
( ESNUG 322 Item 9 ) ---------------------------------------------- [6/99]
Subject: ( ESNUG 317 #10 ) The Scoop On The Remade DesignWare PCI Module
> Synopsys re-introduced a synthesizable PCI core in the DesignWare library
> last year. Have you heard from any one that used it? Now it's in the
> DW Foundation library. I heard the first version was difficult to use
> (even Synopsys admited that), and the new version is much better. Is this
> true? I'd appreciate any info you can pass to me.
>
> - William Liao
> MMC Networks
From: Richard_Grenier@3com.com (Richard Grenier)
John,
We've used the new Synopsys DW PCI core in a recent product. It was a
complex PCI configuration that needed to support both 32 and 64 bit
configurations and run at both 33mhz and 66mhz {4 corners}. Our first
implementation was in 3.3v 0.35u 3LM.
We recently received the silicon and have had zero bugs in the PCI front-end
of the chip. All PCI transactions on both 32 and 64-bit buses, as well as
33 and 66 Mhz have been thoroughly tested and are functional. The NIC
itself is already running Netware & NT drivers, as well as diagnostics.
The PCI core has been exposed to a variety of 32 and 64 bit bridges, as
well as 33 and 66 Mhz operation. We do feel, however, that use of a PLL to
compensate for insertion delay is recommended for 66 Mhz PCI operation over
the full commercial temperature/voltage ranges, though this is a
technology-specific constraint.
On the technical support side Synopsys was attentive to our needs and issues
throughout the course of the project.
- Richard Grenier
3Com Santa Clara, Ca
---- ---- ---- ---- ---- ---- ----
From: "Joerg Landmann" <lama@de.xionics.com>
John,
Recently, we began development of a full featured PCI interface to work with
a multifunction device. By using the PCI bus to connect various interfaces
with a general purpose CPU, the decision was made to exploit a ready-to-use
core from an IP vendor. The group had already started the design process
using a core from a different vendor when we became aware of the Synopsys
DW PCI. Granted, there were strong reasons to use that prior IP core
in the first place (proven silicon), but the Synopsys approach was different
enough to warrant another evaluation cycle.
We decided to switch to the Synopsys DW PCI core because it had a:
- Very easy-to-use installation procedure
- Easy GUI-driven configuration mechanism
- Automatic generation of simulation model together with a
ready to use compliance test suite
- Automatic generation of the synthesis models together with
ready to use synthesize scripts for the Design Compiler
Of course, the installation alone didn't provide a workable product, but it
helped us make certain design decisions very early in the process. Our ASIC
uses NEC's CBC9VX 0.35 micron technology and the 32bit PCI bus is running
at 33Mhz. The overall gatecount of the ASIC including the PCI interface
is about 250K gates.
After generating the core, the group was able to synthesize the complete
core (including the pads) to a timing-clean netlist containing all the
functionality we had defined, and in less than a 1/2 day.
This shortened development cycles enabled us to test various configurations
(like different numbers of BARs, ...) prior to designing the application
interface. Each configuration was tested within the PCI compliance test
suite, which offers an indication of the (PCI) design's quality without
having to worry about writing big chunks of test code.
Besides the installation and startup procedure, the seamless interface of
synthesis and simulation environments drove the final decision to implement
the PCI interface as a "DW PCI core" into the design.
While the Synopsys approach providing the PCI IP is novel, we experienced
a couple of problems in the design cycle, but none of them were fatal:
- The installation tree is complicated. Updates to the simulation
environment as well as the Design Compiler scripts are not intuitive.
- The target library should support the scan process with the GUI of
the DWF software. If it does not, all PCI pads may not be found.
During our design process, we found that the PCI interface needed to grow
with our needs and add functionality to the ASIC. There was a clear need
to support a multi-function PCI interface to enable plug and play for
multiple interfaces located on the device, while the DW PCI core remained
single functioning. Additional Synopsys documentation helped us make
modifications primarily to the top level macro to support additional
function units. This process greatly impacted our plans for future
projects. While the design supports functionality, it is not yet completely
defined. If the PCI requirements change, it will be important to have the
flexibility to switch to a source code model which fits seamlessly into an
existing DWF library.
- Joerg Landmann
Xionics Dortmund, Germany
( ESNUG 322 Item 10 ) --------------------------------------------- [6/99]
Subject: ( ESNUG 321 #7 ) DC's Wrecking My Scan Chains During Incrementals
> I have a netlist with a scan chain inserted. Now I want to do an
> incremental compile on that netlist without the Test Compiler. I've tried
> to put a set_dont_touch on every register and every scan chain net (the
> one which are connected to the DB input of my scannable register).
> Unfortunately, this doesn't stop Design Compiler from messing around with
> my scan chain since the set_dont_touch on a net applies only on
> combinatorial cells connected to that net.
>
> What happens basically is that Design Compiler is re-routing my scan chain
> thru inverters to try to reduce the fanout on other critical paths. So
> instead of going from Q to DB, it goes from QN to DB thru an inverter.
> Not really what I want for a scan chain !!!
>
> This scan chain wasn't generated by the Test Compiler at the first place.
>
> If anyone has a suggestion, that would be great.
>
> - Laurent Claudel
> Massana Ltd Dublin, Ireland
From: Jeffrey Ebert <ebert@sonicsinc.com>
John,
Laurent needs to make sure that DC knows about the scan chain. This
involves specifying the signal_types for the scan ports and running
check_test. Of course, this requires a Test-Compiler license, at least
for the check_test execution. Subsequent compiles will not need it.
In theory, you might be able to set the appropriate attributes on the
scan circuitry manually or with a nice little script, but I've never
been down that road.
On the other hand, I don't know why Laurent is concerned about DC using
the QN output. This is usually considered a good thing in scan
synthesis, precisely because it reduces loading on the functional
output. I guess he has his reasons, though.
- Jeffrey Ebert
Sonics
---- ---- ---- ---- ---- ---- ----
From: Sam Rosen <sam@lexra.com>
John,
I wanted to offer help on Laurent Caudel's Scan issue (ESNUG Post 321 #7).
I re-read Bob Wiegand's great letter on "Five Lessons I Learned The Hard Way
While Using DC 99.05" in ESNUG Post 317 #6, and realized I had a couple of
(hard-earned) gems of wisdom he didn't cover about Design Compiler and
Test Compiler. Hopefully these will help Laurent and others.
1. check_test adds scan attributes to a non-DC scan chain
In our design, we read verilog netlists (.hv) in for non-synthesized
pre-scanned blocks (ie, datapaths). To add scan attributes to a subdesign
(say, foo) on reading it in, do the following: (note: use set_signal_type
for _existing_ scan, while you use set_scan_signal before insert_scan.
why? beats me)
read -format verilog foo.hv
current_design foo
set_scan_configuration -existing_scan true
set_signal_type test_scan_enable SEN
set_signal_type test_scan_in SIN
set_signal_type test_scan_out SOUT
check_test
At this point, Design Compiler recognizes the scan chain, and therefore
won't do stupid things like adding muxes to the inputs, etc.
2. Optimizing use of the Test-Compiler License
We have less Test Compiler licenses than Design Compiler licenses. When
we ran out of Test Compiler licenses DC shell issued a non-fatal error
message occurred, and the job completed without inserting scan. The
solution we use causes a job to wait until it acquires a valid license,
and releases the license when its done. This should (with #1) allow
Laurent to do an incremental compiler without a Test_Compiler license.
(I found this basic script in SolvNet, slightly modified)
FAILED_LICENSE = 0
get_license Test-Compiler
while (dc_shell_status == 0) {
sh "sleep 300"
FAILED_LICENSE = 1
get_license Test-Compiler
}
if (FAILED_LICENSE) {
echo "Error: Test-Compiler License acquired"
}
<do the check_test from #1, above>
remove_license Test-Compiler
<do the incremental compile>
3. "Safe" insertion doesn't modify cells
This method of "safe" insertion was provided to me which shouldn't affect
the cells in existing scan chains. I've found it modifies cells when scan
configuration constraints are violated, but is much safer than a simple
insert_scan:
test_dont_fix_constraint_violations = "true"
insert_scan -map_effort low -ignore_compile_design_rules
I use this because in a subdesign block (foo, from above) on which I need
dont_touch attributes. However, I want its scan chain included on the
scan chain of the higher block. In some cases,
set_scan_path Chain1 foo/1 -complete false
insert_scan
might work (the foo/1 refers to the 1st scan chain in block foo, which
seems to be assigned randomly during check_test. referring to it as an
item should cause it to be untouched inside foo itself.) Referring to the
individual cells will cause an error that it can't insert because of a
dont_touch attribute.
I use this workaround:
<check_test on foo, as in #1, above>
<remove all dont_touches>
test_dont_fix_constraint_violations = "true"
insert_scan -map_effort low -ignore_compile_design_rules
<add back all dont_touches>
4. Forcing Q vs QN / chain buffers (only a mediocre workaround here)
One of the place & route tools we have experience with requires consistent
use of Q or QN as the scan output. We were told by Synopsys AE's that the
variable: test_disable_find_best_scan_out = "TRUE" should prevent it from
using QN. However, this was not the case.
To solve this, we've eliminated all flops with QN from our library (using
dont_use) to get around this. This initially worried me (overconstraints);
however, Design Compiler frequently chose flops with Q and QN while leaving
QN unconnected. The flop was larger _and_ slower. It turns out DC was
picking flops badly, and this helped it choose better. Does anyone have a
better solution?
- Sam Rosen
Lexra Waltham, MA
( ESNUG 322 Item 11 ) --------------------------------------------- [6/99]
Subject: ( ESNUG 319 #12 321 #9 ) Want To Remove Tied-off/Dead Flip-flops
> The result can be summarized like this: If a cell is not sequential (no
> clk), DC will try to remove it. If a cell does not drive anything, DC
> will try to remove it. But if a cell is sequential (has clk), or it
> drives something, DC is stuck with it, no matter how input pins are
> connected.
>
> If you have time, try the example, then have fun with other combinations.
>
> - William Liao
> MMC Networks
From: "John Patty" <EUSJRPA@am1.ericsson.se>
John,
I've done some more investigating also. The "open output" observation is
correct and is true for any element, not just a sequential element. Logic
that doesn't drive anything is removed automatically.
I ran some other test cases on some D FF's with the following configurations
to see how DC would optimize them. In each case, the test flop is a DFF w/
asynchronous reset. Test case is on the left. Results on the right.
1. Normal configuration (all i/o connected to signals) --> Normal DFF
2. Open output --> All logic removed
3. D input tied low --> DFF w/ D input tied low
4. reset_b tied active low --> DFF w/ reset_b tied low
5. clock tied low --> LATCH w/ D input tied low, reset_b tied to clock_b
6. D input tied high --> DFF w/ D input tied high
7. reset_b tied inactive high --> normal DFF w/o clear
8. clock tied high --> LATCH w/ D input tied low, reset_b tied to clock_b
The optimizations for 1, 2, 6, and 7 seem correct. For 3, 4, 5, and 8, the
output can only be controlled to the low state and should be reduced to a
tie-off.
As an observation, I would say that DC does NOT have the ability to replace
a sequential element with a non-sequential element.
- John Patty
Ericsson Research Triangle Park, NC
( ESNUG 322 Item 12 ) --------------------------------------------- [6/99]
Subject: ( ESNUG 320 #11 ) Designing High Speed FPGA Multipliers
> I was wondering if anyone can refer me to some information about designing
> an 8-bit by 4-bit unsigned multiplier and an 8-bit by 4-bit signed
> multiplier that will perform at high clock speeds and have efficient usage
> of CLBs on the Xilinx Virtex FPGA.
>
> - Allen Tung
> Visicom Labs San Diego, CA
From: [ A Synopsys FPGA CAE ]
John,
With version 3.2 of FPGA Compiler II and FPGA Express, you can get improved
FPGA architecture-specific multiplier implementations for Virtex and XC4000
devices. See http://www.synopsys.com/fpga/ for more info and software
downloads.
- [ A Synopsys FPGA CAE ]
( ESNUG 322 Item 13 ) --------------------------------------------- [6/99]
Subject: ( ESNUG 317 #6 ) Propagate_constants Doesn't Work Like You Think
> The propagate_constraints command has already made my life much easier
> by simplifying the application of constraints in a design hierarchy.
> Constraints can be applied at a lower level of the hierarchy and then
> propagated to the top level with the propagate_constraints command.
> Propagate_constraints works as advertised and only as advertised. So be
> sure to read the documentation. I had a case in which I segmented timing
> paths using input and output delays on an internal pin. These constraints
> are not propagated (yet--track STAR 69625). I was able to get around this
> problem thanks to the the new "-through" option for timing exceptions.
>
> - Greg Mann
> Ford Microelectronics Colorado Springs, CO
From: London Jin <londonj@eng.adaptec.com>
John,
I learned from ESNUG 317 that propagate_constraints made your life much
easier. You may be able to shed some light on this. I tried it, and
wanted to see how it works, and all I got at top-level were clock specs
(which is trivial). I expected to see set_input_delay & set_output_delay,
too. (Are these realistic expectations?) The following is what I did.
read top.db
characterize u_bac
current_design bac_test_1
write_script -format dcsh > bac.scr
write -f db -hier -o bac.db
remove_design -d
read -f verilog top.v
remove_design bac_test_1
read bac.db
current_design top
link
current_design bac_test_1
include bac.scr
current_design top
propagate_constraints -design bac_test_1 -all
write_script -format dcsh > top.scr
Any hint is greatly appreciated.
- London Jin
Adaptec
---- ---- ---- ---- ---- ---- ----
From: gmann@ford.com (Greg Mann)
Hi London,
I was a little vague in my comments in ESNUG 317 which probably lead to your
confusion. propagate_constraints doesn't propagate set_input_delay or
set_output_delay statements no matter what options are used, but is used to
propagate exceptions such as set_false_path, set_multicycle_path,
set_clock_gating_check etc. (See the Synopsys On-Line Docs for a
comprehensive list).
The problem that was solved by the -through option solved was a case in
which I needed to apply the constraint:
set_false_path -through find(pin,U1/A) -to find(cell,out_reg)
The version of Design Compiler I was using when I wrote the original
constraints didn't support the -through option, so the path had to first be
segmented using set_input/output_delay statements followed by a
set_false_path constraint as shown below.
/* Segment the path */
set_input_delay 5 -clock CLK find(pin,U1/A)
set_output_delay 5 -clock CLK find(pin,U1/A)
/* Apply false path exception */
set_false_path -from find(pin,U1/A) -to find(cell,out_reg)
Since propagate constraints doesn't yet support set_input_delay and
set_output_delay, it wouldn't propagate my constraints correctly. But when
I changed my constraint to a simple set_false_path command with
the -through option, propagate_constraints worked correctly.
- Greg Mann
Ford Microelectronics Colorado Springs, CO
( ESNUG 322 Networking Section ) ---------------------------------- [6/99]
North Billerica, MA -- Avici, a router/switcher start-up, seeks engineers
with Synopsys, Verilog, and Test exp. No headhunters. "pmora@avici.com"
Cary, NC -- Raleigh Technology seeks Verilog, Synopsys, 5+ yrs ASIC design
exp., ethernet a plus. Stock options! "gbrookshire@raleightech.com"
|
|
