> Stalin took a backwards Russia and in 30 years made it a nuclear world
> Soviet super power that bested the German Wehrmacht along the way. Gerry
> took a nothing ArcSys and turned it into a 26 consecutive profitable
> quarters Avanti that still bests Cadence in most P&R benchmarks.
From: Bill Knapp <billk@Cadence.com>
John,
It's interesting how you can make light of an analogy between two
criminals, one against humanity, one against Intellectual property.
If the Soviet Union is such a great place where one of your idols used
to live, why don't you move there? Synopsys will always be able to
find another pimp.
John, you are a disgrace.
- Bill Knapp
Cadence Sales Guy Red Bank, NJ
( ESNUG 352 Subjects ) ------------------------------------------- [5/17/00]
Item 1 : An Ultima ClockWise Tape-Out Story Plus A User Skew/Power Warning
Item 2 : ( ESNUG 350 #9 ) COT vs. ASIC / Hier vs. Flat Statistical Problem
Item 3 : Can I Fix Transition Violations Without Lots Of Downsized Buffers?
Item 4 : ( ESNUG 351 #3 ) De-Glitching Coverage Tools Are A General Issue
Item 5 : Muddling From A 3-Pass To A 2-Pass Hierarchical Layout Methodology
Item 6 : ( ESNUG 351 #7 ) Curry's Holy War On Oren's Verilog "<= #1" Idea
Item 7 : ( ESNUG 351 #8 ) Formality, Chrysalis, Verisity, & Model Checkers
Item 8 : ( ESNUG 350 #10 ) The URL For The Behavioral Compiler Tutorial
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 352 Item 1 ) --------------------------------------------- [5/17/00]
Subject: An Ultima ClockWise Tape-Out Story Plus A User Skew/Power Warning
> And yesterday, after some snooping, I discovered that LSI Logic, Matrox,
> HP, Texas Instruments, and Philips were all doing evals of ClockWise.
> I wonder if there are any ClockWise tape-outs yet.
From: Jon Stahl <jstahl@avici.com>
Hi John,
I recently taped out a design on which I inserted clock trees using the
Ultima ClockWise tool and really liked it. In the past I have used
intentional skew in special situations to help improve timing, but it was
difficult time consuming hand work.
I have always thought that having an automated way of using skew to improve
timing would be great, but it seemed like a difficult problem. In the past
I have seen a few academic papers on the subject, but until recently I have
never heard of a commercial tool.
Ultima has pulled off a very nice implementation of a "useful" skew tool.
The tool has several modes, zero-skew, useful2, and useful3 (and a promised
useful4).
In a few words, useful2 mode kind of preserves the look and feel of a
zero-skew methodology. This mode separates registers into two groups:
1) BSG (Bounded Skew Group), which are either
- IO flops, that receive data from primary inputs/drive
primary outputs
- flops on another clock tree
2) Internal - everything else
Once these two groups are identified, the tool creates a "schedule" for the
insertion delays of all the clock leaf points in the design. Flops in the
BSG are scheduled with equal insertion delays, i.e. zero skew with respect
to each other. All other flops are fair game for it's useful skew algorithm.
The current useful skew scheduling algorithm is fairly straightforward.
A "permissible range" is derived, which is a window where the clock can
transition on a flop and have it's setup and hold times met w/respect to
"adjacent" flops (flops connected to the flop through combinational logic).
The tool attempts to schedule the transition early enough to meet the setup
time without violating hold, hold being the dominant constraint. You can
also specify "safety margins", i.e. extra slack for both setup and/or hold
that the tool will attempt to meet. (Personal opinion: I believe it would
be better to place the transition right in the center of the range to
provide as much margin on either side as possible...)
I used useful2 mode on my design because of one particular property. As far
as the board level IO timing requirements, the design looked as if it were
zero-skew. I could schedule the PLL reference to match the BSG insertion
delay, and my external interfaces were clean. Although doing this, of
course, ruled out any useful skew optimization on the IO flops.
Useful3 mode allows ClockWise to schedule the IO flops in order to optimize
the internal setup and hold constraints, but does not take I/O constraints
into account. This is something that would have just caused havoc on my
design. Ultima has talked about developing a useful4 mode that would allow
I/O constraints to be factored into the schedule. This is something I am
eagerly anticipating as I/O timing is an area I have had to struggle with
in the past.
Now, to give you an idea of the design:
850K gates
49 RAM instances
13mm die in 0.25um 4layer technology (LSI Logic LCBG11P)
9 clock domains
~39K flops on main clock tree @ 100MHz
Post-placement/IPO worst case timing slack was -1.2ns.
Normally the kind of results that would send you into a long re-synthesis,
placement, and IPO loop. However, on this design ClockWise was able to help
us get very close to placed timing closure *just* by inserting the clock
tree.
Here is a partial summary from the tool run ...
IO/BSG skews (between 454 leaves)
Max skew bound : 0.300 ns
Skew (min-min) : 0.226 ns
Skew (max-max) : 0.226 ns
without intra-BSG with intra-BSG
Safety margins ---hold-- --setup-- ---hold-- --setup--
Zero skew : -0.013 ns -1.664 ns -0.013 ns -1.664 ns
Scheduled : -0.601 ns 0.821 ns -0.601 ns 0.821 ns
Realized (min) : -0.992 ns 0.623 ns -0.992 ns 0.623 ns
Realized (max) : -0.992 ns 0.623 ns -0.992 ns 0.623 ns
... and it requires some explanation.
I constrained the tool for a 300 ps max skew in the BSG group (of 454 I/O
flops). It claimed to have achieved 226 ps (more on this later).
The safety margins section is split up into two main columns of numbers.
The "without intra-BSG" numbers show the timing for all paths excluding arcs
between flops in the BSG. Since ClockWise can't use skew to improve timing
in the "intra-BSG" paths, they try to give you a breakout of the timing
that can't be improved and that which can. On this design my most critical
paths were not among the "intra-BSG" set, and so the two sets are the same.
The numbers show the big advantage that using a local skew methodology
can provide. With a non-existent tool that could have provided a perfect
zero-skew tree this design would have failed timing by -1.664 ns (according
to ClockWise). Using skew, the tool scheduled for 0.821ns of positive slack
and claims to have built a tree achieving 0.623 ns.
A few caveats and notes are needed here:
1) I was lucky enough on this design that my worst slacks happened to
fall in pipeline stages where moving the clock around could improve
them. This is of course not always the case.
2) One of the problems I ran into was that the timing numbers from
ClockWise didn't completely correlate with the numbers I got using my
vendors global router, delay calculator, and PrimeTime. There were a
few reasons, including a bug in the version (1.0.12) that I was using
that prevented ClockWise from legalizing the cells correctly. (I had
to legalize using other tools). I'm told that has been fixed.
Anyway, that's why I said that the worst case slack for the design was
-1.2ns, even though the ClockWise report shows -1.6 ns. The good news
was that it was the same path. Taking a look at 100 paths from a
correlation viewpoint (what was scheduled vs. what my vendor tools plus
PrimeTime said), I noticed ~200 ps average difference, with outliers in
the 500 ps range. Considering the bug and difference in tools used to
reach the answers I would consider this pretty good.
3) The hold numbers appear as if ClockWise failed to meet the constraint
badly, but that isn't that case. This design contained some
"interesting" synchronous RAMs with a write-through feature that had
a greater than 3 ns write-to-read clock constraint. ClockWise
appropriately scheduled the write clock earlier than the read clock,
but couldn't (tool issue) schedule the write clock early enough to
completely meet the constraint Thus the -0.992ns hold violation. On
the whole ClockWise did a good job of scheduling so as to not violate
hold, and at the expense of some setup violations it could have fixed.
In the case of this design, it would have been much easier to add a few
delay cells to fix hold problems rather than to fix the uncorrected
setups. But there is currently no way to drive the tool to do that.
4) An annoying but not difficult problem that I had to work around was
the fact that ClockWise puts flops on different trees with *any* arc
between them into the BSG. This is usually but not always what you
would want. For instance, I attempted to insert two trees in one run,
a JTAG zero-skew tree, and the main clock tree useful2. ClockWise put
any flops with arcs between the JTAG and main tree into the BSG. Not
good, since this eliminates hundreds of flops that could potentially
benefit from useful skew just because of test mode timing arcs. There
is currently no way to constrain the tool to avoid this, and so I had
to do two runs one for each tree.
There were some ancillary benefits from using ClockWise that should be
mentioned:
1) It fuzzes out your clock reducing peak power!
2) It builds a real buffer tree (as opposed to trunk based methodologies),
clock timing is less dependent on wire (not unique to ClockWise...)
3) You can edit the schedule for special purpose stuff, e.g. create
early taps for forwarded clocks, RAM write clock/read clock
constraints, etc., and do it in nanoseconds instead of buffer levels.
Looking towards the future, I see a lot of very cool stuff that could be
done with a tool like this. Perhaps downsizing cells for power with the
additional margin provided post-clock insertion. Or planning ahead for
certain pipeline stages to have greater than the average cycle time with the
knowledge that pre/post-ceding stages will have less. RTL could be
partitioned differently, and/or synthesis constraints could be relaxed.
In any case it's a real working and helpful tool today. And the support
Ultima provided on tool usage and issues was excellent. I know of only one
other vendor that has said they are developing similar technology, claiming
they will have it released late this year.
- Jon Stahl, Principal Engineer
Avici Systems N. Billerica, MA
---- ---- ---- ---- ---- ---- ----
From: Mehmet Cirit <mac@libtech.com>
Hi John,
I don't want to spoil your fun watching a point tool grow right in front of
you, but permit me to bring to your attention a few points:
1. Adding more random skew to clocks increases noise on the supplies,
through inductive and substrate coupling. This is a nastier problem
you don't want to mess with especially with low supply voltages.
Reduction on the peak current may be due to increased average latency.
dI/dt is more critical rather than peak current. A low skew clock
network is better from dI/dt point of view.
2. Adding extra drivers, and the extra loads they may entail exacerbates
so called "too much power" problem. 20% more buffers most likely
results in 20% increase in capacitive load, possibly 10% increase
in overall power usage.
3. I wonder if a smart router trying to balance loads may take away the
usefulness out of "useful" skew.
I hope these insights help your readers better understand skew/power issues.
- Dr. Mehmet A. Cirit, President
Library Technologies, Inc. Saratoga, CA
( ESNUG 352 Item 2 ) --------------------------------------------- [5/17/00]
Subject: ( ESNUG 350 #9 ) COT vs. ASIC / Hier vs. Flat Statistical Problem
> So 59% of the designers are designing ASICs, 69% of which are under 1M
> gates. Hierarchical design flows are just starting to limp out into the
> ASIC arena. And yet 80% of the designs are being laid out with some form
> of hierarchy? Huh?
>
> Something's just not fitting together here. I would expect to see some
> correlation between COT and hierarchy, or chip size and hierarchy, but
> this just looks like it's all over the map. If there's all this
> hierarchical layout being done, what design flows are they using? COT
> I can see, but not much ASIC. The flows just aren't that mature yet.
> If there was this much hierarchical ASIC design out there, how come my
> ASIC suppliers look at me like the Exorcist Lady when I insist on
> partitioning my layout?
>
> - Nancy Nettleton
> Sun Microsystems Silicon Valley, CA
From: Gary Smith <gary.smith@gartner.com>
John,
Looks like Nancy is running into a hard core issue. ;-) At least by one
definition using a hard core makes it a hierarchical design. I would think
that's what you're seeing in these responses. As far as COT vs ASIC you can
forget about the question. There are so many individual definitions for the
term COT, you'll never get a good response. There are some engineers that
insist that you need to supply masks for a true COT flow, and GDS-II doesn't
count.
- Gary Smith
DataQuest San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Tom Ayers <tomayers@believe.com>
To: Nancy Nettleton <nancy.nettleton@eng.sun.com>
Nancy,
I would suspect that some of your questions with the data would be reflected
by the following problems:
1) Quite a few design engineers have little idea of how the backend is
actually being done.
2) The survey probably did not draw a distinction in its questioning
between embedded cell ASIC layout (hard macros for memories or other
megacells), and hierarchical layout.
I suspect that combined with floorplan grouping in a flat layout and some
just confused engineers who think they have design hierarchy would throw off
the results.
- Tom Ayers
Believe.com
---- ---- ---- ---- ---- ---- ----
From: Nancy Nettleton <nancy.nettleton@eng.sun.com>
To: Tom Ayers <tomayers@believe.com>
Tom,
You're right. I knew it as soon as I read the analysis. The data is still
interesting, but you kind of have to take it for what it is.
I'm hoping to see a more substantive discussion of hierarchical layout
(beyond the hierarchical vs. flat discussion). The hierarchical vs. flat
discussion is really only interesting until you hit about 2M-3M gates. Then
flat just isn't an option, and many of the hierarchical methodologies are
quite immature.
Are you seeing much in the way of hierarchical layout methodologies?
- Nancy Nettleton
Sun Microsystems Silicon Valley, CA
( ESNUG 352 Item 3 ) --------------------------------------------- [5/17/00]
From: Tongbi Pei <tpei@vitesse.com>
Subject: Can I Fix Transition Violations Without Lots Of Downsized Buffers?
Hi, John,
Recently, when I tried to fix transition violations, I found that Design
Compiler downsized a lot of buffers which I did not want it to do. Does
anybody know how to tell DC not to do this?
- Tongbi Pei
Vitesse Semiconductor Santa Clara, CA
( ESNUG 352 Item 4 ) --------------------------------------------- [5/17/00]
Subject: ( ESNUG 351 #3 ) De-Glitching Coverage Tools Are A General Issue
> Unfortunately, I have not been able to turn "deglitch" off correctly and
> get a good run. And I don't have any time to work on it.
>
> My advice to others, especially if you are using Verilog-XL, or if you
> suspect you are getting false positives in combinatorial always@'s
> (always@(signal_list)), would be to run this code snippet: ...
>
> - Dan Joyce
> Compaq Computers
From: Dan Joyce <dan.joyce@compaq.com>
Hi, John,
I sent you the wrong test Verilog code snippet to test for that code
coverage bug in ESNUG 351 #3. Here's the correct version:
module test1(
);
reg clk;
reg [4:0] register;
reg [4:0] register_next_state;
reg error;
reg error_next_state;
reg [11:0] count;
initial begin
//$dumpvars;
register <= 0;
error <= 0;
clk <= 0;
count <= 0;
#20 clk <= 1;
end
always@(clk) clk <= #20 ~clk;
always@(posedge clk) begin
count <= count+1;
if (count == 12'hfff) $finish;
end
always@(register) begin
if(register[0]) register_next_state = 5'b00000;
else register_next_state = 5'b11111;
case(register)
5'b00000 : error_next_state = 0;
5'b11111 : error_next_state = 0;
default : error_next_state = 1; // This line should show NO
coverage!!!
endcase
end
always@(posedge clk) begin
register <= register_next_state;
error <= error_next_state;
end
endmodule
BTW, I think this bug is a generalized issue for all code coverage tools,
so your readers should try this test on their favorite coverage tool.
- Dan Joyce
Compaq Computers
( ESNUG 352 Item 5 ) --------------------------------------------- [5/17/00]
Subject: Muddling From A 3-Pass To A 2-Pass Hierarchical Layout Methodology
> I'm hoping to see a more substantive discussion of hierarchical layout
> (beyond the hierarchical vs. flat discussion). The hierarchical vs. flat
> discussion is really only interesting until you hit about 2M-3M gates.
> Then flat just isn't an option, and many of the hierarchical
> methodologies are quite immature.
>
> Are you seeing much in the way of hierarchical layout methodologies?
>
> - Nancy Nettleton
> Sun Microsystems Silicon Valley, CA
From: Tom Ayers <tomayers@believe.com>
To: Nancy Nettleton <nancy.nettleton@eng.sun.com>
Hi, Nancy,
I've done quite a bit of hierarchical layout, but the tool support for this
technique is spotty. Typically the process involves the following:
1) Project lead determines hierarchical breakdown of chip into
"subsystems" which are place and route blocks. Hierarchical
equivalence is maintained between RTL and layout. Subsystems have
additional requirements from modules, usually WRT reset, interrupt,
etc., resynchronization for synchronous distribution across the chip
and clock tree components if clock tree synthesis is not being used.
2) At RTL code complete, first pass floorplan is done. Blocks are 90%
accurate for cell area and margin is added for late maturing blocks.
Manual global routing (Synopsys has new tool optimized for this, but
I don't know how good it is) and megacell memory placement is done and
timing data extracted for subsystems (PrimeTime or Ambit would be best
for this since they have time budgeting). Some global buses may be
SPICEd.
3) Representative subsystem is selected for full trial P&R closure to
iron out tool flow issues.
4) Final RTL synthesis is done after validation complete and subsystem
areas compared to allow floorplan to be "jiggled" to correct sizes.
5) P&R closure for each subsystem with IPO runs.
6) Full chip parasitic extraction and static timing.
7) LVS/DRC/tapeout
This pass I expect to integrate Chip Architect to allow both forward
annotation of basic floorplan from design team to backend and to help
timing closure with synthesis to placed gates.
I would be interested to hear what you are doing over there at Sun.
- Tom Ayers
Believe.com
---- ---- ---- ---- ---- ---- ----
From: Nancy Nettleton <nancy.nettleton@eng.sun.com>
To: Tom Ayers <tomayers@believe.com>
Hey Tom,
What we're doing is very, very similar. I'll explain the overall
differences and then annotate your mail with specific differences.
One question: are you in an ASIC flow, a COT flow, or are you in a kind of
a revised ASIC flow where you have an ASIC vendor doing P&R but you're
doing up-front floorplanning and cell placement to close timing?
Here's some of the differences between what you describe and what I've put
into place for our ASICs.
1. I've been emphasizing stages of the project in addition to specific
tool capabilities (since I've seen alot of projects that went
to layout either too early or too late to close). I work really
hard up-front to define what design milestones we need to meet
for given levels of layout.
2. For our last four 1M+ gate ASICs, we've had our ASIC suppliers do
all floorplanning, placement, and timing closure. I check out
the suppliers, set up the projects, and keep track of them as
they go through the pipe, but the suppliers do all the heavy
lifting in physical design.
3. We've got hierarchical flows running on both Avanti and Cadence, both
with extensive homebrew from the ASIC suppliers. We use DC for
synthesis and PrimeTime for pre- and post-layout STA, but most of our
time budgeting has been pretty manual. That's not going to work for
3M+ gate ASICs.
4. I've been working with the teams to get 3 full chip layouts done,
but I've been wanting to try to move to a 2-layout model if I can get
the suppliers flows stabilized. I'd be interested to compare notes
to see how your 2-layout model works.
Our 3-layout model works something like this:
Layout 1: 80-90% gates synthesized
All memories, hard macs, clocks, & DFT implemented
Pre-layout Timing and verification level irrelevant
Layout Goals:
. Confirm die size
. Structure clocks, top-level busses, and critical
I/O paths
. Identify any architecturally or floorplan
limited critical paths.
. Work the kinks out of the hand-off model (esp.
for timing constraints)
. Work the kinks out of the methodology
. Set timing budgets
Layout 2: All gates synthesized
Sufficient verification to assure that top-level
will not change in final layout.
Timing met in synthesis with parasitics and budgets
from layout 1.
Layout Goals:
. Layout and freeze top-level routing.
. Close timing to synthesis timing.
Layout 3: This is basically the layout that goes to mask.
Logic is fully verified.
Because the top-level is frozen (small # ECO's allowed),
this layout is just a block-level re-spin,
making it much faster than layout 2.
What I've been telling my projects is that we could cut out the first layout
if we could take another 2-4 weeks on the 2nd and 3rd layout OR if they
could leave more area/timing margin to take care of last minute problems.
So far I haven't had a project want to take the additional time or margin.
My feel is that management is willing to pay more up-front NRE for an add'l
layout in order to minimize the time it takes to get from fully verified
RTL to mask.
I also suspect that for the last 4 ASICs, we've been hitting some pretty
raw design methodologies. For all 4 ASICs, we were their first hierarchical
design project, the first project on which they had fully owned layout
timing closure, and the first project on which they had to close
cross-capacitance. It was alot of methodology to check out in just 2
layouts. I don't think I could've done it.
> 1) Project lead determines hierarchical breakdown of chip into
> "subsystems" which are place and route blocks. Hierarchical
> equivalence is maintained between RTL and layout. Subsystems have
> additional requirements from modules, usually WRT reset, interrupt,
> etc., resynchronization for synchronous distribution across the chip
> and clock tree components if clock tree synthesis is not being used.
We break out the hierarchy with our suppliers (because they look at the
physical side while Sun ASIC managers look at the logical). If we were
in a COT environment, or our design managers had more experience with
hierarchical layout, I would do what you describe above.
> 2) At RTL code complete, first pass floorplan is done. Blocks are 90%
> accurate for cell area and margin is added for late maturing blocks.
> Manual global routing (Synopsys has new tool optimized for this, but
> I don't know how good it is) and megacell memory placement is done
> and timing data extracted for subsystems (PrimeTime or Ambit would
> be best for this since they have time budgeting). Some global buses
> may be SPICEd.
This sounds like my Layout 1 (90% complete, margin added for late maturing
blocks...) We do the top-level route automatically in both our Cadence and
Avanti flows. We do full block-level floorplanning, cell placement, and
routing. I haven't tried PrimeTime for budgeting yet, but I'm going to try
on my next project. We don't spice global busses, but we do spice clocks
and some sensitive I/O paths (choice of what gets spiced is pretty design-
specific).
> 3) Representative subsystem is selected for full trial P&R closure to
> iron out tool flow issues.
Yep. Because it is so hard to identify all architecturally limited paths
in synthesis, I've been doing all blocks. It also helps us characterize
insertion delay on un-PLL'ed clocks.
> 4) Final RTL synthesis is done after validation complete and subsystem
> areas compared to allow floorplan to be "jiggled" to correct sizes.
One big problem we've been encountering in the multi-million gate ASICs is
that the typical 20-50% error in estimating gate count has just killed us.
We've had netlists grow by hundreds of thousands (and once even a million)
gates from release to release. For this reason, we've started tracking
gate counts in between layout netlist releases, so that if something really
starts to grow, we can respond with an early floorplanning netlist before
the real netlist release.
It probably starts sounding a bit maniacal, but once that netlist is handed
off to layout, our management starts the clock ticking like its a death
march. Anything we can do to pull time out of that netlist-to-closure
time, we really need to do it. We really emphasize early identification
of issues for that reason.
> 5) P&R closure for each subsystem with IPO runs.
> 6) Full chip parasitic extraction and static timing.
> 7) LVS/DRC/tapeout
That's my Layout 3.
> This pass I expect to integrate Chip Architect to allow both forward
> annotation of basic floorplan from design team to backend and to help
> timing closure with synthesis to placed gates.
This makes me think you're in a hybrid ASIC team where you're doing some
floorplanning and placement to help close your synthesis-to-layout timing.
I've wanted to explore this methodology, but most of the Sun ASIC teams
have been very resistant to building any sort of physical infrastructure/
knowledge at all. They pay for it in NRE, but they seem to prefer that
to coughing up for the tools/engineers it would take. I think we can only
get away with it because we're such a big chunk of the ASIC suppliers pie.
I'd be surprised if we can get away with it forever.
What kind of hand-off model environment are you in?
- Nancy Nettleton
Sun Microsystems Silicon Valley, CA
---- ---- ---- ---- ---- ---- ----
From: Tom Ayers <tomayers@believe.com>
To: Nancy Nettleton <nancy.nettleton@eng.sun.com>
> One question: are you in an ASIC flow, a COT flow, or are you in a kind
> of a revised ASIC flow where you have an ASIC vendor doing P&R but you're
> doing up-front floorplanning and cell placement to close timing?
Hi, Nancy,
For ASIC processes, it was upfront floorplanning using either CMDE (LSI) or
Compass to do soft floorplanning and megacell placement with ASIC provider
doing power strapping, clock tree, column cutting, and P&R. For COTs
process, our design group would draw out floorplan as starting point for
the backend group and review final megacell placement and actual floorplan.
> 1. I've been emphasizing stages of the project in addition to specific
> tool capabilities (since I've seen alot of projects that went
> to layout either too early or too late to close). I work really
> hard up-front to define what design milestones we need to meet
> for given levels of layout.
Yes, I usually use a "layout checklist" which needs to be filled out before
you are ready. If you can fill it out, then you are probably ready (all
clock, reset, cell type restrictions, layout instructions, checks on
synthesis and static timing results, etc).
> 2. For our last four 1M+ gate ASICs, we've had our ASIC suppliers do
> all floorplanning, placement, and timing closure. I check out
> the suppliers, set up the projects, and keep track of them as
> they go through the pipe, but the suppliers do all the heavy
> lifting in physical design.
I like keeping basic floorplanning in house and detailed (LVS/DRC clean)
floorplanning at the backend, or at least floorplan specification. There
is too much that can be done to impair timing closure without designer
guidance. That is why I find Chip Architect promising.
> 3. We've got hierarchical flows running on both Avant! and Cadence, both
> with extensive homebrew from the ASIC suppliers. We use DC for
> synthesis and PrimeTime for pre- and post-layout STA, but most of our
> time budgeting has been pretty manual. That's not going to work for
> 3M+ gate ASICs.
Have used mostly DC static timing in the past as it is mostly fast enough
and mode dependancies were not needed. Will use PrimeTime this time,
mostly due to time budgeting aspect which I agree needs to be less manual
(and was extracted from DC static timing plus perl scripts on previous
projects).
> 4. I've been working with the teams to get 3 full chip layouts done,
> but I've been wanting to try to move to a 2-layout model if I can get
> the suppliers flows stabilized. I'd be interested to compare notes
> to see how your 2-layout model works.
I have had pretty good luck with two layout model. The important point is
in not kidding yourself about when you are ready for the first layout,
otherwise you are sure to do three. Checklists can help here. Try the
following:
Layout 1: All gates synthesized.
All memories, hard macs, clocks, & DFT implemented
Sufficient verification to assure that top-level
will not change significantly in final layout.
Timing goals not necessarily closed, but not way off.
Reasonable compile strategy (-map_effort med)
minimum.
All false, multicycle, etc paths worked out.
No timing arcs.
DFT not debugged
Layout Goals:
. Confirm die size
. Structure clocks, top-level busses, and critical
I/O paths
. Identify any architecturally or floorplan
limited critical paths.
. Work the kinks out of the hand-off model (esp.
for timing constraints)
. Work the kinks out of the methodology
. Set timing budgets
. Layout and freeze top-level routing.
. Close timing on one P&R block to iron out
tool flow.
Layout 2: Top level netlist released 1 week in advance of
validation closure.
Subsystems released as validation complete
and signoff checklists completed.
This is basically the layout that goes to mask.
Logic is fully verified.
> What I've been telling my projects is that we could cut out the first
> layout if we could take another 2-4 weeks on the 2nd and 3rd layout OR
> if they could leave more area/timing margin to take care of last minute
> problems. So far I haven't had a project want to take the additional
> time or margin. My feel is that management is willing to pay more
> up-front NRE for an add'l layout in order to minimize the time it takes
> to get from fully verified RTL to mask.
This depends on your market really. For performance oriented designs such
as microprocessors and 3D graphics parts, speed is everyting. For designs
where the clock rate is not the key driving issue, doing an extra layout
actually slows the team down and you are better off adding some additional
margin to your design (order of 5-10% of clock period makes a big
difference).
It also pays to have good predictive wireload models.
>> 1) Project lead determines hierarchical breakdown of chip into
>> "subsystems" which are place and route blocks. Hierarchical
>> equivalence is maintained between RTL and layout. Subsystems have
>> additional requirements from modules, usually WRT reset, interrupt,
>> etc., resynchronization for synchronous distribution across the chip
>> and clock tree components if clock tree synthesis is not being used.
>
> We break out the hierarchy with our suppliers (because they look at the
> physical side while Sun ASIC managers look at the logical). If we were
> in a COT environment, or our design managers had more experience with
> hierarchical layout, I would do what you describe above.
We tend to make this easy to do by wrapping modules in "subsystem wrappers".
These wrappers also include some o fthe things I've listed above as well as
bus interfaces for internal high speed chip buses. We went as far as
standardizing the backside interface to the bus interface so that all
modules would have consistant host interfaces that were not tied to the
current internal bus implementation.
>> 2) At RTL code complete, first pass floorplan is done. Blocks are 90%
>> accurate for cell area and margin is added for late maturing blocks.
>> Manual global routing (Synopsys has new tool optimized for this, but
>> I don't know how good it is) and megacell memory placement is done
>> and timing data extracted for subsystems (PrimeTime or Ambit would
>> be best for this since they have time budgeting). Some global busses
>> may be SPICEd.
>
> This sounds like my Layout 1 (90% complete, margin added for late maturing
> blocks...) We do the top-level route automatically in both our Cadence
> and Avanti flows. We do full block-level floorplanning, cell placement,
> and routing. I haven't tried PrimeTime for budgeting yet, but I'm going
> to try on my next project. We don't spice global busses, but we do spice
> clocks and some sensitive I/O paths (choice of what gets spiced is pretty
> design-specific).
Difference is primarily in level of completeness. Checklists ensure a
higher degree of accuracy in area implementation and most of the remaining
area issues are non-floorplan critical. Some of our internal buses have
been cross-chip high speed internal processor (SOC) buses with long wire
lengths and many clients. We were not comfortable with just A2STAR or
something similar.
>> 3) Representative subsystem is selected for full trial P&R closure to
>> iron out tool flow issues.
>
> Yep. Because it is so hard to identify all architecturally limited paths
> in synthesis, I've been doing all blocks. It also helps us characterize
> insertion delay on un-PLL'ed clocks.
Maybe your wireload models are not so good? I have not really had much
difficulty identifying limited paths in synthesis.
>> 4) Final RTL synthesis is done after validation complete and subsystem
>> areas compared to allow floorplan to be "jiggled" to correct sizes.
>
> One big problem we've been encountering in the multi-million gate ASICs is
> that the typical 20-50% error in estimating gate count has just killed us.
> We've had netlists grow by hundreds of thousands (and once even a million)
> gates from release to release. For this reason, we've started tracking
> gate counts in between layout netlist releases, so that if something
> really starts to grow, we can respond with an early floorplanning netlist
> before the real netlist release.
>
> It probably starts sounding a bit maniacal, but once that netlist is
> handed off to layout, our management starts the clock ticking like its a
> death march. Anything we can do to speed up that netlist-to-closure
> time, we really need to do it. We really emphasize early identification
> of issues for that reason.
Sure. The problem above is because you are doing netlist #1 too early.
It is mostly a wasted effort at that point. We use spreadsheets that list
modules down the left side and module specific data along the top such as
current area, method of determining area, DFT % coverage, number of flops
per domain, and milestones with expected completion dates.
As the project matures, information fills in left to right giving a quick
glance at project progress as well as a wealth of information about the
project data.
>> This pass I expect to integrate Chip Architect to allow both forward
>> annotation of basic floorplan from design team to backend and to help
>> timing closure with synthesis to placed gates.
>
> This makes me think you're in a hybrid ASIC team where you're doing some
> floorplanning and placement to help close your synthesis-to-layout timing.
> I've wanted to explore this methodology, but most of the Sun ASIC teams
> have been very resistant to building any sort of physical infrastructure/
> knowledge at all. They pay for it in NRE, but they seem to prefer that
> to coughing up for the tools/engineers it would take. I think we can only
> get away with it because we're such a big chunk of the ASIC suppliers pie.
> I'd be surprised if we can get away with it forever.
I have not yet met a project manager who did not want to draw up the basic
floorplan yet. I do not mean jiggle every memory into the exact location,
but draw the rough boundaries and cell placements. This would be forward
annotated to the backend team who would make the real floorplan. For
instance your Layout #1 could be done completely in Chip Architect and done
quickly to get subsystem timing budgets. Little time would be wasted in
doing a detailed layout for something that is not yet ready for this. Some
full ASIC houses such as LSI, IBM, VLSI, etc provide the tools and expect
you to do this step anyways.
The real advantage that I hope to get, however, is to follow a synthesis to
placed gates methodology. 99% of timing closure problems are due to gate
placement, not routing. Chip Architect allows running synthesis to
placement and iterating on it in one tool and the forward annotating the
LEF/DEF files to the final router. This should be legal placement at this
point which means timing closure should be quick.
- Tom Ayers
Believe.com
---- ---- ---- ---- ---- ---- ----
From: Nancy Nettleton <nancy.nettleton@eng.sun.com>
To: Tom Ayers <tomayers@believe.com>
> Yes, I usually use a "layout checklist" which needs to be filled out
> before you are ready. If you can fill it out, then you are probably ready
> (all clock, reset, cell type restrictions, layout instructions, checks on
> synthesis and static timing results, etc).
Hi, Tom,
Most of our designers want to go to layout before they could complete
such a checklist. One of my biggest pushes in the past year has been
to get the projects embedding checklist items in their project plans so
we aren't scrambling at the last minute trying to put in place something
we need but neglected.
> I like keeping basic floorplanning in house and detailed (LVS/DRC clean)
> floorplanning at the backend, or at least floorplan specification. There
> is too much that can be done to impair timing closure without designer
> guidance. That is why I find Chip Architect promising.
We've been providing designer guidance to floorplanning via an extensive
design review process as well as face2face, @the-workstation sessions
to tune it.
I've been finding that even with alot of designer interaction, there are
data flow and timing detail we miss until we get timing constraints,
particularly wrt DFT. Too many whacked out half-cycle paths and things
that are just hard to identify and handle without detailed specs.
I'm getting ready to try a hybrid kind of hierarchical flow that may give
me the best of both worlds (famous last words :-)
We used to do this back on UltraSparc II, but until we had good hierarchy,
there was no sense trying it on ASICs.
We're going to do one netlist release to stabilize the top-level. The
block-level netlists will need to have all memories instantiated with
most of their gates and good estimates of how many gates are still
coming. We'll stabilize the top-level and block-level floorplans, then
set the block-level layout flows up so that they can be executed as a
back-end to the synthesis flow so that my logic designers can check
physical timing for a synthesis run (instead of just checking synthesis
timing with WLM's). The trick will be stabilizing the floorplans enough
that the blocks can spin inside that floorplan for a while. I expect
we'll want to spin the block layout down through placement and rough
layout timing closure, but not through routing. This way, designers
can see their physical timing without going through all the work of
releasing a netlist to physical design.
The only things I haven't worked out yet are how often do we need to
integrate the whole chip to make sure it'll work (guessing twice), who
writes/maintains the rough PD flows (us or our supplier), and does the
rough PD flow produce just timing or something useful to layout as well.
I don't have a chip to try this on yet. It could be a few months before
I can really work the kinks out of this.
> This depends on your market really. For performance oriented designs
> such as microprocessors and 3D graphics parts, speed is everyting. For
> designs where the clock rate is not the key driving issue, doing an extra
> layout actually slows the team down and you are better off adding some
> additional margin to your design (order of 5-10% of clock period makes a
> big difference).
>
> It also pays to have good predictive wireload models.
In alot of ways I agree with you, but when I think back over the last few
projects I worked on, we could not have done it without that first layout.
Of the last 5 ASICs I've worked on, 2 had the wrong physical design strategy
going in. This was due to alot of things like immature architectures and
inexperience with the process technology. If we hadn't done 1 trial
layout to find out we had the wrong strategy, we would've spent all our time
in the final trial layout focusing on methodology and not on the design.
On the last 3 ASICs, we did not have the wrong physical strategy going in.
I could possibly have lived without 2 trial layouts, but it would've taken
longer because the physical team had never owned layout timing closure and
never done hierarchy.
Its possible Sun needs 3 layout spins because our business people insist
on contracting high performance, high complexity silicon with suppliers
who really don't do high performance, high complexity. I hadn't thought
about that alot.
> - What is your cross-capacitance issue?
I worked with our microprocessor design group to review their 0.18 um
simulation results, and it was a big wake-up call. When we started
simulating our ASIC 0.18 um technologies/libraries, we found that with
as little as 1 mm of adjacent routing, we could see >50% increase in
delay. We also found that with about 1 mm of adjacent routing, we could
get noise glitches better than .8V. So we started our 0.18 um suppliers
working on xcap noise/delay check & repair. What an odyssey...
We've got flows in place now that are finding and fixing coupling
topologies that would've caused us to violate set-up or clock in an
incorrect logic value. All of our xcap checking is static, so it all
assumes worst-case phase relationships.
The only silicon data I have on xcap is test chip data. I haven't had
a chip fail on xcap yet. I've heard of a couple in 0.25um, but we
skipped 0.25um for the most part.
> Maybe your wireload models are not so good? I have not really had much
> difficulty identifying limited paths in synthesis.
Our largest hierarchical ASIC was partitioned into 19 sub-modules, so it's
way over-partitioned. Consequently, there are many long, skinny blocks for
which WLM's just don't work very well.
I also think we had alot of young engineers really hoping against hope that
marginal paths would make it. It was a real struggle to institute a logic
level budget of 30 levels of logic for 200MHz design. The custom wireload
models helped, but it was still a struggle getting some of the paths down.
I think it was acerbated by late changes to the architecture, but I really
don't see that end of things.
> We use spreadsheets that list modules down the left side and module
> specific data along the top such as current area, method of determining
> area, DFT % coverage, number of flops per domain, and milestones with
> expected completion dates. As the project matures, information fills in
> left to right giving a quick glance at project progress as well as a
> wealth of information about the project data.
I agree that the spreadsheet data is absolutely necessary, but I'm still
not convinced we could live without netlist #1 on all designs. Without a
stable methodology, the risk is just too great that we wouldn't be able
to freeze the top-level before final layout. I can't tell you how many
hours I've spent in meetings with managers trying to scrub 3 days out of
the final layout schedule.
> I have not yet met a project manager who did not want to draw up the basic
> floorplan yet. I do not mean jiggle every memory into the exact location,
> but draw the rough boundaries and cell placements. This would be forward
> annotated to the backend team who would make the real floorplan. For
> instance your Layout #1 could be done completely in Chip Architect and
> done quickly to get subsystem timing budgets. Little time would be wasted
> in doing a detailed layout for something that is not yet ready for this.
> Some full ASIC houses such as LSI, IBM, VLSI, etc provide the tools and
> expect you to do this step anyways.
I, also, have not met a design manager who didn't want to draw the basic
boundaries and module placements.
Don't know about Chip Architect. Last time I looked at it, it couldn't
structure real clocks, which is a must-have out of the first integration
for us.
Agreed on ASIC house expectations. Like I said, I think sun often gets
a different ride on the same merri-go-round.
> The real advantage that I hope to get, however, is to follow a synthesis
> to placed gates methodology. 99% of timing closure problems are due to
> gate placement, not routing.
Couldn't agree more. That's what I'm hoping to get out of my hybrid flow
I outlined above.
The only gotch here is if cross-capacitance increases dramatically in
0.15um technologies. I really hope the guys working on xcap avoidance
are coming up with something good, because the processor data I'm
looking at is not very encouraging. As their clock rates approached
500MHz, their cross-cap shot up because of increased slew rate. They
were finding 10-100x more xcap violations than I'm getting for the same
metallization scheme. That kind of increase in xcap violations could
mean we'll have to go to routing to know our timing. Man that would
suck. I've really got my fingers crossed for xcap avoidance.
> Chip Architect allows running synthesis to placement and iterating on it
> in one tool and the forward annotating the LEF/DEF files to the final
> router. This should be legal placement at this point which means timing
> closure should be quick.
That might be really slick. I'll be interested to see how it works out.
- Nancy Nettleton
Sun Microsystems Silicon Valley, CA
( ESNUG 352 Item 6 ) --------------------------------------------- [5/17/00]
Subject: ( ESNUG 351 #7 ) Curry's Holy War On Oren's Verilog "<= #1" Idea
> I didn't see Cliff's presentation at SNUG (I was in a different session),
> but this is indeed a very thorough analysis of the different cases. All of
> Cliff's guidelines have been standard practice for us, for a long time.
>
> I'd add one guideline of my own - add a #1 in the nonblocking assignments
> to sequential elements:
>
> a <= #1 b;
>
> instead of
>
> a <= b;
>
> There are two reasons for this:
>
> 1. It allows mixed RTL and gate-level simulations to run correctly,
> by providing 1ns of hold time to the gate-level flip-flops.
> 2. It's so much easier to understand what you see on the waves display
> when you're trying to debug something, because signals change 1 ns
> after the clock edge.
>
> Good paper, Cliff.
>
> - Oren Rubinstein
> GigaPixel Corp. Santa Clara, CA
From: Mark Curry <mcurry@ti.com>
Hi, John,
Argh. Actually I was quite pleased when Cliff's paper did NOT have these #1
all over the place. I assumed it was on purpose. I've been on a crusade in
my group to get everyone to DROP these silly #1s all over the place.
Why I hate #1s.
1. They make your code ugly. It ties timing info to something that
really shouldn't have or need timing. No timescale's appear in any
of my RTL because it's not needed. What happens if your clock (from
the testbench) ends up being faster than a #1 ( whatever unit it is )?
2. They cause more problems than than they solve. #1 insertion in our
group has been mix and match. Some have it, some don't. Some add it
to combo blocks as well as flip-flops. With all of these differences,
one starts getting glitches at the RTL level debug. Doesn't really
matter, but's it's disconcerting to see glitches in your waveforms
when you're only runnning RTL.
Oren's #1 (bad pun) reason above is usually easily solvable by turning on
zero delay models, and/or function only models for the gate level portions
of designs.
As to his #2 reason. This is designer preference. I have no problem
debugging waveforms. Actually, doing it this way for so long, I feel I have
a better understanding of the event-scheduling in verilog, and Cliff's
paper made perfect sense!
In the end, it's pretty much still designer preference on the #1 in our
group. But, I'm still not giving up. And I can't keep quiet when someone
else suggests to use 'em!!
- Mark Curry
Texas Instruments Broadband Access Group
( ESNUG 352 Item 7 ) --------------------------------------------- [5/17/00]
Subject: ( ESNUG 351 #8 ) Formality, Chrysalis, Verisity, & Model Checkers
> A few weeks ago, one of my readers forwarded me this anonymous post from
> the Yahoo CDN stock chat board:
>
> "Formality sales of about $10M doesn't point to a market leader, it
> seems like a tool bundled into a larger deal for a low price, which
> Synopsys can afford to do to build a market presence. As you probably
> know, formal verification is divided into two areas, model checking
> and comparison checking. Verplex is the runaway leader in comparison
> checking, and Chrysalis/Avanti still owns model checking. Another area
> is test bench verification where Synopsys has no presence and Verisity
> is the leader here. There is also a new company on the horizon that
> will challenge Verisity. So Formality's survival is in question, and
> this area is hot and growing."
>
> Why I'm reprinting this is that passing claim that "Chrysalis/Avanti still
> owns model checking" -- is this true? What are the customer experiences
> with their model checking tools? Why I ask this was while at HDLcon'00, I
> ran into a Cadence marketing guy who said Cadence was doing very well in
> the model checking business. I would love to see a detailed customer
> review of the Cadence model checking tools just to see if this Cadence
> marketdroid was on-the-money or blowing smoke.
>
> - John Cooley
> the ESNUG guy
From: Sherri Al-Ashari <sherria@brightlink.com>
So, when I worked at SUN, the terminology was model checking and equivalency
checking and theorem proving. The first 2 operated on RTL, and the third
you had to write what you were proving in some mathematical language. From
what I had seen ~2 years ago was that Chrysalis was ahead in equivalency
checking and FormalCheck (purchased by Cadence from Lucent) was the easiest
to use model checker.
I'm interested in hearing about this challenger to Verisity... is there
really room for a third? I wonder how believable this Yahoo source is....
- Sherri Al-Ashari
---- ---- ---- ---- ---- ---- ----
From: Mike Bartley <mike.bartley@infineon.com>
John,
You say there is also a new company on the horizon that will challenge
Verisity. Can you give more details please?
- Mike Bartley
Infineon
---- ---- ---- ---- ---- ---- ----
From: Garry Tuttle <garry.tuttle@alt-tech.com>
Hello, John,
In one of your recent ESNUGs you mentioned a company who offer a product
competitive to Verisity. We are an EDA distributor and always on the look
out for new tools to sell in the UK and Republic of Ireland. We would be
interested to find out more about this company - can you send me more
information please?
- Garry Tuttle
Alt Technologies Basingstoke, Hampshire, UK
---- ---- ---- ---- ---- ---- ----
From: Erik Jessen <Erik.Jessen@Vixel.com>
Hi, John,
I've not tried Cadence model-checking, but I believe it to be very useful.
On equivalency checking, Verplex has worked well for us. RTL v. gate on
600k gates:
flattened hierarchy : 3 hours
hieararchical compare: < 1 hour
on a Sun 266MHz CPU.
We do FPGAs and also have done equivalency checking there. We found the
following interesting results. Given:
reg [15:0] foo;
always @ (posedge clk)
if (fee == 1'b1)
foo <= 16'h0000;
else
foo <= 16'hFFFF;
Synopsys generates 16 flops for "foo". Synplicity recognizes that all 16
flops are set to the same value, and simply implements a single flop, then
wires its output 16 places. But none of the equivalency checking tools we
tried cope with Synplicity's results. Verplex allows you to tell it that
16 flops in RTL are equivalent to a single flop in gates. This led me to
do the following:
1.) I asked Synopsys to do similar flop elimination; they said they set
a policy long ago that they would output the 16 flops. (Can anyone
help me encourage them to at least have a switch to do this cleanup?)
2.) I talked to Synplicity and asked them to work with the equivalency
cheching vendors & write out a mapping file so that people can run
EC on their FPGA netlists, and also identify redundant flops in the
original design. I believe they are working on it.
In power-sensitive ASIC applications, I'd run Synplicity & EC on my netlist
to find redundant flops & remove them, before running Synopsys. Battery
time is worth it.
- Erik Jessen
Vixel Irvine, CA
---- ---- ---- ---- ---- ---- ----
From: Avi Parash <parash@zoran.co.il>
Hi John,
IBM has a Model Checker as well. (I am using it.) For more info see:
http://www.haifa.il.ibm.com/projects/verification/RB_Homepage/
Regards,
- Avi Parash
Zoran Microelectronic Ltd. Israel
( ESNUG 352 Item 8 ) --------------------------------------------- [5/17/00]
Subject: ( ESNUG 350 #10 ) The URL For The Behavioral Compiler Tutorial
> Is anyone aware of a Behavioral Compiler tutorial (preferably a Verilog
> based tutorial?) Every Synopsys tool has its own tutorial in the
> documentation, except Behavioral Compiler. I searched the SNUG & SolvNET
> sites, but couldn't find anything. Any help apprieciated!
>
> - Lars Rzymianowicz
> University of Mannheim Mannheim, Germany
From: [ A Synopsys BC CAE ]
Hi John,
Actually we have what you're seeking in the Synopsys website. Go to
www.synopsys.com, choose "Behavioral Compiler" under "synopsys products"
list. Click on "Insight for Behavioral Compiler", you will get into
BC insight webpage:
http://www.synopsys.com/insight/BC/BC_home.html
You need to have synopsys username and password to login. This page will
guide you through a BC overview, the basics of BC, how to write your
design in Behavioral level and achieve higher performance.
There are two design examples under "Design Examples". One is a simple
complex multiplication design which shows you the basic behavioral flow
and BC commands. Behavioral code is shown in both Verilog and VHDL.
Another design is a real world example -- Inverse Quantisation (IQ) widely
used in MPEG decoders. It has the design description in .pdf format and
the whole design in both Verilog and VHDL which can be downloaded directly
from the Web. The file contains several labs that teach you how to complete
the design for synthesis and simulation and use advanced techniques to
achieve higher performance.
On the web, you can also download the "Behavioral Compiler Handbook" which
comes pretty handy and useful.
- [ A Synopsys BC CAE ]
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,086 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."
|
|
