Editor's Note: Well, my short term contract has ended and I'm heading
home today back to Boston. Being in the South has left me with some
odd impressions. Yes, this *is* the Bible Belt as the sociologists
say. And there are *plenty* of churches here. Lots of them. Beaucoup
churches everywhere. Most of them also have very bright lit signs.
I've even seen car dealerships with the message "JESUS SAVES" on their
marquees!? (Whoa! You *never* see businesses mixing in religion in the
rest of the U.S.!) ... But I've also never seen so many strip bars and
topless clubs in one region of the country either! (Whoa again!)
The "South" is just one big study in contrasts, Yes, Sir, contrasts.
One thing I do know though. I just called my friends in Boston and I've
heard tales of woe concerning freezing weather, so much ice it has
cause power outages, and brutal cold. Yet down here it was 70 degrees
today... I'VE JUST GOTTA GET ME ANOTHER ONE OF THEM CONTRACT JOBS
AFTER CHRISTMAS IN FLORIDA, TEXAS, ARIZONA -- ANY PLACE THAT'S WARM!!!
- John Cooley
the ESNUG guy
( ESNUG 257 Item 1 ) -------------------------------------------- [12/96]
From: Byron.Sonner@eagle.ColumbiaSC.NCR.COM (Byron Sonner)
Subject: I Always Use Freshly Squeezed DesignWare Parts For Speed
Dear John,
I just want to share with the ESNUG readers a little script I use to "crunch
down" the DesignWare libraries within Synopsys. We're always interested
in speed first and then area for our compiles. This helps us get there:
foreach(design_name,find(design,{*DW*})) {
current_design design_name
create_clock -period 20 -waveform {0, 10} -name clk
set_clock_skew -ideal -delay 0.0 clk
set_input_delay 19 -clock clk all_inputs()
set_output_delay 1 -clock clk all_outputs()
compile -map_effort high
}
current_design top
set_dont_touch {*DW*}
Experiments on my own designs have shown this improves the speed of designs
with the area not growing significantly.
- Byron Sonner
NCR, Columbia, SC
( ESNUG 257 Item 2 ) -------------------------------------------- [12/96]
Subject: ( ESNUG 255 #4 256 #1) Internal Tri-State Vs. MUXes Rules Of Thumb
> I thought you might like the approach I am using on my current ASIC
> design. I have an internal bus in the ASIC that has to read
> approximately 100 registers. I mux the registers internal to each
> of my approximately 5k gate partitions that get synthesized by
> Synopsys. When I mux inside the partition, I have a "case" statement
> with the default/others choice with the output all zeros if none
> of the registers are selected. I then daisy chain "OR" the partition
> outputs from one partition to the next. This approach minimizes the
> routing between partitions and so does not require lots of routing
> like the external mux approach would require. This approach only
> requires a 1x driver to drive the next partition since there is only a
> single load when you "OR" which is much better than tri-stating.
From: dchapman@goldmountain.com (Dave Chapman)
Wow, John.
It simply never occurred to me to do it that way. Perhaps the 100 gate-delay
propagation time has something to do with this. For low-performance
applications, it might be the way to go.
Meanwhile, several people pointed to the problem of finite fan-out from a
tri-state driver. Right. You will have to partition the design, with sub-
buses and so on, until it looks something like a PC, with a CPU bus, an ISA
bus, a PCI bus, and whatever the flavor of the month is bus. That's life.
My conclusion is that we still do not have a single best solution to the
problem of designing a bus, and that these things will continue to require
trade-offs and plain old design skill.
- Dave Chapman
Goldmountain
---- ---- ---- ---- ---- ---- ----
From: tbrown@armltd.co.uk (Tudor Brown)
John,
In my experience of designing complex systems, tristate buses are hard to
avoid when going for area and power efficiency (though system architecture
issues of a chip can determine area & power more than any methodology such as
tristate buses, etc.)
We naturally use tristate buses as the default approach, and I think it is
fair to say that we have had some actual problems and also some near misses
in terms of tools support spotting contention or power-up faults, but the
savings made in my opinion justify the perserverence.
My answer to the "which is better" debate would be "it depends if your
tools can support the methodology". If your tools expect to cope with the
charge-sharing, contention and undriven aspects of tristate buses, then
bidi's are usually smaller and cheaper. But if your tools expect logical
connections only, then it is best not to push the bidi philosophy, because
sooner or later you will come unstuck when the tools miss a logical driver
error -- resulting in contention, or float.
Personally, I feel it is a bit of a cop-out on the part of many tool flows
not to treat the issues of bidirectional buses and mulitle drivers correctly,
but unless you really go it on your own and use transistor level simulation
(which most of the world cannot afford to do) then most designers are limited
by the capabilities of the tools they use. So sadly, unidirectional buses are
here to stay as well.
Our ARM7TDMI core, designed for embeddability recognises this fact and
actually has 96 data pins! There is a bidirectional bus and also 2
unidirectional buses. Then it is up to the user to determine the philosphy
he wants to invoke in using the core.
- Tudor Brown, Chief Technical Officer
ARM, Ltd.
---- ---- ---- ---- ---- ---- ----
> One very serious problem with tri-states that wasn't addressed is the
> possibility of creating a tri-state net which can't be driven by the
> largest tri-state driver in the cell library, (i.e. the net capacitance
> is larger than the max_cap attribute of the tri-state driver.)
From: sgolson@trilobyte.com (Steve Golson)
A subtle point, John: if you have a big tri-state bus, you may get faster
performance by using a *smaller* drive tri-state buffer. If you use the
largest buffer in your library, then all the drivers on the bus will
see a much larger load on the bus (due to the pin capacitance of the
other big drivers). Your library probably has a "sweet spot" --
experiment and try out all possible buffers for the size bus you have,
in order to find the fastest cell.
Do not let Design Compiler blindly pick the tri-state driver! For any
given small module, DC sees a giant load on the bus, and picks the
largest drive buffer. If all the modules do this, you get sub-optimal
performance. Use "set_dont_use" on all other tri-state library cells,
so DC is forced to use the particular tri-state buffer you want.
- Steve Golson
Trilobyte Systems
---- ---- ---- ---- ---- ---- ----
From: jcooley@world.std.com (John Cooley)
The big "gotcha" I've seen from internal tri-state buses is that the tools
downstream from synthesis sometimes have had problems. For example, some
ATPG tools have historically just "choked" when encountering them.
(Apparently internal tri-state buses don't test nicely.)
- John Cooley
the ESNUG guy
( ESNUG 257 Item 3 ) -------------------------------------------- [12/96]
Subject: ( ESNUG 254 #6 ) Great DC 3.5 "-scan", But Its Licencing Sucks!
> Some of your ESNUG readers might be as happy as I was to learn about
> the "-scan" option to the "compile" in rev. 3.5 of Design Compiler.
> This is a relatively 'painless' way to map scan test devices into a
> design. ... Now the 'gotcha'. The "-scan" option checks out a Test
> Compiler license. In the version 3.4 compile scenario the Test Compiler
> license was only needed during the 5 minute "insert_scan" operation.
> In 3.5, the Test-Compiler license is 'held' for the entire duration of
> the rather long "compile"! ... Thus, I must shell out additional $$$ to
> buy enough Test-Compiler licenses to equal my Design Compiler licenses or
> I cannot use the "-scan" option. ... My opinion is that the "-scan"
> option should not need a Test Compiler license.
>
> - Charles F. Shelor
> Efficient Networks, Inc
From: [ The Synopsys TC Tech Marketing Manager ]
Hi John,
We released 1-pass scan synthesis in v3.5a, which as Charles noted,
includes the ability for Design Compiler to directly synthesize
to an optimized, mapped implementation using scannable sequential
elements. I (and the R&D people here!) respectfully disagree that
the "'-scan' option only affects library element selection".
While 1-pass does not require any explicit invocation of Test Compiler,
"compile -scan" does invoke TC under the hood to perform a variety
of actions, including the following:
- Synthesize and optimize scan logic, including techniques
only relevant to test logic.
- Annotate scan routing delay model elements into the
design, and control test mode signals to inactive states.
These steps ensure that gate-level simulation will
accurately reflect both the timing impact from scan routing
(the scan chains are not actually routed during 1-pass), and
mission-mode behavior.
- Manage the design database during possible multiple optimization
iterations through Design Compiler to maintain the required
scan logic and mapping.
Test Compiler does need to be explicitly invoked to run
test DRC checks, route scan chains, and run ATPG. (Scan chain
routing is NOT performed by compile -scan for two reasons:
- We did not want to overconstrain synthesis in its exploration of
the optimization search space
- Scan chain stitching tends to be chip-level task, with likely
input from manufacturing requirements or from physical design).
It is true that 1-pass scan synthesis does use the Test Compiler license
longer than the five minutes he was seeing in his old flow, but 1-pass is
a new, high-value feature in v3.5a that all current TC customers received
*in addition to* existing capabilities. We haven't taken anything away,
Charles "...must shell out additional $$$ to buy enough Test-Compiler
licenses to equal my Design Compiler licenses..." only if he sees that
1-pass and the new design flows it enables are valuable in their own right.
The 1 TC license per DC license is a new user model, compared to earlier
releases, and we've made some product configuration changes to help make
the adopting 1-pass easy:
1. Starting in January, there will be a new Design Compiler
configuration called DC Expert Plus, which is DC Expert
and all of the module-level DFT capabilities in Test Compiler
(including 1-pass scan synthesis, hierarchical scan DFT,
test DRC, statistical fault coverage reporting).
2. The current TC DFT package will go away, and will be replaced
by a DC Expert to DC Expert Plus upgrade.
3. We recognize that designers will need much more access to
DFT licenses, and we are pricing the the DC Expert Plus
configuration, and the DC Expert to DC Expert Plus upgrade
to better enable this user model.
Finally, during a promotional period in December, DC Expert Plus and DC
Expert to DC Expert Plus upgrades will be priced very attractively.
- [ The Synopsys TC Tech Marketing Manager ]
[ Editor's Note: We have "DC Expert", we have "DC Professional", and *now*
you've added a "DC Expert Plus" ?! Oh, great. I wonder which Marketing
wunderkind got the bonus for thinking *this one* up??? :^) - John ]
( ESNUG 257 Item 4 ) -------------------------------------------- [12/96]
From: [ The Chicken Man ]
Subject: User's Benchmark Of Model Tech V4.5c vs. Synopsys VSS 3.4b & 3.3b
Hi John,
Here's some benchmark data that may interest you. The first shows the
differences in run speed for 2 versions of Synopsys VSS vs. Model Tech
that were done on a Sun Ultra-1, equipped as described below.
The second shows the differences between a Sun Ultra-1 (1 CPU) with 448M
vs. a Sun Ultra-2 (2 CPUs) with 1 Gig of memory.
The sets of data are actually runs of the same simulation for all of the
cases. The 1st runs were on the same Sun Ultra-1 as the data taken for the
Ultra-1 vs. Ultra-2 test cases.
Rather than incur the wrath of the EDA vendor gods, and be doomed to be
awash in a sea of "X"s for the rest of my simulating life, please delete
my name. Best wishes,
-- [ The Chicken Man ]
Benchmark Data for Synopsys VSS 3.3b, 3.4b, and ModelTech V4.5c.
****************************************************************
The benchmark was a single testbench on a board level design containing:
- 4 copies of a 415K gate ASIC (36,000 lines of RTL),
- 1 copy of an 70K gate ASIC (4500 lines of RTL) and
- 16 models of a 64K by 18 SSRAM."
The ASICs perform a complex switching function.
Each simulation logged about 200 signals into a waveform data file for
later viewing, and each simulation wrote 43,000 lines of textio output to
the transcript file ( used for movie viewing ).
Simulations were compiled and run on the same Ultra1. No swapping.
Speed of simulation
-------------------
which TB_ICP_BTA sim Relative sim times
--------------------- -------------- ------------------
VSS V3.3B Interpreted 240 minutes 100%
VSS V3.3B Compiled 94 40%
VSS V3.4B Interpreted 191 80%
VSS V3.4B Compiled 48 20%
Model tech V4.5c 47 20%
Speed of compilation
--------------------
I did not accurately measure this, but its pretty dramatic between Synopsys
compiled and interpreted.
VSS V3.xB Interpreted FAST
VSS V3.xB Compiled 5-10 X slower
Model tech V4.5c FAST
Kernel Size
----------
VSS V3.3B Interpreted 100 MB
VSS V3.3B Compiled ---
VSS V3.4B Interpreted 92 MB
VSS V3.4B Compiled 85 MB
Model tech V4.5c 18 MB ( !!! I swear )
Library Size
------------
VSS V3.xB Interpreted 15 MB
VSS V3.xB Compiled 18 MB
Model tech V4.5c 10 MB
Usability:
------------
The Model Tech waveform tool is less capable than Synopsys's, but the host
of other methods of viewing your data more than makes up for it. Model
Tech waveform is much faster at viewing lots of data (full view).
ModelTech crashed once in the waveform tool. Synopsys never crashed.
Executuve Summary
-----------------
Synopsys (compiled) and ModelTech are neck and neck in sim speed for this
one design. Otherwise, MTI has much smaller simulator images, compiles
faster, provides more information, is easier to use, you don't have to
worry about compiled vs interpreted.
Synopsys is more forgiving of VHDL semantic content, has a fuller featured
wave viewer, and might be more robust on the bigger circuits.
Benchmark Data for Synopsys VSS 3.4b SUN Ultra-1 Vs. An Ultra-2
***************************************************************
No other significant jobs were running on either machine.
The simulation library was NOT local to either machine.
Kernel size for the VSS3.4b compiled code simulation: 85 MB
Ultra-1 Ultra-2 diff
-------- -------- -----
wall clock time: 51.7 min 34.5 min 67%
cpu time: 2900 sec 2018 sec 70%
Note: This same simulation was taking us about 4 hours for similar
test simulations in the spring, using VSS V3.3b interpreted
code running on Ultra-1's.
for the Ultra-1
---------------
CPU: SUNW,UltraSPARC
FRAME BUFFER(S): cgsix, cgsix
SunOS RELEASE: 5.5
MEMORY: 448MB
SWAP: 3584.6MB total, 148.7MB used, 3435.8MB available
LOAD AVERAGE: 1.26, 1.14, 0.79
for the Ultra-2
---------------
CPU: SUNW,UltraSPARC
CPU: SUNW,UltraSPARC
CPU: SUNW,ffb
FRAME BUFFER(S): cgthree
SunOS RELEASE: 5.5.1
MEMORY: 1024MB
SWAP: 2453.0MB total, 28.7MB used, 2424.3MB available
LOAD AVERAGE: 0.20, 0.10, 0.06
Executuve Summary
-----------------
The Ultra-2 ran the single simulation 50% faster ( simulation time is 67%
of the Ultra-1's ). There is no swapping on either machine, and the
Ultra-2 appears to only use one cpu for the single simulation.
( ESNUG 257 Item 5 ) -------------------------------------------- [12/96]
From: Charles Thomas <charlest@jna.com.au>
Subject: Mentor AL2 Vs. Synopsys W/ Floorplanning Mgr. In The "Down Under"
G'day John,
I have read with much interest many of your various articles and news
items regarding ASIC design and synthesis.
I am starting the design of my company's first ASIC which is a 35K gate
device with an additional 64kbits of RAM which will be manufactured by
LSI Logic using thir LCB6000K process.
I am now having to make a decision regarding the most appropriate
synthesis tool for my company to purchase. It basicaly boils down to
either Mentor Autologic II or Synopsys Design Compiler Expert which have
the following advantages/disadvantages:
Mentor advantages : cheap, locally supported, Exemplar Galileo will
be thrown in
disadvantages : small market share, unknown future
particularly regarding enhanced features. Less
likely to be supported by ASIC vendors
Synopsys advantages : large market share, plausible long term
development strategy, recommended by LSI
Logic for their design flow.
disadvantages : expensive, support out of Singapore - not local
We want a tool that will last, but cost and support are also an issue.
As we have little previous experience in this area, this decision is not
an easy one for us to make.
Things are a little bit unclear regarding the interaction betwen
floorplanning/layout and synthesis. Both Mentor and Synopsys are telling
me that I don't really need to be worrying about the ability to
backannotate RC path delay info from floorplanning/layout back into the
synthesiser to re-optimise the circuit prior to routing. Mentor claim
that AL2 supports this for LSI Logic should I want to do it (do I
believe them?) and Synopsys say I can do it with their Floorplanning
Manager tool (for an extra US$60K (list)).
I would have thought that this sort of feature would have been required
by anyone doing an ASIC design using a 0.5um or less technology but due to
my lack of experience in this area I am not sure if I am correct.
I realise that you must get many questions from people all the time, but I
would very much appreciate it if you could spare the time to answer the
following few questions.
- Do Synopsys users in general use Floorplanning Manager?
- Is Floorplanning Manager required to backannotate floorplanning/layout
RC data?
- Is Autologic 2 likely to support this functionality at no extra cost?
- Any other comments you would care to make regarding the choice of a
synthesis tool?
Thank you for bearing with me.
- Charles Thomas
JNA Telecommunications Limited, Chatswood, AUSTRALIA v
( ESNUG 257 Item 6 ) -------------------------------------------- [12/96]
From: mcur@alcatraz.rtc.sc.ti.com (Mark A. Curry)
Subject: "Bad DC! Bad DC!" -- How Can You Get DC To Clean Up After Itself?
John,
I use parameterized templates extensively in my Verilog designs. When
Synopsys reads in these templates, it creates a few temporary files with
names like "*.mra", and "*verilog.syn". Problem is, messy Synopsys doesn't
clean up these files upon exit. My directories are really starting to get
cluttered!
Do any of your readers have any tricks to get Synopsys to not create these
files, or redirect them to a junk directory? Something like a cache_read,
or cache_write dc_shell variable would be OK. But, I can't seem to find
any variables like this in the online docs.
- Mark Curry
Texas Instruments ASIC Design Center - San Jose, CA
( ESNUG 257 Networking Section ) -------------------------------- [12/96]
Bristol, UK -- Hewlett-Packard seeks ASIC/FPGA dsgnrs w/ Verilog/Synopsys,
know LANs and >50 Mhz design. No Agencies. "gcaw@hplb.hpl.hp.com"
|
|
