"It was very painful to not attract VCs, but we found they're just not
interested in this space. Their eyes would glaze over. It's too easy
to make a billion dollars on tupperware.com. They don't want to
understand the silicon design chain."
- John Ott, on why Genedax went out of business because it failed
to get a second round of VC funding. (EE Times, 2/28)
( ESNUG 345 Subjects ) -------------------------------------------- [3/1/00]
Item 1: ( ESNUG 344 #5 ) My 6 Carefree Days With A Stolen PhysOpt License
Item 2: ( ESNUG 339 #8 ) We Chose HDL-Lint Instead Of SureFire Or Avanti
Item 3: Anyone Have A Cadence Silicon Ensemble Library For A Grad Student?
Item 4: ( ESNUG 344 #5 ) PhysOpt: 11 Runs; Timing-Driven Qplace: 2nd Base
Item 5: ( ESNUG 342 #3 ) Synchronicity's DesignSync -- A True Nightmare
Item 6: ( ESNUG 343 #10 ) Missing: A Meaty DC Library Developer's Guide
Item 7: ( ESNUG 343 #5 ) "Don't Care" X's In DC 99.05/.10 Are Messed Up
Item 8: Bogus TCL "Help" Files In FPGA Express Trashes Xilinx GSR Mapping
Item 9: Ouch! We Got Burned By Our Motive-To-Primetime Script Conversion!
Item 10: ( ESNUG 344 #8 ) Superlog, Maybe. But C++ HW Design Is A Joke
Item 11: ( ESNUG 344 #9 ) Some DC Rumors & Running TCL In Design Analyzer
Item 12: ( ESNUG 342 #10 ) "Model" Command & Fake DC Library Elements
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 345 Item 1 ) ---------------------------------------------- [3/1/00]
Subject: ( ESNUG 344 #5 ) My 6 Carefree Days With A Stolen PhysOpt License
> We liked staying in a DC based (TCL) environment with just a few extra
> commands. It made PhysOpt easy to learn and easy to use for us. Because
> of this, I estimate it would take a designer familiar with back-end tools
> no more than an afternoon to get up and running with PhysOpt.
>
> - David Romanauskas, Design Engineer
> Matrox Montreal, Canada
From: Roger Bethard <criguy@sgi.com>
Hi, John,
It took me took 6 days from initial ramp-up to final netlist with a stolen
copy PhysOpt. But, my days are 18 hours, so I'd jokingly say that for the
mere mortals out there, it would take you around 2-3 weeks to do this. :)
I am a logic designer at SGI for the Cray SV1 product line. It's my job to
take legacy Verilog, merge and enhance the design, synthesize into a
technology that was never meant to run so fast, cram the results into a
ridiculously small floorplan image, and achieve post-physical design timing
closure. In my copious spare time I fend off the constant pestering from
mechanical engineering for their worrisome power dissipation estimates.
Just recently I released a netlist to the IBM foundry to begin detailed
place and route. I did not know about PhysOpt during this release process.
This was an 8M gate design, approximately 500K placeable objects, in IBM's
0.18u copper-interconnect technology. Approximately half the cell area is
consumed by large register-array and SRAM macros, and approximately 70% of
the die is utilized. Area-array I/O placement restrictions force the
pre-placement of I/O cells without regard to floorplan partition. The
netlist is created using our traditional design flow:
1) Write and simulate (cycle-based) multi-level hierarchical Verilog. We
use GENSIM, an internal Verilog cycle simulator that runs on Crays.
2) Synthesize into gates using DC. Ungroup and flatten into blocks of
approximately 50K cells; ungroup without regard to final floorplan.
Use ludicrously small wireload models, unreasonably high max_fanout
constraints, and promiscuous input/output delays. But choose target
library cells wisely; do not rely on the vendor defaults. Use ideal
nets for any signals which will be distributed and repowered at the
global level. Makefiles and lots of DC licenses facilitate the rapid
parallelized creation of the gate-level netlist.
3) Partition the gate-level netlist. The IBM physical guys prefer a flat
netlist because of data management issues, but logic design like me
prefer not to risk having 50K cell sub-designs spammed across the face
of the die. We compromise at a two-level hierarchy made of one- to
two-dozen floorplan blocks. My preferred floorplan tool is dry marker
in a room filled with white boards. Blue marker works best. Don't
write Verilog for this; just shuffle the 50K cell blocks and draw a
rectangle around the ones that result in point-to-point (reg-to-reg
preferred) adjacent inter-block communication. There is _no_ greater
insurance for post-physical design timing closure than planning
up-front for inter-block communication.
4) Incrementally synthesize the gate-level netlist using DC. Use group()
to gather multiple 50K cell designs into the one- to two-dozen
floorplan partitions, then flatten the partitions. Constrain the
partition input/output ports to one pin max. Maintain the original
ludicrous wireload models for internal paths, but nail the
between-block paths with pessimistic (even vulgar) CAP and RC
constraints. At the top level, use characterize() to propagate
top-level assertions down to floorplan block ports, then perform a
parallelized incremental compile on the floorplan blocks. Iterate on
characterize() and compile() 2-3 times.
5) Front-end process the floorplan netlist using the vendor's toolset.
Insert ideal clock trees, insert scan chains, etc.
6) Release the front-end-processed netlist to the IBM physical guys.
They Place-and-Route using the IBM proprietary toolset.
7) Spend the next three months converging on timing closure. Static
timing analysis allows rapid feedback of placement-based
optimizations. Hierarchical netlist enables parallel work. I
choose personally not to use PrimeTime because I sign off on timing
closure with IBM's EinsTimer static timing analysis tool anyway.
8) Final 3-D extraction of CAP and RC data for timing signoff. Do more
EinsTimer work.
9) Formal verification of gate-level netlist to pre-synthesis netlist
using Verplex. Release ASIC to manufacturing.
In the absence of a timing-driven placement tool, we iterate using
capacitance constraints to drive incremental placement. When necessary we
clone logic and restructure fanout trees by hand, or bitstack portions of
logic to seed an incremental placement. The IBM toolset supports in-place
optimization of drive strengths, but the placement has to be reasonable to
begin with. We extract CAP and RC into the stand-alone static timing
analysis tool, hand-create the ECOs to fix problems that placement alone
cannot remedy, and iterate. At no time do we back-annotate and throw the
design back over the wall into synthesis. That feed-back/feed-forward
mechanism tends to create more work than actual benefit.
After I "Stole" PhysOpt
-----------------------
I found out through the grapevine that one of our other projects here at
Cray had acquired a copy of PhysOpt. I'm not smart enough to work with
"smart" GUI's, and I don't have time to learn complicated tools or
resynthesize for the sake of re-synthesis, but I volunteered to use my
design for a quick performance evaluation. (John, this is a polite way of
saying that I was desperate so I stole their PhysOpt license after hours.
They were the ones who paid the $500,000 for the license. I don't think
they were exactly happy about this, but I had a chip due ASAP. They
understood, so they tolerated me for a short while.)
For gate netlist optimization, this is the flow I followed:
* Create the technology PDEF file. This file is used by PhysOpt to
describe cell sizes, cell pin locations, etc. I can't comment on
how long it actually took to create this file because it was the
one task I could actually hoist off the members of the other project.
* Create the floorplan LEF file. This file describes the floorplan
cell rows, routing resources, pin locations, obstructions, etc.
I found it was less work to create a generic parameterized LEF which
defines cell rows and floorplan area, then use the PhysOpt Tcl
commands to place the floorplan-specific ports and blockages.
It took an hour or two to create the generic file and then create
the floorplan-specific files.
* Create the floorplan Tcl script. This script reads the base technology
PDEF, the original *.db design, and the new floorplan LEF. It also
places the ports and places any obstructions caused at the top level.
All ports have to be assigned an initial location, but the locations
don't necessarily have to be legal. The Tcl commands are a nice way
to bitstack the bussed ports, pre-place the large register-array and
SRAM macros, and create blockages. It took about six hours per
floorplan block to create the files. (There were now a dozen floorplan
blocks altogether; and I pipelined the process.)
* Run PhysOpt. It took about six hours per floorplan block to optimize.
I ran several iterations on the first block (due to my operator error
during scripting), but the remaining blocks ran through with one
iteration only.
* Dump the design into a format that the IBM P&R tools understand. I
dump an output LEF that contains the placement information for cells
and pins. Run a Perl script to extract the cell locations from the
LEF and convert to Tcl commands for the IBM P&R tools. The PhysOpt
obstruction locations and port locations are thrown away. The real
obstructions are created and propagated by the IBM P&R tool, and the
real floorplan port locations are snapped to the cells that drive them.
Remember the importance of point-to-point inter-block communication...
My initial and overall impression of PhysOpt is... great start! The tool is
very easy to use once the basic setup is achieved. Not once did I have to
fire up a GUI, although I hear there is a separate viewing tool available.
(I loathe GUIs. Give me a Command Line Interface any day!) I was expecting
a simple placement of the existing design, but I can see that a great deal
of area is conserved during logic restructuring and area recovery.
The tool does a reasonable job at timing-driven placement, but it does an
even better job if the multi-cellrow-high cells are hand-placed first. All
but one floorplan block completed within 5% of the target design frequency.
That one floorplan block fails spectacularly on several paths because
PhysOpt doesn't see the cellrow space between the non-rectangular SRAM
macros. I'm just now getting a peek at wiring congestion within the IBM
tools. Although I did not run a separate PhysOpt run to specifically
address congestion, nothing I see today looks unreasonable or any worse than
our previously released ASICs. The 5% timing goal achievement is close
enough from my standpoint. The assumptions made during RC extraction are
gross, and the assumptions made about global wiring obstructions are
incomplete. The IBM tools are fully capable of taking the PhysOpt output
and completing the P&R task.
I can't quantify the final schedule benefit from PhysOpt because I'm just
now starting the physical design cycle (nor would I want to, lest management
find out and retask my performance plan).
I can say from experience that I'm now at least one month, maybe two, ahead
of where I would have been without PhysOpt and it only cost me a week's
worth of work. This result has definitely generated a stir around here at
Cray/SGI.
- Roger Bethard, Design Engineer
Cray/SGI Chippewa Falls, WI
( ESNUG 345 Item 2 ) ---------------------------------------------- [3/1/00]
Subject: ( ESNUG 339 #8 ) We Chose HDL-Lint Instead Of SureFire Or Avanti
> We evaluated Veritools' (http://www.veritools.com) HDLlint tool a few
> months back. We were impressed and purchased a seat. The tool is a
> command line program that lints Verilog code. They claim to do 100% of
> all the checks Verilint does (overpriced tool from Avanti, originally
> from interHDL). Veritools is offering their lint tool at a reasonable
> price compared with other alternatives.
>
> - Gareth O'Loughlin, Design Engineer
> Extreme Packet Devices Kanata, Ontario, Canada
From: Nathan Dohm <dohm@starbridgetech.com>
Hi John,
We are a small semiconductor startup, and as part of our tool selection
process, we were looking to purchase a lint tool. We are Verilog based, and
most of our designers have used Verilint in the past. We got a quote for
Verilint (now owned by Avanti), but felt that it was overpriced, so we
naturally looked for cheaper alternatives.
The one tool that we found was called HDL-Lint, sold by Veritools. (There
is apparently another tool called SureLint from SureFire Verification,
recently acquired by Verisity, but it was not available at the time of our
evaluation. I think it is still in alpha/beta stages at this point.)
HDL-Lint was developed by Everest Design Solutions, LLC, and is distributed
by Veritools. It is included in Veritools' Undertow suite (a waveform
viewing and debugging tool similar to Novus-Debussey) but is also
available as a standalone version. It can be run from the command line (we
run it from emacs), and uses the standard FlexLM license manager.
When we began evaluating the tool, we didn't have an established code base
to test it on (being a startup and all), so I created a few code examples
with typical problems in them. HDL-Lint only caught about half of the
problems. It was soon obvious that they were missing a lot of stuff. I
sent them a long note detailing the problems, and had pretty much dismissed
it as a possibility, but within 24 hours, they came back with a new version
with many of the problems fixed, and a promise to fix the rest quickly.
They also added a couple features we requested. Based on the cost savings
and excellent technical support, we purchased the tool.
HDL-Lint reports (at last count) around 300 code problems, categorized into
Errors (such as syntax errors), Warnings (such as inferred latches or
missing variables in sensitivity lists), and Notes (such as unused
parameters). More checks are added regularly, including a number of style
type checks which sites will want to turn off based on their coding
methodology (these include Notes on nested if statements, no default clause
in case, etc.)
HDL-Lint includes a number of options for turning messages off, either on
the command line or in the code; code-based options include turning messages
off in a block, a file, for a given number of lines, etc. There are a
number of output format modes, including emacs-parsable output (added at our
request) to enable easy checking of code from within emacs using the compile
and next-error commands. (Note that the newest versions of verilog-mode
from SureFire -- 3.37 and 3.38 -- break the standard parsing and require an
edit to get the next-error command to work with HDL-Lint.)
HDL-Lint has a number of interesting command line flags, including different
output formats, library directory and file includes (-y and -v), +define on
the command line, processing of Synopsys translate_off/translate_on
directives, little endian enforcing, and input parameters from files. It
also supports user-supplied Perl code for additional style enforcement, but
we haven't tried this though.
Over the last few months, we have continued to find some problems here and
there (mainly in the form of reporting warnings where it shouldn't) but they
have been resolved quickly. At this point, the tool is a vital part of our
code development.
- Nathan Dohm
StarBridge Technologies Marlboro, MA
( ESNUG 345 Item 3 ) ---------------------------------------------- [3/1/00]
From: HongLiang Chang <hchang@cs.umn.edu>
Subject: Anyone Have A Cadence Silicon Ensemble Library For A Grad Student?
Hi, John,
I'm a graduate student in computer science. I'm now implementing layout
with the Cadence Silicon Ensemble tool. But we don't have the cell library
together with the tool. Is there someone who can tell me where can I find
and download such a library that is compatible with Silicon Ensemble?
- HongLiang Chang
University of Minnesota
( ESNUG 345 Item 4 ) ---------------------------------------------- [3/1/00]
Subject: ( ESNUG 344 #5 ) PhysOpt: 11 Runs; Timing-Driven Qplace: 2nd Base
> Doing PhysOpt synthesis and placement takes a lot of CPU time. Most of
> our blocks ran in 2-24 hours, but we had one large nasty block which took
> over 80 hours to complete because we didn't take a true hierarchical
> approach with it. (This block was over 1/4 of the entire chip in our
> multi-million gate design.) ... Ouch. What we saw with this flat
> routing approach were that the global routes over modules sometimes
> interfering with the local routes of those modules, throwing the
> estimates that PhysOpt made on those nets off (sometimes by more than
> 1mm!). Ouch.
>
> - David Romanauskas, Design Engineer
> Matrox Montreal, Canada
From: Dave Balhiser <balhiser@fc.hp.com>
Hi, John,
At my division in Agilent, we're fanatics about using a pure hierarchical
methodology for everything (placing, routing, and static timing.) This way
we can easily turn parts of the design independently and quickly. In our
standard cell designs, subdividing the place and route problem also helps
to improve the correlation between wireload model (WLM) based timing and
extracted timing.
For us, a "block" is the level of the hierarchy at which standard-cell place
and route is performed. A "block" can also refer to a piece of IP such as
a RAM, ROM, or other hard macro. Our design flow supports n levels of
hierarchy allowing several blocks to be routed together to form a "n+1"
block, and these meta-blocks are routed together to form a chip.
Because our approach is block-based we can mix and match our P&R methods
on a per-block basis within a chip. We had been using Silicon Ensemble
5.2QSR3 for place and route. In general, ~75% of our blocks benefited
from using SE's timing-driven features; though some blocks did much better
with SE's timing-driven features turned off.
Nonetheless, we've found that the difference between WLM timing and
extracted timing for challenging blocks can deviate by up to 40% of clock
period. Because of this, we looked into PhysOpt, too.
Our Plain Vanilla SE Flow
-------------------------
1. Start with a flat Verilog netlist for a block. This netlist is based
on synthesis to a custom WLM.
2. Create a block floorplan for the block based on the chip floorplan.
(We used some in-house proprietary tools plus PrimeTime budgeting
and some hacks to do this.)
3. Place the block with Cadence timing-driven Qplace.
4. Connect the scan chain(s) with Silicon Ensemble's troute.
5. Route with timing-driven Warproute. (But don't always use the
timing-driven Warproute -- to our surprise, we've discovered that some
non-timing-driven Warproute runs gave better results!)
6. Extract timing with our in-house RC extract tool and create DSPF.
7. Perform static timing with Primetime. (PrimeTime had difficulties
handling detailed parasitic info between blocks. You can't budget
between hierarchical pins in PrimeTime and we had to hack a
complicated workaround to get it to work.)
8. If needed, fix timing violations with any number of "tricks". (The
least of these tricks include re-routing, and often includes going
all the way back to Step 2.)
Enter PhysOpt
-------------
We're currently using PhysOpt on a 3.7 million gate, predominantly standard
cell, 3.3 nsec design with many latency sensitive paths. Many of our paths
come in through a chip pin, through the pad, through about 20 levels of
logic, to a register, through another 20-odd levels of logic and out of a
chip pin on the other side of the die. These single-cycle latency paths
can traverse several blocks, making the inside the block timing quite
challenging. It is not uncommon for a 10-level logic path in a block to be
budgeted only 900 ps to enter and exit the block.
Our goal with our Plain Vanilla SE Flow was to avoid resorting to the
iterations and the tricks mentioned in Step 8. For 10 out of our 30 blocks
this was possible. For 12 more blocks, we were able to meet block timing
with numerous iterations and some labor-intensive tricks. Not good.
These 12 blocks initially missed spec by 200-700 ps. That left 8 blocks that
kept our designers busy using time-consuming tricks to meet spec: pre-routes,
pre-placements, and even hand-routes of critical signals. These are the
blocks that without manual intervention missed the target clock period by
about 700-1200 ps.
Our hope was that PhysOpt was an automated approach to closing those timing
loops. We've been using it on a block-by-block basis on our design. Our
new flow remained largely unchanged with the exception of Step 3, where we
replaced the timing-driven SE Qplace with PhysOpt. (We also added a formal
verification step to make sure PhysOpt kept the original functionality just
to be safe.)
My only minor gripes with PhysOpt are the data translations we had to do.
PhysOpt needs both a db and a pdb file. Db's come from Design Compiler.
To make a pdb, you need to craft a LEF library of all the basic cells used
in your design (AND, NAND, NOR, FF's, etc.) Then you run lef2plib. Then
we had to hand edit the plib file because of a bus naming style problem.
Then in psyn_shell we did a "read_lib" followed by a "write_lib -o" to
finally get the pdb we need. This should be an automated process, not
something we have to do by hand.
For discussion purposes, I'm going to refer to three general categories of
blocks as "easy", "medium", and "hard". "Easy" means slam dunk with
traditional SE methods. "Medium" means that a few iterations are needed.
"Hard" means a lot of hard work and manual intervention is needed.
All of our blocks were 30K to 75K gates, with our typical PhysOpt runs
being: 30 minutes for an "easy" block; 2-3 hours for a "medium" block; and
5-6 hours for a "hard" block.
For "easy" blocks the PhysOpt command was simply:
physopt
For the most difficult blocks we had to tune our script. This "medium"
script example runs about 3X longer, but worked well:
physopt -effort medium -area_recovery
run_router -effort high
physopt -incr -effort high -congestion -congestion_effort high \
-area_recovery
physopt -incr -effort medium -area_recovery
What We Found
-------------
So far, we've only run PhysOpt on 12 blocks. There were 4 "easy", 6
"medium", and 2 "hard" block in these 12. With PhysOpt we have been able
to make 11 of these 12 meet timing. Only one of the "hard" blocks gave
PhysOpt significant trouble. (Depending on how we tweaked our script,
PhysOpt placement either created an optimized netlist that was too big to
fit in the block (floorplan) -- or -- the final PhysOpt placement was
unrouteable in SE.)
On this problem child block we had to switch back to Cadence's Qplace
(in timing-driven mode and without PBopt). Reverting back to this
labor-intensive mode, we got our problem child block within 120 ps
(extracted timing) of spec. Closer, but still not there.
For the other remaining 11 blocks, our PhysOpt results were very positive.
The "easy" blocks remain "easy"; the "medium" blocks became "easy" (they go
right through with little or no manual intervention), and the other "hard"
block became a "medium" -- we only had to play a few tricks to meet timing.
The important thing to note here, John, was that those 11 blocks were
handled automatically by PhysOpt. For us, hassle-free EDA == Good News.
In baseball terms, what we're seeing is 11 home runs by PhysOpt and 1 run
to 2nd base by timing-driven Qplace.
We have noticed that with the 1.0 HP build of PhysOpt, the run_router
command should not be run before timing reports -- it makes the timing
reports far too pessimistic. (The run_router command does global and/or
steiner route estimates depending on which level you use it on.) You must
run "physopt -incr" after every "run_router" command or you'll have some
very messed up timing reports.
We have also noticed that the first "physopt" command should not be run
with the "-congestion" flag because it puts registers in really bad initial
locations that subsequent incremental runs can't improve. (This was our
first for STAR for PhysOpt.)
My last gripe about PhysOpt is the hassle involved with trying to pre-place
physical cells not in the logical netlist. (These cells have no Verilog
function but we still need them. Some examples: clock buffers, scan logic,
and spare cells.) We had to trick PhysOpt by creating layer 0 obstructions
in a TCL directives file for PhysOpt for these pre-placed cells. Then let
PhysOpt place everything else around the pre-placed cells. PhysOpt outputs
a db. Then db2def followed our set of homebrew Perl scripts to finally
sew all the DEF files back together. This should be automated just like
how the prior LEF/plib/pdb translation should be automated.
We have not had a chance to take blocks with embedded hard macros completely
through the PhysOpt flow. This is next on our agenda, and it will be
interesting to see what it does with them.
These caveats not withstanding, PhysOpt has made us more productive by
keeping our "easy" blocks "easy", making our "medium" blocks "easy", and
that one "hard" block became "medium". It has been quite stable for beta
code, and is reasonably easy to learn (~1 week) for someone familiar with
Design Compiler and backend tools.
We expect to tape-out in 2-3 months.
- Dave Balhiser
Agilent Technologies Ft. Collins, CO
( ESNUG 345 Item 5 ) ---------------------------------------------- [3/1/00]
Subject: ( ESNUG 342 #3 ) Synchronicity's DesignSync -- A True Nightmare
> This is a survey and question about RCS. I would like to know in the
> Verilog world who's using RCS revision control software. I have used it
> and found it quite useful to manage projects particularly when it was
> being used with a GUI (i.e. Renoir, CS-RCS etc). I was wondering if
> others have had the same experience and what company you're with (i.e.
> no vendors saying how much we need it). Thank you for your help.
>
> - Joshua Schwartz
> Redux Communications Israel
From: [ Synchronicity Is Marketing Hype ]
John,
Please keep me anonymous on this one.
For years (15+) the most successful tool I've used in CVS. It's free,
handles multiple files simultaneously, extremely customizable, has
options for distributed secure Internet use, works on many platforms
(including Windows NT, Linux and even Mac) and has commercial support
if you want it. There are even multiple platform GUI's available if
you need it. CVS is built on top of RCS or SCCS (it's your choice --
most choose RCS).
Then there is DesignSync by Synchronicity designed for EDA... Don't
do it! It's marketing hype. It has a fancy GUI, but lacks sufficient
maturity. There are a ton of things it does not do well at all (e.g.
handling branch merges, reporting updates, portability of shadows).
With their network architecture, the tool is very slow (compared with
CVS) even with encryption turned off. Worst of all, there are nasty
bugs that don't seem to get fixed very fast. They designed the
product with Windows NT and management (the buyers) in mind. There is
a cool link for project tracking. Too bad the tool is hard to install
and users seem to universally be confused by their training and
terminology. Synchronicity touts their TCL interface, but it's just a
cover for the poor job they've done. Eventually Synchronicity may get
to the same level as CVS, but why wait? Why pay for inferiority and
pain when CVS works and is available free? Commercial support is
available if you don't have the support staff.
- [ Synchronicity Is Marketing Hype ]
---- ---- ---- ---- ---- ---- ----
From: "Tommy Kelly" <tommyk@dcs.gla.ac.uk>
Jon,
I've used RCS, CVS and ClearCase. RCS provides only revision control,
which is only one component of Configuration Management. It is simply not
sufficient for management of a large chip with more than a couple of
engineers. That's why most RCS users will find themselves adding
make/perl-type script support around about RCS. Been there, done that,
bought ClearCase.
In my experience, some of the major components of config. management (i.e.
manging the complex configuration of your design database, as it grows and
changes throughout its life) -- and these apply to HDL-based chip design as
much as to s/w design -- are:
a. Version control (tracking changes to files and directories)
b. Build management (bolting all those files together)
c. Workspace management (allowing parallel, concurrent development)
d. Process control (enforcing design policy - e.g. auto-running a code
lint before allowing a code change to be checked in)
e. Release management (baselining and labelling a snapshot of the design)
f. Bug tracking (bugs?, what bugs!?)
g. Remote working support (doing all of the above from different
geographical locations)
RCS provides only a., and even there it does it only for files and not for
directories. CVS gives a., including some directory versioning, c., d.,
and e. ClearCase does a-e and does them all in generally more powerful
ways than CVS. It has a Very Cool approach to b. in that it provides a
version of unix "make" which does implicit dependency detection.
ClearCase's d. (process control) is more powerful than that of CVS, but
essentially both provide for pre and post operation trigger scripts.
None of the three provide f., but I think there's a ClearCase DDTS
integration. And you can sit gnats or something similar next to RCS, SCCS,
CVS or whatever.
CVS can do g., via anonymous ftp or ssh. ClearCase has a bolt-on called
MultiSite which does the same thing.
ClearCase's major drawback is its admin overhead. If you are lucky enough
to have a *full-time* UNIX administrator/EDA engineer, then you may get
away with ClearCase. If your design is big enough you should probably
consider having a full time Configuration Manager in addition to your
SysAdmin. Otherwise, consider CVS, PRCS or similar. RCS just won't cut it
for most designs.
Final point: none of these tools is a silver bullet. Successful CM,
particularly in the heterogeneous world that is VLSI design, is as much a
social thing as a technical one. These tools don't cause the design
complexity, nor do they themselves solve it. The complexity is inherent in
big design, and good professional practice -- in coding styles, data
structuring, change management -- is what is ultimately required.
ClearCase, etc. merely provide the mechanisms for implementing that
practice. I'd give yourself at least a year, and one or two projects
*after* installing your tool of choice before you'll feel that you're
beginning to crack this problem.
- Tommy Kelly Somewhere, England
---- ---- ---- ---- ---- ---- ----
From: [ We Got Burned, Too ]
Hi, John,
Please keep me anonymous on this one!
We're using ClearCase for ASIC design & it works great. We used DesignSync
from Synchronicity on one project and it was a disaster. DesignSync is like
an early beta version of RCS that they charge a lot of money for! We had
problems with corrupted databases and lost files. In ClearCase we see
nothing like this. It just works in the background as a good revison
control system should do. In the past we have used RCS on many projects but
it started to consume a lot of the designers time to manage the system and
create scripts so we started to look around for alternatives. After the
DesignSync mistake we have settled on ClearCase, which is also the system
our software designers are using.
- [ We Got Burned, Too ]
---- ---- ---- ---- ---- ---- ----
From: Ray Salemi <rays@exemplar.com>
Hi John,
Clearcase is an extremely powerful configuration managment system. It
manages remote sites well and it is just about fool-proof in that you cannot
trick it by changing permissions, etc.
It is tough to install and bring up as your configuration tool. It requires
quite a bit of planning and commitment to move to it. However, once you've
made the transition there is no better tool for managing large designs.
We chose Clearcase for two reasons:
1. We had a bi-coastal design project and had to share design files.
2. We had very large design directories. So each time someone wanted to
create a new workspace they had to copy several hundred megabytes of
data. This ate a lot of local disk space and it took several hours
to create the new workspace.
Clearcase lets you create a new workspace in seconds. It doesn't copy the
files to your machine until you check them out. If you don't check them
out, you see the files as a remote file system mounted on your machine. You
can switch between different releases of your chip with one command without
having to re-copy the design files.
You get this functionality at a price. Clearcase uses a ton of network
bandwidth, and it can push the compute power of workstations. There is a
significant learning curve. (During the learning curve users will
accidently get in a state where it appears they have deleted all their
files. This is stressful for the users though sometimes amusing to the
support staff.)
Clearcase is also tricky to integrate with LSF for server farms.
Overall, if you've got a large ASIC project clearcase can handle it. It's
the most powerful tool on the market and I think it was worth the learning
curve.
- Ray Salemi
Exemplar Logic
( ESNUG 345 Item 6 ) ---------------------------------------------- [3/1/00]
Subject: ( ESNUG 343 #10 ) Missing: A Meaty DC Library Developer's Guide
> We always had the library problems mentioned (unpredictable synthesis
> results per a library change). This is the first time we got some kind
> of a guide from the Israel Synopsys support team. It's a 10 page article
> in SolvNet titled "DC Library Ultra Guidelines" (October 1999) and it has
> the detailed description of the new DC timing model, how to analyze a
> .lib, and plus basic library developer guidelines for their new timing
> model. It's Synthesis-625.html on SolvNet.
>
> A good, meaty guideline of library developing is sure missing.
>
> - Doron Nisenbaum
> Chip Express (Israel) Haifa, Israel
From: Chris Kiegle <ckiegle@us.ibm.com>
Hi John,
I just wanted to say thanks to Doron Nisenbaum for pointing out the article
on the DC Ultra library guidelines (Synthesis-625.html on SolvNet).
We have been spending a lot of time over the last year or so trying to
examine library structure, content, and the ways that Design Compiler
responds to the library. This task is made even more difficult in creating
a library for use with multiple synthesis tools. We have gotten a lot of
good information from Synopsys about library expectations and library
analysis for Design Compiler. Most of this has come through SVP
connections.
My hope is that Synopsys will provide more information similar to these
library guidelines, make it available to both library developers and chip
designers, and relate it to all the tools. For example, is a library tuned
toward DC Ultra also going to work well with Module Compiler? What are the
constraints that a designer sets that may impact the library analysis & how?
Perhaps an intermediate step could be added to synthesis to spit out the
results of the library analysis and to report the set of cells the synthesis
is initially targeting? That information would be helpful to both library
developers and chip designers to help steer synthesis and make more educated
choices for constraints that impact the initial mapping (and possibly the
implementation selection), like wire load models & set_prefer.
- Chris Kiegle
IBM Microelectronics Burlington, VT
( ESNUG 345 Item 7 ) ---------------------------------------------- [3/1/00]
Subject: ( ESNUG 343 #5 ) "Don't Care" X's In DC 99.05/.10 Are Messed Up
> Here's a recent issue I found with Synopsys DC 99.05/.10 that other users
> may be interested in hearing about. I have a wire defined as:
>
> assign mask3 = {byte1[7],6'hx,byte1[7],byte2[7],byte2[7],5'hx,byte2[7],
> byte1[6],6'hx,byte1[6],byte2[6],byte2[6],5'hx,byte2[6],
> byte1[5],6'hx,byte1[5],byte2[5],byte2[5],5'hx,byte2[5],
> byte1[4],6'hx,byte1[4],byte2[4],byte2[4],5'hx,byte2[4],
> byte1[3],6'hx,byte1[3],byte2[3],byte2[3],5'hx,byte2[3],
> byte1[2],6'hx,byte1[2],byte2[2],byte2[2],5'hx,byte2[2],
> byte1[1],6'hx,byte1[1],byte2[1],byte2[1],5'hx,byte2[1],
> byte1[0],6'hx,byte1[0],byte2[0],byte2[0],5'hx,byte2[0]};
>
> And used in the RTL as:
>
> casex({ena1, ena2, ena3, ena4, DATA[191:0]})
> {1'b1, 1'bx, 1'b0, 1'b1, 1'bx,mask1,63'hx}: flag <= #1 1;
> {1'b0, 1'b1, 1'b0, 1'b1, 1'bx,mask2,63'hx}: flag <= #1 1;
> {1'b0, 1'b0, 1'b0, 1'b1, 1'bx,mask3,63'hx}: flag <= #1 1;
> default: flag <= #1 0;
> endcase
>
> Well, it turns out DC is not carrying the "don't care" x's over into the
> casex statements correctly when analyzing/mapping/etc of the RTL.
> Verilog-XL sims are functionally correct, but the gate-level are wrong.
> When I edit the RTL and place the wire assignment value directly into the
> casex statements, all is fine with the Synopsys gate-level result. I let
> Synopsys know about this problem and they have been examining the problem
> for the last several weeks. If it is an illegal coding style, Synopsys DC
> never complains about it.
>
> - Mike Jarchi
> Vitesse Semiconductor Corp. Camarillo, CA
From: Vigyan Singhal <vigyan@home.com>
To: Michael Jarchi <jarchi@vitesse.com>
Hi Mike,
What you have found is not a synthesis bug, but a problem with a synthesis
and simulation semantic mismatch when signals are assigned to "X"s. I am
surprised that Synopsys is taking weeks to figure this one out! Let me
explain the reasoning, using a simple example, inspired by your design:
module test(cond, tag, value, data);
input cond, tag;
output value, data;
reg data;
assign value = cond ? 1'b0; 1'bx;
always @(tag or value) begin
casex(tag)
value : data <= 1'b0;
default: data <= 1'b1;
endcase
end
endmodule
Consider the case when "cond" is 0. Depending on the synthesis tool you
have, the value of "value" will be either 0 or 1 (and not X, unlike
simulation; most synthesis tools will pick 0 in order to simplify the
logic). Regardless of whether the synthesis tool chooses 0 or 1, you will
have a synthesis-simulation mismatch. See below:
If the synthesized gates set "value" to 0 (when "cond" is 0):
simulation: when input "tag" is 1, output "data" will be 0
synthesis: when input "tag" is 1, output "data" will be 1
If the synthesized gates set "value" to 1 (when "cond" is 0):
simulation: when input "tag" is 0, output "data" will be 0
synthesis: when input "tag" is 0, output "data" will be 1
I do not know any way around this. If it was me, I would in-line the
assignment into the case statement (like you already tried), AND use
"casez" instead of "casex" (the latter for different reasons; see the
ESNUG'99 article from Mills/Cummings).
- Vigyan Singhal
---- ---- ---- ---- ---- ---- ----
From: Michael Jarchi <jarchi@vitesse.com>
Hi John,
I sent the text of Vigyan Singhal's email to me to the Synopsys tech support
engineer working my case. He was not making a lot of headway with their
Formaility equivalence checker as it ran for over 2 days before he had to
kill the run. (As a side note even Chrysalis with the correct design took
only a few hours.) In any event, Vigyan's comments made sense to me given
that my workaround was successful; our CAD group also pulled something
similar from the SNUG'99 Proceedings. Basically, there is an issue with the
usage/interpretation of "don't cares". This is not the same issue regarding
"X"(unknown) in simulation and "x"(don't care) in synthesis where mismatches
can occur and are dangerous. This is more of DC assigning a value (0/1) to
the "dont care" assignment prior to insertion into the casex statement. My
solution, as was Vigyan's, was to paste the assignment statement directly
into the casex statement to work around this problem. The closure from my
understanding is that Synopsys planned on putting this explanation into
their support database for future issues related to this. I did not get the
feeling that this was interpreted as a DC "bug". Another case why even for
RTL-to-Gate compares, Formal Verification has huge value.
- Mike Jarchi
Vitesse Semiconductor Corp. Camarillo, CA
( ESNUG 345 Item 8 ) ---------------------------------------------- [3/1/00]
From: Carl Christensen <carl.christensen@philips.com>
Subject: Bogus TCL "Help" Files In FPGA Express Trashes Xilinx GSR Mapping
Hi, John,
I use the TCL based scripting of FPGA Express to automate my synthesis. I
ran into a problem when I tried to set a switch to ignore unlinked cells
when mapping the GSR (Global Set Reset) for a Xilinx part. In the GUI there
is a switch when editing constraints that you set if you want to ignore
unlinked cells. The normal reason for this is if you are using a core of
some type. Anyway the FST documentation is pretty limited but in this case
it appears to have the exact information I needed. It clearly states that
there is a pre-defined variable:
proj_gsr_ignore_unlinked_cells = "yes" (default)
Wait a minute if it's default was "yes" it should have already been doing
what I want. After trying to set the thing to "yes" every which way and at
every point in my script without any luck, I finally used the printvar
command to confirm that in fact the variable doesn't exist at all. (With
TCL's declare at usage it does after you try to change the value.) The
correct way to ignore unlinked cells for GSR insertion is with the
set_chip_gsr_ignore_unlinked_cells
command. Which isn't mentioned at all in the windows help pages. Thanks to
Loren Lacy at Xilinx for helping me find the correct command. If you use
FST you've probably found that most of the information is only in the man
pages. There is also a help available from the shell. For example help
*gsr* brings up the set_chip_gsr_ignore_unlinked_cells command which you can
then to a man page on. I'm not sure if the "windows help" mentions the
command line help if it does I missed it somewhere. It's not super useful
but at this point anything on FST can be helpful.
I believe the same issue would apply to FPGA Compiler II also.
- Carl Christensen
Philips Digital Video Systems
( ESNUG 345 Item 9 ) ---------------------------------------------- [3/1/00]
From: Kevin Campbell <kcampbell@avici.com>
Subject: Ouch! We Got Burned By Our Motive-To-Primetime Script Conversion!
Hi, John,
We decided to take the plunge and use PrimeTime instead of Motive for static
timing analysis on our latest chip. Using the documentation available (both
from AE's and available on SOLV-IT) we translated our Motive .ref and .mcp
files to PrimeTime Tcl scripts.
Upon completion of the initial analysis, we noticed more margin than
expected on chip outputs min delays. If you blindly copy the Motive to
PrimeTime translation suggestions, and you have positive hold Tsh
requirements, you will effectively relax your external hold requirements,
and have paths that would fail in Motive pass in PrimeTime.
Here's our example. In Motive .ref:
TSH NET sram_data_0..15 REF sram_clk EDGE R SETUP 5.0 5.0 HOLD 2.0 2.0
PrimeTime commands according to docs:
set_output_delay 5.0 -max -clock sram_clk [get_port sram_data_*]
set_output_delay 2.0 -min -clock sram_clk [get_port sram_data_*]
I would expect "set_output_delay -min" to subtract the 2 ns from the min
data delay and compare to clock edge for hold. Instead, 2 ns is subtracted
from the Clock which moves the hold check in the wrong direction. The
correct command should be:
set_output_delay -2.0 -min -clock sram_clk [get_port sram_data_*]
Same story as always -- never trust a blind translation between tools!
-Kevin Campbell
Avici Systems Billerica MA
( ESNUG 345 Item 10 ) --------------------------------------------- [3/1/00]
Subject: ( ESNUG 344 #8 ) Superlog, Maybe. But C++ HW Design Is A Joke
> The problem with Superlog is that it's a new language. Most designers
> know C today. Why not take advantage of a universal language like C++
> and use it for both its ability to look like Verilog as well as its
> verification and design extensibility capabilities?
>
> - Bill Steinmetz
> Cisco Systems
From: Anders Nordstrom <andersn@nortelnetworks.com>
Hi, John,
I do not agree with Bill at all. I don't see Superlog as a new language, I
see it as an evolution of Verilog. You can use whatever language you like
as long as it is compatible with Verilog. We are using Verilog exclusively
for design and verification and by now we have 50 million lines of Verilog
code that we are not going to replace. I know some C but I am not using it
for design or verification, neither is anyone else that I know around here.
C++ is even more of an unknown! Yes you can make C look like Verilog if
you are using some of the tools like CynApps but the designer have to
rewrite his code several time to make behave like Verilog and then what is
the point. Surely there are instances where C is a better language, but
using C in isolation and trying to link it to a Verilog simulation via the
PLI I don't think is the right solution. A much tighter coupling between
the two languages is required and ONE way of achieving that is SuperLog.
- Anders Nordstrom
Nortel Networks Ottawa, Ontario, Canada
( ESNUG 345 Item 11 ) --------------------------------------------- [3/1/00]
Subject: ( ESNUG 344 #9 ) Some DC Rumors & Running TCL In Design Analyzer
> Oh Great! We get our entire synthesis environment setup for TCL-based
> scripting (DC, PT, etc) and find out that Design Analyzer doesn't support
> TCL. This really blows chunks, considering there is no elegant way to
> automagically determine if you would like TCL or DC-flavored usage in your
> ~/.synopsys_dc.setup file. Hence any DA usage must now have a separate
> kludge to get the library paths, environment setups, etc to work! Yuck!
>
> Rumours say that Synposys is re-writing the GUI interface of Design
> Analyzer to be TCL-friendly, but that isn't available now when I need it.
> Now why can't Synopsys release tools (DA & DC) that at least work together
> in a nice fashion?
>
> - Gregg Lahti
> Intel Corp Chandler, AZ
From: [ A New Jersey Synopsys CAE ]
Good morning John! I'm an AC in the New Jersey office, just figured I'd
drop you a line with a few helpful bits of info.
1. Gregg only needs one setup file (thankfully)! I thought the same thing
as he when I found out that DA was DCSH-only. However, you can write a
.synopsys_dc.setup in a format called "Tcl-S", or "Tcl Subset" which is
basically a Tcl setup file which allows a certain subset of commands.
The trick to this is that the first line has to begin with a '#'
character. This setup file WILL be understood by DC, DC-Tcl, and DA!
Cool, eh? Here's my setup file:
# Tcl-s
target_library = {lsi_10k.db}
synthetic_library = { dw_foundation.sldb }
link_library = "* $target_library $synthetic_library"
bc_fsm_coding_style = "two_hot"
# automatically source any Tcl procedures available for use
suppress_message CMD-041
foreach _script [glob ~/tcl/*.tcl] {source $_script}
foreach _script [glob ~/tcl/*.tcl] {source $_script}
unsuppress_message CMD-041
unset _script
Have no fear, you can definitely intermix shell types without fear of
complex setup file tricks! Without this, we ACs (who must jump between
shells a lot) would be in pretty bad shape too.
2. Design Vision is indeed in beta, and it is available to customers. It
will support both DCSH *and* Tcl. Customers are encouraged to sign up
for the beta. Simply go to our homepage at http://www.synopsys.com/,
and click on "Synopsys' 2000.05 Synthesis Beta Program" in the Product
News column. The Design Vision section is towards the bottom.
Personally I myself am a huge Tcl advocate, and I'm glad to see customers
moving to it.
- [ A New Jersey Synopsys CAE ]
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys Marketingdroid ]
Hi, John,
The rumors Gregg heard are true. We are implementing a new GUI for Design
Compiler that supports both dc_shell and DC-Tcl. The new GUI supports
advanced analysis capabilities in addition to existing Design Analyzer
features. The new capabilities in the tool are:
1. Hierarchy Browser - a tree control capability that enables easy
design navigation.
2. Timing Histograms - a high-level view into a design's timing issues
End Point Histogram - an overall picture of timing
Path Slack Histogram - all paths through a pin, port, net
Net Capacitance Histogram - an overall picture of net capacitance
3. Path Schematic - A simple schematic view of one or more timing paths,
paths that span multiple hierarchical levels, and fanin/out can be
easily added to nodes in the path
Knowing how you feel about us, John, you'll probably edit out anything more
that I say which promotes this tool anyway. So I'll stop now. :)
- [ A Synopsys Marketingdroid ]
( ESNUG 345 Item 12 ) --------------------------------------------- [3/1/00]
Subject: ( ESNUG 342 #10 ) "Model" Command & Fake DC Library Elements
> I did a 'man model' in DC 98.02, and found a help page for the 'model'
> command, but don't find one in DC 99.10. It sounds like a useful feature,
> but where did it go? Maybe Synopsys removed a feature, or maybe they just
> didn't bother to include it with the documentation (our install of 99.10
> was missing about a bunch of the man pages, because they just didn't fit
> on the disk we got from Synopsys).
>
> - [ Where's The Beef? ]
From: "Matthias Brucke" <Matthias.Brucke@Offis.de>
Hi John,
The feature is still there, but propably "Beef" here hasn't installed the
sold_patch_10-3. It works here at our site and we have installed the
patch. Look at Doc-84.html on SolvNet.
- Matthias Brucke
Universitaet Oldenburg Oldenburg, Germany
|
|
