From: Cliff Cummings <cliffc@sunburst-design.com>
Honorable John -
Since you're the Chief Justice of the ESNUG Supreme Court of EDA Public
Opinion, and since I lost the "Best Paper" Award at this year's Boston
SNUG by only 3/100ths of a point, I'm petitioning you for a re-count.
0.) I would first like the ballots optically scanned to see if I won.
If that does not work, I want the ballots counted by hand to see
if I won.
1.) The Caterpillar Ballot was obviously designed to confuse the
older engineers who wear glasses. See for yourself, your honor.
best worst
"I would rank this paper overall" 0 0 0 0 0
Some engineers would mistakenly check the far right 0 thinking
of it as a bar graph (due to the natural right hand bias most
people have.) If need be, I can have Kurt Baty testify that he was
confused by that trick ballot.
2.) My presentation was given just before the Tensilica paper that some
have accused of being a marketing presentation. You should look
closely at the ballots because some voters might have down-voted my
paper due to proximity to the bubbles of the Tensilica talk.
3.) Some voters might have been out of ink by the time they got to my
ballot and might have only made an indent in the bubble, so I would
like a ruling from you, John, that all indented bubbles on my ballots
should be counted in my favor because that was their obvious intent.
4.) There are more Verilog users on the West Coast that would have voted
in my favor so I think a final tally should have not be certified
until all the West Coast absentee ballots have been counted.
5.) There were people who attended 3rd-party presentations (like Nortel's
afterhours recruiting event) who missed voting. I would like to hold
a re-vote with *all* of the SNUG attendees voting only for one of the
two best papers.
In closing, I'd like to say that I know there were dozens of uncounted
votes in the Boston SNUG Best Paper Award and that I'm only working to
make sure everyone's vote is counted. This has nothing to do with me nor
Al Gore not liking the results of our elections. Instead, John, we are
Solders for Truth, and I beg your support in my petition for this recount.
- Cliff Cummings
Sunburst Design, Inc. Beaverton, OR
( ESNUG 362 Subjects ) ------------------------------------------- [11/30/00]
Item 1 : How I Almost Lost My Job At LSI Logic Doing Two PhysOpt Tapeouts
Item 2 : Customer Musings On Tcl, DC, Presto, PrimeTime, ACS, & PhysOpt
Item 3 : Scriptlet To Make dc_shell-tcl Shut Up About Non-Error "Errors"
Item 4 : What Do Users Think About Verisity's Specman? Should I Work There?
Item 5 : ( ESNUG 359 #8 ) Other UNIX Tips & Tricks For Those Long EDA Runs
Item 6 : ( ESNUG 359 #9 ) How We Use ClearCase To Manage ASIC Design Data
Item 7 : ( ESNUG 359 #7 ) My Design's Small; I Need Cheap-But-Good ATPG
Item 8 : Janick Pisses On Superlog; Supports Vera And Verity's "E" Instead
Item 9 : ( ESNUG 361 #1 ) PKS Tape-out, Layout Staffs, Project Schedules
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 362 Item 1 ) --------------------------------------------- [11/30/00]
From: Vijay Angarai <angarai@lsil.com>
Subject: How I Almost Lost My Job At LSI Logic Doing Two PhysOpt Tapeouts
Hi John,
I almost lost my job because we used PhysOpt.
I'm a design engineer in the DSP division of LSI Logic here in Dallas. We
were working on two ZSP chip cores. (I can't tell you their project names,
so I'll just call them "Chip #1" and "Chip #2" for the purposes of this
letter.) The ZSP chip cores are licensable for our customers and they're
superscalar RISC processors designed to give 800 MIPS at 200 Mhz. My job
was to tape them out in LSI's low power 0.18 (G12L) and high performance
(G12P) libraries. My goals were:
Chip #1 Chip #2
-------------- -------------------
Goal low power high performance
Lib LSI G12L LSI G12P
Clock 10 nsec (gated) 6.25 nsec (non-gated)
Metal 4 layer 5 layer
Size under 4 mm2 under 6 mm2
Mem 64 K instruction 64 K instruction
64 K data 64 K data
I started out using a standard tape-out flow. This is when my life started
to go downhill. Here was my flow:
RTL -> DC -> Gate Netlist -> "compile -scan" -> pre-layout netlist
It was nothing fancy. For layout, I did:
Prelayout netlist -> Avanti Placement -> Physical resynthesis (Saturn
and LSI upsize/downsize internal tool) -> Apollo CTS -> Apollo Route
-> RC Extraction -> PrimeTime
Although we called it our "Days of Hell" tape-out, this miserable process
took us 3 months to do. It was like being part of a secret CIA experiment
to test the limits of human sanity. I would run a chip through Design
Compiler and using its conservative WLMs, DC would tell me it made timing.
Then, in the Avanti placement, we'd be 2 to 3 nsec off on timing. After
Avanti Saturn resynth and LSI resizing, the best we could get was 1 nsec
off spec. Go back to try to fix things. We looped like this forever. Our
fundamental problem was that we were working with three different timing
engines that didn't agree with each other: the Synopsys DC engine, the
Avanti Saturn enginine, and our internal LSI engine. Finally, after 3
months of this we just decided to stop. Here were our results:
Chip #1 Chip #2
-------------- -------------------
# of Cells 79,000 instances 80,000 instances
Size 4.2 mm2 6.0 mm2
Timing 11.0 nsec (1 nsec off) 7.0 nsec (0.75 nsec off)
My Brush With Unemployment
--------------------------
Since we were so far off after 3 months of timing Hell, we decided to give
Synopsys a call to see if their PhysOpt tool could save us. Since Chip #2
was the most recent chip I was running through in the old flow, I decided to
run Chip #2 in the new PhysOpt flow for our eval.
That was my mistake.
Our new flow changed only slightly. We just swapped PhysOpt for the Avanti
placement and Avanti Saturn steps in our old flow.
Prelayout netlist -> PhysOpt -> Netlist + PDEF -> Load into Apollo ->
-> Apollo CTS -> Apollo Route -> RC Extraction -> Primetime
We used a Perl script given to us by Synopsys to convert PhysOpt's PDEF
output into an Avanti SCHEME file. After we loaded the PhysOpt placement
into Apollo, we used an internal LSI tool to do synthesis an ramptime fixes
on the high fanout nets like "Reset" in our designs. PhysOpt doesn't know
how to build a balanced tree for such nets, so we had to fix them ourselves.
It's important to note that in PhysOpt these nets like "reset" must be set
off with set_ideal_net and set_false_path being "true". PhysOpt also can't
do Clock Tree Synthesis yet even though the higher ups in Synopsys give me
great assurances that it will soon. We used Apollo CTS.
The Chip #2 PhysOpt run only took 6 hours. It met our 6.25 nsec spec and it
correlated well with the other timing engines after we did the final Apollo
layout. Due to PhysOpt's good flip-flop clustering, we quickly got a very
low clock skew (~70 psec) in the Apollo CTS run. This was a dream compared
to our old flow (~150 psec) which required 2 or 3 rounds of buffer resizing
and hand tweaks to many of the buffers. The 70 psec skew gave us no hold
violations to fix in the Chip #2 design. That old 150 psec skew gave me
scads of hold violations that I had to chase down and fix!
Everything looked great. I recommended we buy PhysOpt.
Things started to fall apart when we began running Chip #1 through our newly
purchased PhysOpt flow. The first problem we ran into was that it took
PhysOpt 7 days to complete its run. (This is where I learned the difference
between Synopsys customer support and Avanti customer support. We were
early adopters of Avanti's Saturn tool at LSI. Saturn had a lot of crashes
and segmentation faults. Avanti didn't help us that much and I had the
impression that they didn't know what was really wrong with Saturn. It was
very unpleasant for us to do critical resynthesis with Saturn if it had
problems. In contrast, when PhysOpt gave us trouble, Synopsys planted a
full time AE on site with us as well as dedicating AEs to us at their own
site.) Anyway, despite the great customer support, it took us 7 days to do
that Chip #1 PhysOpt run and an additional 7 days for Synopsys to duplicate
this problem at their own site.
I had just recommended PhysOpt! I was afraid of losing my job. I wasn't
the sole eval engineer here at LSI, so my career was temporily safe, but I
was on the hook to make PhysOpt work.
The first thing I noticed from the 7 day PhysOpt run was that Chip #1's area
had gone down 18 percent(!), so I tried setting max_area to a reasonable
value. PhysOpt seemed to ignore this and try to do its best.
My old "Days of Hell" memories came back when we discovered that Chip #1's
PhysOpt placement was not routeable because of the extra buffers inserted
by Apollo to achieve gated clock tree balancing. (Chip #1 had gated clocks;
Chip #2 didn't. Every 8 flops in Chip #1 had a clock gate to conserve
power. There were over 1,000 clock gating cells. Apollo CTS added more
than 1,000 buffers. Congestion went haywire because of the extra nets
with these buffers.)
We then resorted to using the netlist generated by PhysOpt but discarded the
PhysOpt placement. We used the Avanti placer and CTS engine to finally
close the design. Because PhysOpt generated a better physically aware
synthesized netlist than Design Compiler, we were still able to achieve our
target 10 nsec speed using the Avanti placer.
We later noticed that Chip #1 had only 4 metal layers and a low performance
lib with smaller, weaker cells (G12L). Chip #2 had 5 metal layers and
strong cells with G12P. The metal pitch was the same in both libs so Chip
#1's low power lib (G12L) had less available metal tracks to use, too. Also
Chip #1 had only one horizontal layer available (metal 3) because metal 1
was used up by the low power G12L lib. With Chip #2's G12P, we had metal 3
and metal 5 for horizontal routing.
Found The Way Out
-----------------
All these problems made Chip #1 very sensitive to congestion problems. We
were relieved to find this congestion can be alleviated by reading in the
netlist and PDEF from Avanti after CTS into PhysOpt and doing an overnight
incremental PhysOpt run to fix congestion problems. We didn't know about
this incremental PhysOpt run fix to solve that problem at the time so we
taped out Chip #1 not using the PhysOpt placement data. On a post-tape-out
rerun of the flow, the 7 day PhysOpt run dropped to 12 hours. The final
PhysOpt results (compared to the old flow were):
Chip #1 Chip #1
Old DC Flow New PhysOpt Flow
-------------- -------------------
# of Cells 79,000 instances 67,000 instances (15% reduction)
Size 4.2 mm2 3.9 mm2 (7% reduction)
Timing 11.0 nsec (1 nsec off) 9.36 nsec (0.64 slack)
Chip #2 Chip #2
Old DC Flow New PhysOpt Flow
-------------- -------------------
# of Cells 80,000 instances 80,000 instances
Size 6.0 mm2 6.0 mm2
Timing 7.0 nsec (0.75 nsec off) 6.25 nsec (on spec)
I've also been told by Synopsys that there was a bug in PhysOpt v 1.21 that
may have caused my 7 day runtime problem. They say it's been fixed in the
new PhysOpt 2.0 coming out next week.
In the end, we believe that clock tree synthesis capability is a must in
PhysOpt to avoid the late surprises as we experienced. I've had high
assurances from Synopsys that its coming. We have other chips coming up and
we don't want CTS biting us like it did. Now, though, because we have this
Avanti CTS / PhysOpt incremental workaround, we can get these chips done
either way.
- Vijay Angarai
LSI Logic, DSP division Dallas, TX
( ESNUG 362 Item 2 ) --------------------------------------------- [11/30/00]
From: Dennis Milton <Dennis_Minton@stratus.com>
Subject: Customer Musings On Tcl, DC, Presto, PrimeTime, ACS, & PhysOpt
John,
I didn't get to add my voice to your Boston SNUG review so I thought I'd
share them now concerning Synopsys synthesis. I loved Gregg Lahti's talk
on Tcl. At least somebody addressed the Synopsys Tcl short falls. Maybe
Synopsys will include Tk toolkit in the future. Until then, I don't see
a complete tcl solution.
Presto makes me nervous. Changing the way MUXes and arrays are translated
to gtech sounds like two different circuits to me. Infer enumerated types
should be defaulted to off to be compatible with earlier releases.
I have started using the -path full_clock switch for report timing. I was
pleased to see it common to Primetime tcl and dc-shell.
ACS is just another way to become tool dependant. Fundamentally I agree
with it, but I don't see any reason to move from Primetime budgeting to
Design Compiler budgeting. Primetime is much faster, and more accurate.
The budgeting step has generated some unrealistic constraints for feedbacks
to flip-flops, feedthroughs, and progated constants. I still need to
"tweak" budgeted constraints to minimize negative slack.
No, I probably will not change from dc-shell during this project phase (till
June 2001). What is working is generally left alone... unless of course
if Synopsys phases out dc-shell.
Concerning PhysOpt, the biggest problem I have with this flow, is the list
of qualified vendor libraries. Most vendors I deal with do not have
qualified libraries for their scan and DFT macros. As far as I know, most
designs require ATPG or BIST.
- Dennis Milton
Stratus Computer Marlboro, MA
( ESNUG 362 Item 3 ) --------------------------------------------- [11/30/00]
From: Paul Gerlach <paulge@mdhost.cse.tek.com>
Subject: Scriptlet To Make dc_shell-tcl Shut Up About Non-Error "Errors"
John,
I've been beating my head against Tcl as we're transitioning to use it with
dc_shell. I thought I would share a little snippet I developed through
much trial and error, and ask the world if there is a better way.
The problem I'm trying to solve is that we would like some general purpose
scripts for our project that will apply constraints to any block given to
it. So we want a conditional application of output_delay on a reset pin,
based on whether the reset pin exists or not. You could just:
set_output_delay 5 -clock clk [get_ports {Reset}]
but then Synopsys says:
Warning: Can't find port 'Reset' in design 'test'. (UID-95)
Error: Nothing matched for collection (SEL-005)
if that port doesn't exist. But maybe that's okay except that errors are
bad when grepping for real errors. Through much effort we came up with:
proc exists { thingy } {
redirect /dev/null {set a [eval $thingy]}
if {$a == {}} {
return 0;
} else {
return 1;
}
}
if {[exists {get_ports Reset}]} {
set_output_delay 5 -clock clk [get_ports {Reset}]
}
Synopsys does it if the pin exists, it reports nothing if it doesn't. Note
the selection of brackets and braces, they are all important! This seems to
work for get_ports and get_designs, I don't know what else. This seems
really useful to me. Has anyone any better methods?
- Paul Gerlach
Tektronix, Inc. Beaverton, OR
( ESNUG 362 Item 4 ) --------------------------------------------- [11/30/00]
From: Umer Yousafzai <uyousafzai@hotmail.com>
Subject: What Do Users Think About Verisity's Specman? Should I Work There?
Hi John -
I read one of your articles posted on the EDA consortium about VERA. I am
considering a job with Verisity. I would greatly appreciate it if you would
share your views about Specman, the trends in verification, Verisity as a
company, and any challenges that they/industry is facing.
Thanks for any help that your readers may be able to provide.
- Umer Yousafzai
( ESNUG 362 Item 5 ) --------------------------------------------- [11/30/00]
Subject: ( ESNUG 359 #8 ) Other UNIX Tips & Tricks For Those Long EDA Runs
> I got hit by a little gotcha recently that I thought I should share.
>
> I've got into the habbit of using the "dc_shell | tee logfile" syntax for
> interactive debugging so I can have a logfile for the session. One nice
> thing about interactive sessions, is that a control-C will allow you to
> checkpoint, or stop something that is compiling into oblivion & see what's
> wrong. This may be very obvious to some, but I found out the hard way
> that when using the " | tee" syntax, the control-C is passed to the "tee"
> instead of the dc_shell session. This basically breaks the pipe and stops
> the job, with no way that I could find to recover. Any UNIX gurus out
> there know how to recover if this happens? To prevent this, make sure
> to use the -i switch on tee, which tells it to ignore interrupts:
>
> "dc_shell | tee -i logfile"
>
> This allows the use of control-C for dc_shell.
>
> - Bob Wiegand
> NxtWave Communications Langhorne, PA
From: Sangeetha Narayan <sangeetha@ctl.creative.com>
To: Robert Wiegand <rwiegand@nxtwavecomm.com>
Hi Bob!
I found something that might be useful! You can send a ctrl-c to dc_shell
(or any process for that matter) by using the command kill -INT
This sends an interrupt or a Ctrl-C equivalent to the dc_shell running in
the background. Send it once if you are using it to get a checkpoint.db,
twice for aborting optimization, and three times to kill the process.
- Sangeetha Narayan
Creative Technology Ltd. Singapore
---- ---- ---- ---- ---- ---- ----
From: Robert Wiegand <rwiegand@nxtwavecomm.com>
To: Sangeetha Narayan <sangeetha@ctl.creative.com>
Hi Sangeetha,
I'm glad to hear that post helped you. I had to 'kill -9' as well, losing
30 hours of run time, bummer! I haven't found any way to recover yet, the
safest bet may be to alias tee to "tee -i". Before discovering the "| tee",
I used to do:
dc_shell -f script > logfile &
tail -f logfile
This would give me a running log as if it were an active session. If
something died, I would control C the tail, fg the background process, and
then be able to blindly type into the dc session. I could open another
window, and tail -f the logfile once again. This would allow me to type in
one window and see the output in another window. The one advantage to this
is that backgrounding the process gives in an automatic "nohup", so if
you're remote logging to a process server, and your user session dies, the
process keeps running on the process server. I've tried typing nohup
infront of the "| tee" syntax, and it runs, but I havn't tried to kill the
user session to see if the process still runs on the process server.
- Bob Wiegand
NxtWave Communications Langhorne, PA
---- ---- ---- ---- ---- ---- ----
From: Christian Michon <christian.michon@st.com>
Hi John,
I read the small tip from Robert Wiegand and found it very useful. Let me
share one, too. For those unfortunate few who would have spent hours of run
time and who would discover with horror they forgot the -i to the tee, you
can just do a "kill -INT <>" where PID is the number of the process ID
of your dc_shell_exec. This works nicely with the UNIX utility "top".
A "kill -INT ..." in unix is equivalent to a "CTRL-C".
Do it once to save a checkpoint, do it twice to abort the current
optimization and go on with your script, do it a third time and it'll
die. I hope this is useful for those who sometimes forget the -i, or even
lost the terminal where they launched the command.
- Christian Michon
STMicro
---- ---- ---- ---- ---- ---- ----
From: Patrick Harkin <paharkin@micron.com>
John,
A trick I like to use for that is to create a small shell script (I call it
xdc) which opens an xterm and runs dc_shell. Here's the xdc cshell script.
#
mv log.$1.log olog.$1.log
xterm -geometry 80x33+0+30 -l -lf log.$1.log -fn 7x13bold -ls \
-sb -n synop -fg moccasin -bg black -cr \#0ef -bd \#0ef \
-ms \#0ef -sl 500 -bw 2 -e
dc_shell -f $1
The session is completely logged as with the tee and you can Control-C the
run within the new xterm. So if you run "xdc module.scr", you will have
log.module.scr.log when you're done and the previous log file is moved to
olog.module.scr.log.
- Patrick Harkin
Micron Technology Inc.
( ESNUG 362 Item 6 ) --------------------------------------------- [11/30/00]
Subject: ( ESNUG 359 #9 ) How We Use ClearCase To Manage ASIC Design Data
> I was searching through ESNUG archives and found several people
> recommending the ClearCase configuration management tool for hardware
> design [ESNUG 345 & ESNUG 281]. I would appreciate it if anyone who is
> using ClearCase could elaborate on the usage model for ASIC design.
> Specifically, is the entire ASIC database (including Synopsys .db files
> and other miscellaneous files and directories created by various ASIC
> tools) under ClearCase management or just the HDL source? Managing the
> entire database seems to be overkill, but if a file is not managed it is
> not easily visible to other users working in other "views".
>
> - Shuhui Lin
> Alcatel USA Raleigh, NC
From: Anders Nordstrom <andersn@nortelnetworks.com>
Hi John,
We have used ClearCase on several ASICs for about a year. We have set up a
directory structure "/vobs/asicname" for each ClearCase domain. Under
"~asicname" we have the same directory structure for all chips:
/Documentation
/RTL
/Simulation enviroment
/Testcases
/Netlist
/Testplan
/Lab verification plan
We do not put the entire database under ClearCase. Log files and VCD files
which are only used for debugging and which change daily are kept in users
own views. All the RTL, documentation, testplans, verifcation enviroment,
testcases and synthesis scripts are kept under ClearCase management.
Basically everything you need to build the gatelevel netlist. We do not
keep .db files for lower level modules in ClearCase, only the final full
chip gatelevel netlist. We had one person doing all the synthesis so the
issue of the files not being visible was not an issue for us. In the future
we will have more people doing syntesis and then we will probably put
sub-system db files in ClearCase.
- Anders Nordstrom
Nortel Networks Ottawa, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: Jim Avant <javant@mindspring.com>
John,
I was acting manager of a group where we were starting to use ClearCase. I
thought it was the best solution at the time. However, it was a real pain
trying to enlist the engineers to actually use it. Most dragged their feet
until the project got cancelled (got other reasons). Getting engineers to
use a new tool, especially a REVISION CONTROL tool, is like trying to herd
cats (sorry for the overused metaphor, but dammit it fits!). Most ASIC
engineers (and I'm guilty of this too) are "fly by the seat of the pants"
guys that don't like non-command-line, non-ASCII tools. And most are not
easily convinced that revision control is a NECESSARY evil (they pick up on
the evil part right away).
Also, ASIC design flows are different from S/W design flows in some tricky
ways. I found it difficult to preserve intermediate files (like .db files)
under revision control and still be able to build a chip without having to
do manual checkout of the intermediate files. Sure it can be done, but the
situation I was trying to avoid in the first place was having a dedicated
person writing scripts for revision control. Of course ClearCase is also
MUCH more expensive than most other solutions.
At my new job (www.socsolutions.com; check us out), I have another decision
to face. Do I try to leverage the software team's choice of PVCS and if so
how? Or do I maintain an independant tool and database for ASIC designs.
I'm still gathering information, but I will make a choice soon. ClearCase
is not even an option because we're still in start-up mode. But if I had
an open budget, I'm not sure I would pick it again. Don't get me wrong. I
think it's a great tool. But a shiny new tool that sits in the shed and
never gets used just doesn't impress anyone.
Good luck.
- Jim Avant
SoC Solutions
---- ---- ---- ---- ---- ---- ----
From: "Martin d'Anjou" <mdanjou@nortelnetworks.com>
John,
I do not use ClearCase, but your questions apply equaly well to any
revision control software. On my current project, we let the revision
control software manage only the files that can't be recreated by an
automatic process, i.e. anything that is an output of an EDA tool is not
managed: most times those files are too big. However, the scripts and the
configuration files are under revision control. This way, any designer or
verifier in the team can recreate any part of the design/verification they
wish. This is useful when one of us is on vacation and our boss wants an
up to date regresion for example. Anyone can launch the regression or
the systhesis and let it go.
If an EDA tool creates directories or files on its own, we typically don't
put those under revision control. I am thinking of putting regression
results under revision control (typically the "pass-fail" output text file
from simulation).
For the "final" or "official" synthesis and layout files, we store them to
a common release area sub-directory named after a unique release id number.
Currently, we don't put those under revision control, but the release area
is backed up on a regular basis. Then designers don't need to occupy disk
space in their own home dirs, and the results are available to all to
look at.
The revision control software we use is SOS from http://www.cliosoft.com/
and so far we are happy with it. I find it fairly easy to configure.
- Martin d'Anjou
Nortel Networks
( ESNUG 362 Item 7 ) --------------------------------------------- [11/30/00]
Subject: ( ESNUG 359 #7 ) My Design's Small; I Need Cheap-But-Good ATPG
> Do any of your many well educated and knowledgeable readers have some
> cheaper ATPG tools to recommend? I won't be generating scan for a million
> gate ASIC so a small tool would work nicely. We can't afford the Mentor,
> Cadence, or Synopsys products, and our design is small. Right now I'm
> working on a very small, specialized design that's only 7 kgates. I don't
> need to buy a $300K suite of tools for this. Ideas?
>
> - Morgan Monks
> Gain Technology Phoenix, AZ
From: Ira Hart <ihart@galtdesign.com>
John,
For a larger design, scan is a must. You may find that for a small 7K gate
design, it would be more worthwhile to write test vectors by hand.
You probably will have a suite of verification tests you can use for a
start. Your ASIC vendor will give you fault grade results to let you know
where the holes are. You can fill in the blanks to get reasonable coverage.
If you are doing a 7K gate design, you are probably doing a cost sensitive
high volume product as well. You will find that adding scan to a design
will increase your sequential gate count by around 40%. This will cost you
$$$ if you get bumped to a larger die size due to the addition of scan.
- Ira Hart
Galt Design Inc. Newton, MA
---- ---- ---- ---- ---- ---- ----
From: [ I Wear My Sunglasses At Night ]
Hi John,
Keep me anonymous please. Morgan should check out AMI. They have their
own tool that can insert scan and do ATPG. His size of design is also in
their sweet spot, if he doesn't need blazingly fast technology.
If he has a design with reasonable volume, he should be able to get the
scan insertion and ATPG thrown in.
I used to work there and I inserted scan on a lot of designs, and got
fault coverage >90% almost all the time, and >95% with a little work on
designs where this was required.
I don't think they sell the tools, or contract out the service, but it
might be worth asking the question.
- [ I Wear My Sunglasses At Night ]
---- ---- ---- ---- ---- ---- ----
From: Veli-Matti Karppinen <veli-matti.karppinen@pigroup.fi>
Hi John,
A possible tool could be the old Attest/Zycad/TSSI/ and now Fluence TDX-ATG.
At least it used to be cheaper than ones Morgan mentioned and in my
experience does the work OK.
- Veli-Matti Karppinen
PI-Group Somewhere, Finland
---- ---- ---- ---- ---- ---- ----
From: Ken Butler <kenb@ti.com>
John,
I noticed Morgan Monks' post about cheap-but-good ATPG. I don't have a web
site to tell him to look, but there are a number of universities over the
years that have developed ATPG tools that they will give out freely.
Probably the one that shows up the most frequently in research papers is
HITEC from the University of Illinois.
HITEC formed the basis for what became the Sunrise tools, portions of which
are as we speak being ported into Synopsys TetraMAX. HITEC's claim to fame
was sequential ATPG, which may or may not be what he wants.
I believe that Dong Ha at Virginia Tech (?) had another tool called, I
believe, ATLANTA. That might be worth a look.
The problem with most tools like these might possibly be an inability to
read whatever netlist format he's using and/or not being able to handle
complex design structures like tristate buses or other non-FF and non-
combinational gate type stuff. Nothing ventured, nothing gained I guess.
- Ken Butler
Texas Instruments Dallas, TX
---- ---- ---- ---- ---- ---- ----
From: Mike Kondrat <mikek@fluence.com>
Hi John,
In your ESNUG 359, Morgan Monks asked about low cost ATPG tools. I know I
am a marketing weenie but I wanted to let your reader know that our ATPG
tools are low cost compared to the big boys. His application would be a
good fit for our TDX product.
- Mike Kondrat
Fluence Technology Beaverton, OR
( ESNUG 362 Item 8 ) --------------------------------------------- [11/30/00]
From: "Janick Bergeron" <janick@qualis.com>
Subject: Janick Pisses On Superlog; Supports Vera And Verity's "E" Instead
> So what may be its key selling point is that the Superlog revolution isn't
> revolutionary at all. Unlike Vera or C/C++ HW design, using Superlog
> doesn't mean you have to start over by throwing away all your old legacy
> Verilog code. "The beauty of Superlog as I see it is that it is an
> evolutionary path from Verilog," concluded Anders. "I can start out with
> 100 percent Verilog and then add as much Superlog as I want. Superlog has
> some very useful constructs such as structures, queues, re-entrant tasks,
> protocol checkers and pointers which are lacking in Verilog."
>
> - from John Cooley's "The Superlog evolution" column in EE Times
[ Editor's Note: Janick Bergeron, a man who I greatly respect, moderates
the "Verification Guild" newsletter. (OK, so we disagree!) - John ]
From: Janick Bergeron <janick@qualis.com>
Hi, John,
Taken from co-design's white paper "Evolving the Next Design Language", here
are the "new features" that Superlog adds to Verilog:
Software aspects:
- User defined types
- Enumeration
- Structures
- Pointers
- Recursion
- Stack, heap
- Strings
System & Verification aspects:
- Dynamic processes
- Protocol checking
- Behaviors to I/O ports
- Extended FSMs
- Hierarchical accesses
- Dynamic arrays and queue
Woohoo! Verilog has been evolved to the software engineering standards that
prevailed in the eighties!!!! Break out the champage! That may represent
progress on the design side, but for verification, it does not even come
close to Vera or Specman. I'll stick with real progress, thank you.
Where's the constrainable random generation? And I do not mean trivial
random generation as in Verilog's $random task, nor TestBuilder's trivial
constraint mechanism. I mean a REAL constraint solver, with sets of boolean
equations that describe relationships between randomly generated fields and
values. And adding constrains should ideally be done WITHOUT modifying code
that is known to work.
Where's the functional coverage? And I do not mean simple dynamic processes
that append to files. I mean a REAL statistics/distribution collection
engine with incremental data collection, cross-analysis, goal definition
with user-friendly reporting. In the SystemSim datasheet, there is no
mention of code coverage capability. I hope this is because, in 2000,
this now goes without saying...
Where's the object-orientation? And I do not mean simply hierarchically
accessing tasks and functions in a module instance. I mean REAL
inheritance, variant structures, virtual members, and polymorphism. There
was more to Java to borrow than the "byte" pre-defined type.
I'm curious about the "protocol checking" bit. Does it mean there is a
temporal language extension?? That would be cool. If it is more procedural
checking mechanisms (like FSMs), excuse me while I yawn.
And what is the big deal with C and C++ anyway? C was designed 30 years ago.
C++ 20 years ago. They may be the most widely known languages today, but
they are also the most widely abused, spagetthi coded, shoot-yourself-in-
the-foot, memory-leaking, obsfucated languages ever used. I do not find
the "I already know the language" argument convincing. What you already
know is the *syntax*. You do not know the intricacies or process for using
it within the context of the SystemC/Cynlib/whatever class library. THAT
you have to learn and THAT is what takes time. Learning the syntax of a new
language (such as Vera or e) takes only a few hours. You won't require
anymore time to learn how to use it than how to use that other C++ class
library. And what's a few hours in a 1-year project?? Especially, if you
end up with a more efficient environment in the long run?
Evolution is an acceptable business strategy. It minimizes discomfort,
allows incremental adoption of new technology and reduces training cost
and initial inefficiencies. Superlog fullfils that need and has a viable
future. However, you should not plan on an evolutionary plan in the long
term: evolution has been known to reach dead-ends. We are in the
Jurassic era of electronic design. I want to bet on the flyers who will
eventually transform into birds, not the current top-of-the-food-chain
Tyranosaur. Actually, I would rather be smart enough to be able to
identify the pond scum that will become homo sapien - and make a killing
in the ensuing IPO.
Revolutions are NECESSARY. Show me the companies that, today, are using
an evolution of the schematic capture methodology prevalent in the late 80's
and early 90's. Those who survive today embraced the logic synthesis
revolution.
There is one VERY BIG problem with revolutions: they are disruptive.
What you knew no longer applies. You have to learn new ways of thinking.
You have to change to way you do things. You have to accept initial
inefficiencies for the promises of future gains. That's not easy to
overcome. Politicians play on and use these feelings all the time with
their talk of "the good old days" and "traditional values" and "national
identity". Change, especially revolutionay change is painful. Introducing
logic synthesis into the design process was a traumatic experience for the
older, experienced schematic-based designers. Fortunately, there are
companies who can help with the transition through training and support
services.
Time will tell which solution will survive: technical merit alone is not
sufficient to guarantee success. I, for one, hope for the revolutionary
one.
- Janick Bergeron on loan at
Qualis Design Corporation Grenoble, France
( ESNUG 362 Item 9 ) --------------------------------------------- [11/30/00]
Subject: ( ESNUG 361 #1 ) PKS Tape-out, Layout Staffs, Project Schedules
> I know your readers are design engineers, so I thought I'd send you my
> detailed experiences using PKS on a tape-out.
>
> I'm a chip designer but my sidebar task here at Geocast is to also be the
> methodology guy, too. I set up our PKS flow here and we recently did two
> 200 Kgate tape-outs to test the PKS flow with our in-house custom standard
> cell library. We used MOSIS TSMC 0.18 and TSMC's CyberShuttle service.
>
> We used PKS v3.0.19. The design was 200K gates of synthesized logic...
>
> - Thad McCracken
> Geocast Networks Systems, Inc. Beaverton, OR
From: [ Jake Buurma, Senior VP of Engineering at Cadence ]
To: John Cooley <jcooley@world.std.com>
John,
Wow, what a great PKS article! It's HOT!
I don't care what all the other EDA companies say about you, I think you're
alright.
Thanks
- Jake Buurma, Senior VP of Engineering
Cadence San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: John Ireland <John.Ireland@philips.com>
To: Thad McCracken <thad@geocast.com>
Hi Thad,
My name is John Ireland. I work for Philips Semiconductors in Southampton,
UK. I'm e-mailing in response to your mail to John Cooley, which was
included in the ESNUG post 361.
I read with much interest about your experiences involving the PKS Ambit
flow. We are about to use this flow, targeted at a VERY similar technology
so your experiences will be of much use to us. Our design is of a similar
size to yours, and with similar clock speed requirements. I have a couple
of questions and would really appreciate it if you could find the time to
answer them.
1.) Did your design include any SRAM instances / Analogue blocks (Apart
from PLL's)?
2.) This is the most important one. Could you put a rough estimate on
the timescales. Both from RTL to tapeout and on the smaller parts
of the design flow. We are working to reduce the time in layout, and
anything that helps this would be useful.
3.) What is the impact of a late design change (assuming you had one).
We nearly always have a small change as tapeout draws near and the
impact that has can vary wildly.
4.) Just so I can scale the answer to (2). How many people were dedicated
to the layout process. We will probably have 10 people working on it.
Any other useful information/pitfalls will be well received.
- John Ireland
Philips Semiconductors - CD/DVD Systems Southampton, UK
---- ---- ---- ---- ---- ---- ----
From: Thad McCracken <thad@geocast.com>
To: John Ireland <John.Ireland@philips.com>
Hi John, (& John),
I've attached my response to John Ireland's questions.
> 1.) Did your design include any SRAM instances / Analogue blocks (Apart
> from PLL's)?
The design had a DLL, clock multiplier, numerous register file instances
(not SRAM), and a CAM.
> 2.) This is the most important one. Could you put a rough estimate on
> the timescales. Both from RTL to tapeout and on the smaller parts
> of the design flow. We are working to reduce the time in layout,
> and anything that helps this would be useful.
The time it took to get from RTL complete to taped-out design (i.e. the
LVS/DRC clean GDS has been shipped) was about 6 weeks. The two big ticket
items we spent time doing were:
1.) Floorplanning the chip. The general order in which I did this was
as follows:
- produce pad-ring .def file, which places all the pads and
defines the size of the chip and serves as a starting point
for everything else.
- add standard cell rows to core of chip
- place hard macros (rams, cam, DLL, clock multiplier), cut
standard cell rows around these (i.e. make halos).
- power grid the whole chip. The way in which this is done
obviously varies. We build a "less dense" grid using M2 to
drive the M1 straps that are built into the standard cell
rows, and overlay that with a dense M5/M6 grid that redrives
the M2 grid as necessary, dependent on design requirements.
We find that this gets us decent placement densities without
overly impacting routing congestion. Other aspects of power
gridding are placing rings around the entire core and
the macros, and tying power/ground pins on the IO cells to
the core ring. Finally, we put endcap cells on each standard
cell row and tie them to the core/macro rings as well.
2.) Iterate this floorplan through PKS. If you have few to no
macros in your design then you may need only one or two iterations
to get an acceptable floorplan. I found that I needed to do
several iterations to get macro placements that were optimal
for general logic placment and for clock tree insertion. In general
it's best to put macros near the edges of the P&R block so that
the area in which standard cells are placed is as close to rectangular
as possible. As far as iteration time, a rough breakdown of
this was as follows:
- synthesize from scratch given new floorplan (7 hours)
- insert clock tree, hook up scan chain, add (1 hour)
filler cells
- route chip (4 hours)
- Extract RC (the fast way), timing analysis (1 hour)
- Extract RC (Hyperextract), timing analysis (5 hours)
So the total for an iteration (RTL synthesized, placed and routed
gates) was 13 to 17 hours, depending on whether you wanted to
Hyperextract that iteration or not. I typically didn't unless it
was looking good and wanted to verify that against more accurate
data.
Problems with a given floorplan usually showed up as timing
problems that could be traced back to routing congestion caused
by poor macro placements. Adjustment of macro placements obviously
requires at least some of the floorplanning steps enumerated above
to be redone. This analyze and adjust period was the major
time consumer in getting to a stable, usable floorplan. I eventually
got to a mostly automated collection of scripts to speed this
process, but have found it difficult to automate in a generic
fashion.
I found that #1 above was the biggest time consumer for this chip, for
various reasons. I probably spent 2-3 weeks of my time on #1 - most of it
constructing the power grid for the chip. Many could probably do this
faster, as I was learning a lot about SE's capability in this area, and also
learning how to represent power pins on I/O cells, etc. such that the power
router would automatically recognize them. The end result of this effort
was a set of scripts that constructed the pad ring, floorplan, and power
grid in about an hour.
Once #1 was completed, I spent another week or so iterating on it as
described in #2 until I was satisfied with the macro placements.
The remaining 2-3 weeks was spent doing a variety of things:
- designing, implementing, and validating any new RTL (most of the
RTL was taken from a previous chip)
- wrapping up specifics of our scan methodology and integrating it
into our flow
- Fault grading the chip
- Adjusting for a late design change (see answer to #3 below)
- LVS/DRC - we did several trial runs through this part of the
flow along the way to work it out.
> 3.) What is the impact of a late design change (assuming you had one).
> We nearly always have a small change as tapeout draws near and the
> impact that has can vary wildly.
We had to deal with several late design changes along the way:
- we were finishing up our RAMs in parallel with the rest of the chip,
and in one case had a RAM macro's size come out slightly bigger than
we estimated - just enough bigger to require the halo and power ring
around the RAM to need a change. I had anticipated this when
writing the scripts to do #1 discussed above, so this change amounted
to the ~1hour it took for those scripts to run and make a new floorplan,
followed by the iteration time to resynthesize, place, route,
extract, etc. So the entire impact of this change was about 1 day.
In this case the size change did not significantly impact standard
cell row utilization so no adjustments to the die size were necessary.
- Our clock multiplier was the last custom block to get finished, and
turned out to be significantly bigger than expected, and left the core
over-utilized. To adjust for this I had to increase the size of
the die by one pad width on each side and adjust the chip floorplan
accordingly. I had to tweak my floorplanning scripts a little to
deal with this, then re-synthesize, place, route, etc. The impact
of this change was on the order of 1.5 days.
In general if your design is meeting timing, the impact of a late design
change (assuming it doesn't introduce a new timing path or cause the design
to outgrow it's allotted area) will be the time it takes to run the design
through PKS, CTGEN, and SE. If the change does impact die size then the
impact will largely depend on how tolerable that impact is, and how easily
the floorplan can be tweaked to accommodate the change.
> 4.) Just so I can scale the answer to (2). How many people were dedicated
> to the layout process. We will probably have 10 people working on it.
I've listed below the number of people we had working on this chip, and what
their responsibilities were.
2 layout guys, on layout of custom macros and I/Os
2 circuit designers (circuit design of custom macros and I/O cells)
1 physical designer doing DRC/LVS, macros abstract generation, etc.
1 designer on logic design of DLL and clock multiplier
1 designer on formal verification of custom macros and ATPG
1 designer on RTL, full-chip floorplan, synthesis, P&R.
Some of the custom work (on the I/O cells and some of the arrays) started
prior to the six-week time frame in which we taped out this chip.
Had we finished all the "building blocks" (i.e. arrays, DLL, etc.) prior to
doing the logic design and implementation then the chip could have been
taped out in the same 6-week time frame with 1-2 designers and the physical
designer mentioned above. I mention this only because I'm not sure if you
guys are doing your own custom design, taking those blocks from a previous
chip, or getting them from a vendor.
On the flip side, most the RTL was taken from a previous chip, so there was
little new design and validation to do.
- Thad McCracken
Geocast Networks Systems, Inc. Beaverton, OR
( ESNUG 362 Networking Section ) --------------------------------- [11/30/00]
San Diego, CA -- Pre-IPO startup Astute Networks seeks ASIC design, verif.,
and layout engineers. Death to headhunters! "mike@astutenetworks.com"
Phoenix, AZ. -- Pre-IPO start-up Gain Technology seeks ASIC design engineer
for design and verification. No Headhunters, please. "mmonks@gain.com"
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
