Editor's Note: I wish to apologize if you're getting this ESNUG post a
little later than normal. I'm late because almost a year ago (Dec. 10th,
1999 to be exact) it was a very rainy day here in Boston.
Here's my story.
Every year I pay for my car insurance with one annual check. On Dec. 10,
1999, I handed my insurance company $700. But, because it was a rainy day
I ended up doing their required photographic car inspection 3 weeks later.
When the insurance company's computer found that I didn't have the photo
inspection yet, it automatically dropped my Comprehesive coverage and
sent me a $200 refund. Then, 3 weeks later, when the photo inspection
happened, it automatically re-instated my Comprehensive coverage and
billed me that missing $200. The glitch was the insurance company
computer was sending all these notices to the WRONG ADDRESS -- so I didn't
know any of this was going on! And when August came around, the same
computer completely cancelled my insurance (because it said I had only
paid $500) and, again, sent the notice to that same wrong address...
Thursday night I'm driving home from my girlfriend's place obeying all the
traffic laws like a true nerd. Unexpectedly the cops pull me over(!)
They then impounded my car because I was driving uninsured(!) And they
tell me this is a *criminal* offense in Massachussetts!!! So at 2:AM,
some good friends picked me up from the Wellesley police station and gave
me a ride home. Since then I've been on foot and I've been a bit more
focused on getting my insurance company to clean up this mess over getting
this particular ESNUG post out the door. So, sorry for being late.
(Damn rainy Decembers...)
- John Cooley
the ESNUG guy
( ESNUG 361 Subjects ) ------------------------------------------- [11/16/00]
Item 1 : Technical Details Of The Geocast TSMC 0.18 PKS/Ambit-RTL Tape-out
Item 2 : Boston SNUG Speaker On Tcl Seeks Help On SolvNet DC-Tcl Script
Item 3 : ( ESNUG 360 #12 ) Ambit-RTL & Interra Concorde *Loves* Aggregates
Item 4 : ( ESNUG 360 #17 ) DC-Tcl 'Collections' Is Not Like Tcl 'Lists'
Item 5 : ( ESNUG 360 #1 ) PhysOpt/Saturn/PKS For Wimps; Real Men Use P&R!
Item 6 : Warning -- PrimeTime 00.05 "update_timing" MUST HAVE the "-full"
Item 7 : ( ESNUG 360 #4 ) Suns Crap Out -- WSJ, SGI, Linux, HPs, PC Farms
Item 8 : ( ESNUG 360 #13 ) A User Compares Synopsys SystemC vs. CynLib
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 361 Item 1 ) --------------------------------------------- [11/16/00]
From: Thad McCracken <thad@geocast.com>
Subject: Technical Details Of The Geocast TSMC 0.18 PKS/Ambit-RTL Tape-out
Hi, John,
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. Most
its RTL was taken from a prior 0.35u chip I worked on that is now a part of
our our Geobox product line. We reworked our RTL slightly to accommodate
these additional 8 custom macros (also designed here at Geocast):
- a clock multiplier
- a DLL
- 3 instances of 32x32 register file
- 3 instances of 64x64 register file
- 1 instance of a CAM
We also implemented some additional testability around the CAM.
These two test chips are our first chips on a 0.18u process. With the TSMC
CyberShuttle test tape-out (our second test tape-out) we tweaked the clock
multiplier on the chip.
The original 0.35u implementation of this design ran at 100Mhz. These 0.18u
tape-outs were implemented to a timing target of 160Mhz -- a goal largely
set by the speed at which the I/Os would run. We ran the core design in
PKS at 200 Mhz and the runtime went from 7 hours to 10 hours (as was to be
expected).
A few months ago there was some heated discussion in ESNUG about designing
chip hierarchically versus flat. We're strongly in the hierarchical camp.
Our chips are typically too big to consider doing flat, and we like being
able to spin portions of the design w/o unnecessarily impacting unrelated
parts of the chip. Since this 200 Kgate was basically a single P&R region,
though, we ran it through the flow I'll describe below flat (in a physical
sense, that is.)
Given this as a starting point, for PKS we started with a chip floorplan,
in .def format, that had the following information:
- pad cell placements
- standard cell rows
- custom macros pre-placed (with appropriate adjustments to
standard cell rows)
- endcap cells
- all power gridding
Our Initial PKS Flow
--------------------
The details of the PKS portion of our flow looks like:
1.) Set up all the system varibles like floorplanning parameters,
special net pin names, cell halos, default RAM halos, etc.
Read in Verilog, Ambit compiled version of the .libs, .LEF files,
PKS layer utilization tables.
read_alf, read_library_update # (to read in compiled .lib files)
read_lef, read_lef_update # (to read in .LEF files)
set_logic_0_net vss # (set logic 0 and 1 net names)
set_logic_1_net vdd
read_layers_usages # (reads layer utilization table, used by PKS
# to estimate which layers a route will
# hit, and how many times it will change
# layers, along it's length. This plays a
# role in parasitic estimation.)
read_ver # read in Verilog files
do_build_generic # Maps Verilog to "generic"
# technology library
2.) Initialize floorplan (i.e. read in .def file) Do the manual
over-rides of the floorplan done by PKS.
For "early" PKS runs we generally let PKS figure out the block size,
and initialize the floorplan only in terms of:
- standard cell row spacing
- standard cell row orientation (flip or not?)
- I/O to core distance
- aspect ratio
- desired standard cell row utilization
- halo to put around embedded macros
These are all set with "set_floorplan_parameters."
Later in the flow the floorplan for the block becomes more defined,
containing the information listed above, and you want PKS to work
within that floorplan. At this point floorplan initialization is
done by just reading in the floorplan .def file, using "read_def".
3.) Apply timing constraints -- i.e. constrain all the normal stuff you'd
constrain before doing timing-based synthesis:
- define clock(s) and assign them to pins (set_clock,
set_clock_arrival_time)
- define input signal arrival times (set_data_arrival_time)
- define output signal required times (set_data_required_time)
- define output max slew (set_port_capacitance_limit)
- define output capacitive load (set_port_capacitance)
- define input driver characteristics (either set_drive_cell or
set_slew_time + set_port_capacitance_limit).
4.) Pre-Placement Optimization
a) Generic design optimization (do_xform_optimize_generic) - i.e. do
any optimization that is possible prior to mapping the design to
our 0.18 custom in-house library.
b) Map the design to our custom 0.18 Geocast library (do_xform_map)
c) Pre-placement optimization (do_xform_pre_placement_optimize_slack)
This amounts to whatever optimization of the design that can be
done prior to placing it. My understanding of how this works is
that PKS derives a WLM from process layer information (from the
LEF file(s) you read in before), and other information, and uses
that to do initial optimization of the design. The goal here is
to come up with a starting point for placement.
5.) Timing-driven placement (do_place -timing_driven true)
Just the placement of the results of step #4, driven by the timing
constraints of the design.
6.) Post-placement optimization (do_xform_optimize_slack -pks)
The goal here is to get the design to timing closure by iterating on
the placement, netlist structure, etc. PKS also does periodic
congestion analysis on the design during this phase, and makes
adjustments to the placement along those lines as well.
7.) ECO placement to legalize cell placements, fix any timing issues that
result (do_xform_tcorr_eco)
I understand placement at this point has lumped cells into "bins",
and this step basically spreads the cells in any given bin out, snaps
them to standard cell rows, etc. Other commands allow access to each
individual part of this process (do_placement_spread, do_place -eco).
do_xform_tcorr_eco does both of these and a short round of timing
correction to resolve any timing issues (usually small) that result
from the placement spread/legalization.
8.) Export .def, .gcf, and Verilog netlists for use in the downstream
tools (CTGEN, SE). The .def represents the placement of the design
(and additionally has all the information presented in the floorplan
you started with). The GCF file represents all block timing
constraints to SE, and is used by QPOPT and Pearl for timing
analysis.
Steps 4-6 can be performed with one "do_optimize -pks", or done separately
with the following commands:
do_xform_optimize_generic
do_xform_map -hierarchical
do_xform_pre_placement_optimize_slack
do_place -timing_driven true
do_xform_optimize_slack -pks
I prefer this latter approach as it allows an .adb to be written out between
these steps, making experimentation with various switches and pre- and post-
placement optimization strategies faster.
Through CTGEN and Silicon Ensemble
----------------------------------
We then took our design through CTGEN/SE as follows:
1.) Clock tree insertion using CTGEN
CTGEN pretty much uses the output DEF from PKS, and constraints for
the clock tree(s) you're inserting (skew, max_transition, min/max
insertion delay) to come up with a clock tree structure that
[hopefully] meets those constraints, and then places the structure
in the design. In general I found that CTGEN did a good job with
clock tree insertion. Some things I found that gave it a hard time
were:
- small slivers of standard cells between, for instance,
a hard macro and block boundary. CTGEN sometimes had
difficulty balancing skew to synchronous elements placed
in those slivers. In general we try to avoid this by
not creating this situation in the first place. If that
is not possible then some manual definition of the clock
tree structure "using define_structure in the CTGEN
constraint file" can help get better results.
- For high-placement density designs or timing-critical
designs that end up having localized areas w/very high
placement density, CTGEN can sometimes have a hard time
meeting constraints w/o moving standard cells a long way
(to make room for the clock tree). I talk about this
issue and how we worked around it more below.
2.) Import design (with clock tree) into Silicon Ensemble
3.) Detailed scan chain hookup done with SE TROUTE
4.) Timing constraints applied (GCF from PKS)
5.) Do a QPOPT pass to fix PKS timing violations that result from clock
tree insertion and scan chain hookup.
We basically try to rely on QPOPT for as little as possible -
i.e. don't expect it to fix really significant timing problems.
We did use it to fix up transition violations on our scan chains.
(PKS never sees these since the chain ordering is done in SE and
it doesn't see any small transition nor the timing violations that
occur as a result of clock tree insertion. Cells get moved by
some amount and some problems are bound to pop up). On the tapeouts
QPOPT turned out to not be critically necessary, and we generally
shoot for this on all our P&R blocks. Most post-route timing
correlation problems can usually be tracked back to poorly placed
macros or pins or some other thing that is better fixed at the
source (as opposed to relying on QPOPT to fix them).
6.) Timing-driven WROUTE
7.) Hyperextract parasitic extraction, final timing analysis using Pearl.
Of course everything was wrapped up from this point with LVS, DRC,
etc. No significant problems were encountered here.
Post-Route Timing Results
-------------------------
Our post-route timing (based on Hyperextract parasitics) were within 160 ps
of the PKS-estimated timing, so routed timing was within 3% (in the noise in
my opinion). Overconstrainting synthesis relative to the "real" timing
targets can get this back if it's really important. The really cool thing
about all this is that we got this result with one pass through synthesis
and P&R. I've not ever experienced that with a WLM based synthesis/timing-
driven P&R flow (has anybody?). This saved us a ton of time implementing
this chip.
Another very cool thing to note about this PKS flow was that it was not
necessary to do any detailed floorplanning to get to timing closure and a
routable design. This block used to require quite a bit of "micro-
floorplanning" to get timing closure, and it had significant routing
congestion problems. I did no such floorplanning on this chip, other than
preplacing all of its custom blocks.
I feel it important to note some of the things that contributed to the tight
timing correlation we got between PKS and post-route timings. PKS basically
uses a routing layer utilization table and characterization of how often a
route typically changes layers, along with the area and fringe cap
coefficients from the LEF file for each layer to estimate the R and C of a
wire. (If you're using an external vendor's LEF then presumably their
coefficients are based on some real data, and possibly don't need to be
mucked with.) We ran several testcases of various sizes & routing densities
through PKS early on and used SE routing reports to derive the layer
utilization tables. We then used Hyperextract runs on the same blocks to
come up with LEF coefficients for each routing layer. I found this really
helpful in getting tight timing correlation.
Once things were tuned, I found that ~95% of the nets had PKS estimated
capacitance within 10% of Hyperextract cap, and nearly all of the remaining
nets were within 20%. Note that I didn't make any adjustments here for very
short nets, which tended to have much larger error (as expected). While
this correlation effort might sound involved, it's really as simple as
taking the coefficients from a log file from a Hyperextract run, and doing
some simple math on numbers easily gotten from SE routing reports. The real
key is to pick a testcase that has a reasonable routing density, as this
will obviously affect the fringe cap coefficients you end up with in the
LEF. I've done this correlation effort once and not had to change anything
since, and we've pushed quite a few blocks through the tools at this point.
This is a big improvement over having to do old fashioned custom WLM's on a
block-per-block basis.
Lessons Learned
---------------
It's probably also good to note some of the problems we ran into with PKS
and SE, and how were able to work around them.
1.) Ambit/PKS does not directly support inference of master-slave
flops, on which our library is based. What this basically meant
was that one of our clocks was left unconnected after initial
mapping to our standard cell library. This turned out to be
quite easy to workaround, by using a TCL script within the
Ambit shell to hook up the second clock tree after mapping,
and before timing-driven optimization of the design.
2.) Our scan methodology was also not supported by PKS. We don't use
the popular MUX-scan methodology that a lot of people use,
and instead use an LSSD method in which each synchronous element
has separate scan clocks, allowing for synchronous elements
of all types (falling and rising edge flops, latches) to be
put on the same scan chain, and be fully scannable. PKS couldn't
deal with this, so we were left with using the script mentioned
in #1 to hook up the scan clocks post-map, and then use SE's
TROUTE to do the placement-based scan ordering. Overall I was
pretty impressed by the flexibility allowed in the Ambit shell
for doing these sorts of things. Being able to do this allowed
us to basically integrate some of the less-standard parts of
our flow into PKS in a very acceptable way, at the right point
in the design flow.
I should note that PKS v4.x appears to have some additional
ability w/regard to scan support, and for placement-based scan
ordering. I haven't had time yet to evaluate whether or not
it eliminates the need for some the workarounds we've implemented
to deal with these shortcomings in v3.x.
3.) The PKS v3.x timing engine did not degrade slew over the RC of a
net, which caused some problems for long and/or large fanout nets.
The biggest place I've seen this pop up is on long routes to P&R
block output ports that have a fairly high lumped capacitive
load. We worked around this in two ways:
- QPOPT has been able to fix some of these types of problems (if
they can be fixed w/ a simple upsize)
- The placer in PKS can take net-weights, and application of a
high weight to nets that connect to block output ports limits
the amount by which the slew can degrade. One can set weights
on these nets be defining a TCL list of nets and using the
"-net_weight" switch of do_place:
do_place -timing_driven true -net_weight "$output_nets 10"
PKS v4.0 appears to account for this slew degradation, which
eliminates this problem all together. I haven't fully investigated
this but initial trials on 4.0 do appear not to have this problem,
and timing reports do show degraded slew over longer nets.
4.) For high-utilization designs or designs that are *really* tight
on timing, we had problems with local placement utilization being
too high leaving no room left for the clock tree! The end result
was that cells got moved larger distances to make room for clock
tree buffers, which degraded post-route timing results, and in
some cases routing congestion. For placement utilizations up
to 90%, we don't generally see this problem (the chip we taped out
was ~90% placement utilization). We've been able to work up to
the mid-90's by passing some switch options to the placer that are
supposed to leave room for clock tree buffers. PKS 4.0 appears to
have even more knobs that may help in this area, but I haven't had
a chance to try them yet.
5.) Some iteration was required to get a floorplan that placed all
the custom macros in a way that did not result in routing congestion
around those macros -- especially if the macros account for a large
percentage of the area of the chip. I guess I don't really see this
as a shortcoming in any tool as much as a fact of life, though.
Overall I was really impressed with PKS and how it fit into our flow.
Formerly we'd been using Ambit/SE, and PKS fit right into this. In general
database handoff between PKS, CTGEN, and SE was pretty seamless. Especially
helpful was the support I received from Cadence as we were putting our PKS
flow together. I can honestly say it's the best support I've received
from any EDA company to date, in terms of both quality and timeliness.
- Thad McCracken
Geocast Networks Systems, Inc. Beaverton, OR
( ESNUG 361 Item 2 ) --------------------------------------------- [11/16/00]
From: Gregg Lahti <gregg.d.lahti@intel.com>
Subject: Boston SNUG Speaker On Tcl Seeks Help On SolvNet DC-Tcl Script
Hi, John,
We've run into a weird scenario which hopefully someone else has seen or
figured out.
One of our steps in synthesis is to go through and flatten the DW hierarchy.
We have a Tcl procedure that has been translated from a Solvnet solution:
...
# Need to traverse through hierarchy & flatten DW components
redirect $G_CONSOLE(NULL) {set hier_designs [filter [find design *] \
{@is_hierarchical == true}]};
if {$hier_designs != {}} {
foreach_in_collection tmp_design $hier_designs {
redirect $G_OURCONSOLE(NULL) {set cell_list \
[filter [find cell *] {@DesignWare == true} ]};
if {$cell_list != {}} {
foreach_in_collection tmp_cell $cell_list {
echo "#UNGROUP_DW: ungrouping" [get_object_name $tmp_cell] \
"in design" [get_object_name $tmp_design];
ungroup $tmp_cell -flatten -prefix DW_ -simple_names;
}; # end foreach_in_collection
}; # end if
unset cell_list;
}; # end foreach_in_collection
unset tmp_design;
}; # end if
...
The errors occurs when we assign a variable with a list of collection of
cells that we want to ungroup, $cell_list. Once we start ungrouping the
cells, DC starts whining about the modification of the collection:
Current instance is the top-level of design 'cnt2_vlog'.
Information: Added key list '( *SynLib-Eval or DesignWare-Foundation )'
to design 'cnt2_vlog'. (DDB-72)
Information: Iteration for collection _sel18 was terminated because
the collection was modified or deleted. (SEL-012)
Current instance is the top-level of design 'cnt4_vlog'.
Information: Added key list '( *SynLib-Eval or DesignWare-Foundation )'
to design 'cnt4_vlog'. (DDB-72)
Information: Iteration for collection _sel24 was terminated because
the collection was modified or deleted. (SEL-012)
Information: Choosing a test methodology will restrict the optimization
of sequential cells. (UIO-12)
It's annoying, but it seems that most of the time one will modify the
collection or operate on the items in the collection. It seems that
DC shouldn't be complaining about this operation. Anyone else see
this or have opinions on this feature?
- Gregg Lahti
Intel Corp. Chandler, AZ
( ESNUG 361 Item 3 ) --------------------------------------------- [11/16/00]
Subject: ( ESNUG 360 #12 ) Ambit-RTL & Interra Concorde *Loves* Aggregates
> I have a piece of VHDL that represents a problem with the Synopsys DC
> parser and aggregates...
>
> architecture arch1 of top is
>
> signal temp_1, temp_2 : std_logic_vector (1 downto 0);
>
> begin
>
> temp_1 <= (1 downto 0 => a_bit_1);
> temp_2 <= (1 downto 0 => a_bit_2);
>
> output_1 <= (a_vector_1 and temp_1) or
> (a_vector_2 and temp_2);
> output_2 <= (a_vector_1 and (1 downto 0 => a_bit_1)) or
> (a_vector_2 and (1 downto 0 => a_bit_2));
> end arch1;
>
> Both output_1 and output_2 should be equivalent, but they're not! Design
> Compiler and Tuxedo both have problems reading in output_2.
>
> - Mike Dotson
> IBM
From: Ravikumar Surepeddi <rkumar@interra.com>
Hi, John,
Synopsys DC 2000.05 doesn't support VHDL aggregates usage as pointed by Mike
for output_2.
dc_shell trace:
--------------
elaborate top
Error: Can't determine type of aggregate or concat
in routine top line 26 in file '/interra/test/vhdl/aggtest.vhdl'
(HDL-123)
No designs were read
0
current_design top
A brief note on myself: I work for company Interra Inc. (www.interra.com).
Interra has a fast RTL synthesis tool by name Concorde. Concorde can be
used as front-end to formal verification tool or design synthesis tool.
Concorde does support Mike's requirement. The Concorde netlist is given
below for your reference. Concorde netlist:
a_vector_1_INT <= (a_vector_1);
a_vector_2_INT <= (a_vector_2);
a_bit_1_INT <= (a_bit_1);
a_bit_2_INT <= (a_bit_2);
output_1 <= (output_1_INT);
output_2 <= (output_2_INT);
rtlc_I7 : INT_AND2
Port Map (Z=>rtlc_N11(0),in1=>a_vector_1_IN(0),in2=>a_bit_1_INT);
rtlc_I8 : INT_AND2
Port Map (Z=>rtlc_N11(1),in1=>a_vector_1_IN(1),in2=>a_bit_1_INT);
rtlc_I11 : INT_AND2
Port Map (Z=>rtlc_N16(0),in1=>a_vector_2_IN(0),in2=>a_bit_2_INT);
rtlc_I12 : INT_AND2
Port Map (Z=>rtlc_N16(1),in1=>a_vector_2_IN(1),in2=>a_bit_2_INT);
rtlc_I15 : INT_OR2
Port Map (Z=>output_1_INT(0),in1=>rtlc_N11(0),in2=>rtlc_N16(0));
rtlc_I16 : INT_OR2
Port Map (Z=>output_1_INT(1),in1=>rtlc_N11(1),in2=>rtlc_N16(1));
rtlc_I35 : INT_BUF
Port Map (Z=>output_2_INT(1),A=>output_1_INT(1));
rtlc_I36 : INT_BUF
Port Map (Z=>output_2_INT(0),A=>output_1_INT(0));
Please note the netlist representation is with Interra's generic library
here. INT_AND2 corresponds to the VHDL logical operator "and", INT_OR2
corresponds to the VHDL logical operator "or" etc. Also, Please note that
Concorde takes care of parallel output instances correctly. temp_1 and
temp_2 optmized away. The synthesis tool has a -preserve option to preserve
intermediate signals if needed.
- Ravikumar Surepeddi
Interra Inc. San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Paul Graham <pgraham@cadence.com>
John,
Regarding the Design Compiler VHDL Aggregates Parser problem, I'm sure
you'll be happy to know that Ambit BuildGates handles this little test case
just fine. It parses the test case and generates correct logic both in the
current version (v4.0) and in the oldest version I could access (v2.3.12,
from September 1999).
This item caught my eye since I wrote the Ambit VHDL parser. :-)
- Paul Graham
Cadence
( ESNUG 361 Item 4 ) --------------------------------------------- [11/16/00]
Subject: ( ESNUG 360 #17 ) DC-Tcl 'Collections' Is Not Like Tcl 'Lists'
> I thought that this may be useful for people using Tcl as their scripting
> language for DC. Synopsys has a new form of list equivalent in Tcl called
> 'collection'. I assumed that the 'collection' worked similar to 'list'
> with their custom commands, but it did not turn out so. ... I was trying
> to remove a collection item from an collection, but it does not work.
>
> - Rajkumar Kadam
> Quantum Corp.
From: Gregg Lahti <gregg.d.lahti@intel.com>
Hi John,
I used an almost similar example in the paper I presented at Boston SNUG
'00 this year. See http://www.deepchip.com and look for the TOPS files in
"Downloads" to get a copy og my paper called "Tcl: The Good, The Bad,
and The Ugly". In the example:
DCSH method of getting all inputs without any clocks:
in_list = all_inputs() - all_clocks()
Tcl method for the same operation:
set inlist [all_inputs] ;# inlist contains a collection!
foreach_in_collection ic [all_clocks] {
set inlist [remove_from_collection $inlist [get_object_name $ic]]
}
The difference from your AE's example is the use of get_object_name, which
will get the name of the object (or collection, actually). The
remove_from_collection procedure requires the name of the object or the same
object class. In your example, you were trying to remove one class of an
object from a different class of an object. In the example I used above,
the get_object_name procedure works only for single-instance items, so one
could not use get_obect_name on the inlist variable because inlist contains
multiple collections.
One of the issues we found using collections is that they are "linked" to
the design and are not static in nature (more like a filehandle into the
design). For example, if I have a variable set to a collection of ports and
I remove one of the ports in the design, the variable containing the
collections is now invalid and I wouldn't be able to run any timing using
the variable. End result is the variables need a "reallocation" or
basically need to set the variable to the group of collections again before
using them if you've tweaked the design in any significant way. Otherwise,
you get the nasty "collection has been modified or deleted" error.
I agree it would have been nicer to use Tcl lists. However, I can see the
predicament that Synopsys has when the tools have attributes of items that
it needs to keep track of (such as load, input delay, name, and direction
attributes for a port). Using Tcl forces the user to see more of the
under-the-hood operations that DC allowed but it does give the user more
flexibility in terms of object-oriented programming (gasp!) to do synthesis
ops. You could always convert back to lists, although the headache of
managing lists of lists is not worth the effort of learning how to use
collections more effeciently, IMHO.
- Gregg Lahti
Intel Corp. Chandler, AZ
( ESNUG 361 Item 5 ) --------------------------------------------- [11/16/00]
Subject: ( ESNUG 360 #1 ) PhysOpt/Saturn/PKS For Wimps; Real Men Use P&R!
> Many of us Wall Street watchers read ESNUG because we're monitoring the
> adoption of physical synthesis tools. From the many customer tape-out
> stories we've read in ESNUG, it appears to those of us in the financial
> community that Physical Compiler is catching on with designers. With
> Cadence's SE-PKS now released, are designers seeing (or do they
> anticipate) any advantage to using SE-PKS with Physical Compiler as
> compared to using Physical Compiler and SE *without* PKS features? Are
> Physical Compiler users interested in SE having PKS features?
>
> - Garo Toomajanian, Research Analyst
> Dain Rauscher Wessels Boston, MA
From: [ 48% Bush; 48% Gore ]
John, no ID on me.
Tell that Wall street hack that his question is somewhat odd. All the work
done inside PhysOpt relies on SE or Apollo as a last step for final routing.
Synopsys tell us it's furiously working on its own router. This temp
reliance on SE/Apollo will soon disappear. PhysOpt or PKS is an XOR choice
for users, so PKS hooks are useless for PhysOpt users.
- [ 48% Bush; 48% Gore ]
---- ---- ---- ---- ---- ---- ----
From: [ Intel Inside ]
John,
Please keep me anon...
I see a consistent theme w/ timing closure tool selection discussions within
Intel and the rest of the industry. People who are logic designers seem to
love Synopsys's PhysOpt tool. Engineers who live in the physical design
trenches gravitate toward Avanti or Cadence SE. In my experience, anyone
who compares the traditional congestion or net weighting based flows to
PhysOpt/Saturn/PKS will think the later is the greatest thing since sliced
bread. All of these new tools (PhysOpt/Saturn/PKS) work with appropriate
coaxing. Each of them have their own warts and blemishes.
To answer Garo's question - I would argue that more ESNUG readers come
from a logic design background than a physical design background. Hence,
I would expect to hear more cheers regarding Synopsys's tool than those
provided by other vendors. There are not a lot of users out there who
are experts in both the physical and the logical worlds...
Going from my personal experience, I think PhysOpt is weak in solving full
chip integration issues and working with designs that have a lot of custom
hard macros, but from a timing closure issue, it does the job. I feel
the Avanti tools do an excellent job in solving the physical integration
issues and coming to timing closure but are weak in understanding ALL of
the logical constraints the way that a design team intended them to mean.
PKS seems to work in the middle of the group. Does a decent job in both
worlds, but probably not the best choice for just physical or just logic
design.
All three of these tools work. You just need to create a methodology that
fills in the gaps. The funny thing is that most people choose the tool
that works best in their area of expertise and then get stuck closing the
holes in areas where they are more weak. Duh! Well, we engineering types
are not known for having strength in the common sense department - my wife
will vouch for that. I guess it would make sense to do the opposite, but
that goes against human nature...??? (shrug)
Don't expect the vendor to solve methodology issues for you. I have yet to
see one that even makes a decent attempt once the Purchase Order has been
signed. Also, it's really easy to poke holes in the other guy's solution
which is another engineering trait. In the long run, it the engineers that
make stuff work. Meanwhile, I'll just keep plugging along and I don't think
I'll be investing in the EDA world until a "near" nirvana solution hits the
market...
- [ Intel Inside ]
( ESNUG 361 Item 6 ) --------------------------------------------- [11/16/00]
From: Paul Zimmer <pzimmer@cisco.com>
Subject: Warning -- PrimeTime 00.05 "update_timing" MUST HAVE the "-full"
John,
A quick note to other Primetime users. Version 2000.05 has a new option
called "-full" on the update_timing command that you may want to know about.
2000.05 has a new feature where it tries to speed up timing calculations by
being smart about what and when to recalculate. This option *forces*
Primetime to recalculate the timing whether it thinks it needs to or not.
I have found one case (an internal timing endpoint) where the new algorithm
thinks it doesn't need to recalculate, but it does. You can do a standard
"update_timing" until you're blue in the face, and the report will still be
wrong.
Do "update_timing -full" and everything starts working correctly.
- Paul Zimmer
Cisco Systems
( ESNUG 361 Item 7 ) --------------------------------------------- [11/16/00]
Subject: ( ESNUG 360 #4 ) Suns Crap Out -- WSJ, SGI, Linux, HPs, PC Farms
> I was wondering if I could poll the ESNUG community for recent experiences
> regarding the use of HP workstations instead of Sun as a platform for EDA.
>
> The reason I bring this up is that we have had a ridiculous amount of
> trouble with our Sun hardware and software over the last few years, and we
> are at the point of researching alternatives.
>
> Now, before I get a bunch of responses along the vein of "these people
> must not know what they are doing because we have used Sun for X+ years
> and have never had a problem"; I ask the reader to postulate the following
> things:
>
> 1) We also have X+ years of Sun hw/sw experience and started out as Sun
> bigots a few years ago.
>
> 2) Without going into details, we have had an unreasonable amount of
> trouble with our current Sun hw/sw (hardware being big E6000 and E6500
> servers.)
>
> 3) We have explored all reasonable avenues of resolving our problems with
> Sun, paying top dollar for the highest level of support, and even
> replacing all of our hardware in spite of the fact that diagnostics
> did not show errors.
>
> Our top concerns are that we may switch and find ourselves with the same
> set of problems with HP workstations -- that our EDA software may not be
> as stable, or supported as well, or even exist on the HP platform.
>
> (Yes, we've seen the recent news of the Sun memory failure "cover-up".
> Some of our problems may have this root cause, but most do not.)
>
> - Jon Stahl
> Avici Systems, Inc. N. Billerica, MA
From: Scott Evans <scott@sonicsinc.com>
Hi, John,
Here's a URL for the recent article the Wall Street Journal just did on the
problems customers are having with Sun servers.
http://www.zdnet.com/zdnn/stories/news/0,4586,2651406,00.html
I think Jon Stahl will get some small comfort in knowing he's not alone.
- Scott Evans
Sonics Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: [ A Horse With No Name ]
John,
Please don't reveal who I am.
I do chip design for Agilent, which recently spun off from HP. As a result
I have almost no experience using Sun HW/SW. And I am surrounded by HP
bigots. But I am also a Linux user. In some ways I prefer Linux. So you
can take my word any way you want.
Long ago we had lots of trouble with HP HW. It was just flakey. But for
the past 10 years at least I have been impressed that the HPUX platform has
been rock solid. (HP PCs are not worth their price, but you didn't ask
about them.) That continues to today.
With one exception. NFS sucks. Its about 1% of intrinsic speed, on a good
day. We are running HPUX 10, and 11 is out. It's possible that HPUX 11
fixes NFS. I understand that NFS is updated in 11.
Without knowing your design flow, I don't know if all the apps will be
supported. Our flow uses a combination of standard tools and internal
tools. But all the biggies run HPUX.
But be aware that your internal software will take some time to port from
Sun to HPUX. The OSs are different. Both C and shell scripts will run into
glitches. The Unix base they started from had bugs. Sun and HP fixed
different bugs. When you port software you won't notice the bugs that
disappear. But you will definitely notice the new ones. Its no fun. But
on the plus side, after you are done porting, your software will be better
for it.
- [ A Horse With No Name ]
---- ---- ---- ---- ---- ---- ----
From: [ From The Land Of Hello Kitty ]
Hi John,
Pls keep me anonymous. I am working as a designer/CAE/EDA engineer. We
also have the same kind of problems as Jon. SUNs' performance is poor
before UltraSPARC-III, support quality is also poor. Also their description
for E-cache problem was unclear at the the time we got ploblems.
We used to think about buying HPs, but decided not because:
1. HP seems pricy than SUN (at least in Japan).
2. at the time we made purchase this year, SUN was the 1st priority
platform for Cadence. But recently Cadence announced they make HP
as the 1st one.
3. We have bunch of SUNs :-)
4. SUN has much more installed base than HP in general.
So if you have any trouble rather than EDA tools,
you can find many good resources on the Net to solve it by yourself.
Things has been changing so fast.
Since we do not do any big designs, IA/Linux is becoming a good candicate
for HDL designers. ( not for analog/layout designers though ).
By the way, does anybody use Alphas as EDA platform?
- [ From The Land Of Hello Kitty ]
---- ---- ---- ---- ---- ---- ----
From: Tony Laundrie <atl@sgi.com>
John,
We ported Synopsys tools to Linux using SGI systems and the run times are
great. See
http://biz.yahoo.com/bw/001009/ca_synopsy.html
http://www.sgi.com/linux/
On top of the regular Linux OS, SGI provides a ProPack layer of additional
tools to improve reliability and server performance.
- Tony Laundrie
SGI
---- ---- ---- ---- ---- ---- ----
From: Alain Raynaud <alain@tensilica.com>
John,
For a while I've been wrestling with the question: "Should we switch our
simulation jobs to a farm of fast, cheap PCs?" I benchmarked a 1 GHz PC,
fully loaded, running Linux, against one of our Sun servers (400 MHz
UltraSparc). The results? Not what I expected.
For VHDL simulation (using a leading VHDL simulator), the PC was 25%
faster than the Sparc.
For Verilog simulation (again, with a leading Verilog simulator), the PC
and the Sparc had exactly the same performance.
So what is going on here?
I have done other measurements with 600 MHz PCs, and the results scale as
you would expect. Keep in mind that I'm testing our RTL design only, so it
may not be your typical design. But that's what we care about. Cache size
and memory subsystem performance may matter more than pure MHz numbers.
In the interest of full disclosure, there is one job where the PC was 40%
faster than the Sparc. That confused me even more. (Also this benchmark
gave me the opportunity to compare simulation speeds for the exact same
design written in VHDL and Verilog. While I can't publish the detailed
results, I can confirm that VHDL simulation is slower than Verilog.)
- Alain Raynaud
Tensilica, Inc. Santa Clara, CA
( ESNUG 361 Item 8 ) --------------------------------------------- [11/16/00]
Subject: ( ESNUG 360 #13 ) A User Compares Synopsys SystemC vs. CynLib
> Our group has been evaluating SystemC and CynApps and we plan to embrace
> one of them. For that, it is very important to get a comparison chart
> between these two tools/languages which are built around the same concept.
>
> Can anybody point me to some website or give me some pointers regarding
> why one is better than the other? I am looking at criteria like:
>
> * licensing mode
> * generation of waveforms
> * which is more popular and more used in industry and universities
> * which has more 3rd party vendor and tool support
> * simplicity of use, resemblance to Verilog
> * do we have Verilog "to" and "from" translators
> * most important, how is the PLI interface architected and how it works
>
> Thank you for your help.
>
> - Satyajit Chowdhury
> Cisco Systems San Jose, CA
From: [ No Names, Please ]
Hi John,
Attached is a text file which is my compiled report comparing SystemC and
CynApps. You can publish this is you remove all instances of any employee
name and of my company's name.
- [ No Names, Please ]
1. Licensing mode.
~~~~~~~~~~~~~~~~~~
SystemC: The license, which is free of any charges, allows access to the
source code for SystemC class libraries and the reference
simulation kernel. This is pretty unrestricted for internal use
in your organization. There is a commercial use attachment if
you wish to re-sell/re-distibute the code outside your company.
There have been some issues you may have heard about in the media
concerning the license. These issues were mainly of concern to
EDA vendors and resolving those issues (basically by ensuring
key decisions were in the hands of the steering group rather than
any one company) was key to getting Cadence to come on board
June 2000.
Something that has all the advantages of Open Source, but also
gives EDA/IP companies better ability to offer proprietary
value-added innovation on top of SystemC.
CynApps: Essentially the same as the Mozilla Public License, which is
listed as a "Free License" according to the GNU project. See
http://www.gnu.org/philosophy/license-list.html for details.
2. Reliability : open bugs, customer complaints.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: None I know of. Probably people submit the fixes if they find
any and that is rolled out in the next version. For example,
right now, a discussion is going on in the forum regarding the
format in which SystemC generates VCD files being incompatible
with Verilog generation.
CynApps: No known problems.
3. Learning curve - time spent to come up to speed with the tool.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: With basic C and C++ knowledge in addition to HW knowledge, it
takes about a week of reading before starting to write code.
CynApps: Free version has roughly the same learning curve as SystemC.
Cynapps offers Cyn++, which allows one to write Verilog-like
Cyn++ code which is converted into C++.
4. Number of associated partners, companies backing the tool.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: The direction and control of SystemC is now shared between all
SystemC users and the thirteen companies who form the Steering
Group. These companies are: ARM, Cadence, CoWare, Ericsson,
Fujitsu, Infineon, Lucent, Motorola, NEC, Sony, Synopsys, TI,
and STMicroelectronics.
CynApps: Cadence, Chronology, and TransModeling have all announced
Cynlib-based tools.
5. Documentation, "help"/"man" feature, user-friendliness.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: The manual is well-written and it is updated with every revision.
They are supposed to release an LRM late 2000.
CynApps: Documentation gives good description of how Cynlib works, but has
not been updated for the latest version (documentation is rev
1.1, latest Cynlib version 1.2). A separate LRM describes the
Cynlib language.
6. Technical support, freq of user newsgroup & mailing lists letters.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: SystemC has a open messageboard for the user community to share
ideas and support. It's the only C++ hardware language that has
one. Traffic in the mailing list is considerable. About 5-6
mails a day.
CynApps: Cynapps has given very good pre-sales support, and I believe
they would continue to give good support, however they are still
a single-product company. Traffic on mailing list near-zero.
7. University interest and projects.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Academic interest in SystemC is very strong. At least 20
universities doing research projects using SystemC. Two are UC
Irvine (Prof. Rajesh Gupta) and U. Tuebingen (Prof. Rosenstiel)
CynApps: Cynapps has announced a program to provide Cynlib to
universities, along with training, but did not name any
universities participating.
8. White papers, articles, general interest from industry, demos.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: 3 new companies joined the steering group in June 2000: Cadence,
Motorola and NEC. SystemC user groups in China, Japan, Sweden.
SystemC training and demos from Synopsys, Willamette HDL.
CynApps: Press releases for three companies listed above.
9. 3rd party vendors, debugging facilities.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Last DAC (in June) 16 companies in the areas of EDA, IP and
Training announced SystemC support for over 20 products.
CynApps: Partnerships announced with Chronology, Cadence, and
TransModeling.
10. Closeness to Verilog, simplicity of use.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Code structure is very similar to Verilog although syntax
is different.
CynApps: Code structure is very similar to Verilog although syntax
is different.
11. Ease of cosimulation with Verilog, plain C - PLI architecture.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Several APIs have been developed for different situations:
- Fast transaction oriented IF for emulation - IKOS
- VCS PLI/Scirocco/MTI cosimulation with SystemC - Synopsys
- Multi-simulator cosimulation - Transmodeling
- Multi-simulator SystemC model generation tools - TBA
CynApps: Cynlib PLI interface is an add-on product, using a simple
function-call for each signal to be connected. Also have
home-grown PLI interface for no additional $$$, works with VCS.
12. Platform support ( Windows, Linux, Solaris )
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Runs in all three.
CynApps: Runs in Solaris and Linux, probably not in Windows.
13. Simulation time, swap memory usage, handling of big designs.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Yet to do any performance measurement.
CynApps: Performance appears to be equivalent to Verilog at same level of
detail. No scalability measures, although RTP may be able to
give input into large designs and scalability.
14. Translators to and from Verilog code.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Several are available including capabilities within Synopsys
CoCentric SystemC Compiler, Frontier Design's AR/T Designer as
part of the synthesis capabilities. Also available is Tension
Technologies VTOC for going from Verilog to C/SystemC.
CynApps: Verilog to CynLib translators available.
CynLib to Verilog translator in development.
15. Waveform generation and related flexibility.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Generates VCD files. Supported by VeriTools, TransModeling,
Blue Pacific, VirSim, Innoveda, plus other commercial packages.
Our current version of virsim 4.0.1 cannot open a dump file
generated by SystemC simulator. But SignalScan can open it.
The reason is virsim expects a VCD+ format file ( or VPD file )
whereas SystemC generates VCD file.
CynApps: Cynlib presently generates VCD files, support for other binary
formats promised. Support for VPD unlikely since virsim is
owned by Synopsys.
For both tools, virsim can open a VCD file if you run vcd2vpd on it first.
16. Roadmap for the tool.
~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Define a C++ class library and simulation kernel for:
* HW modeling: clocks, concurrency, process, signal, datatypes
* SW modeling: interrupts
* systems modeling: abstract communication.
Time frame : July 2000 (validated v1.1 with SystemC v1.1 LRM)
Late 2000 (v1.2 with hierarchical links and
communication refinement)
2001 (v2.0+ with performance models and
RTOS integration)
Even later (v3.x analog/mixed signal support)
CynApps: Simulation language is essentially complete. Further plans are
for commercial tool releases for the Cynlib language.
Verilog-to-C translation tool has been released and used by RTP.
C-to-Verilog "synthesis" tool is in production.
17. Popularity - number of software downloads.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: Total downloads of SystemC stands at over 14,000 for all versions
and this is from over 5,500 registered licensees from over 500
companies from Oct 99 through Aug 2000. Alignment with VSIA SLD
Datatypes.
CynApps: Downloads do not translate well to number of actual users, and
CynApps does not track number of downloads.
18. Range of abstraction.
~~~~~~~~~~~~~~~~~~~~~~~~~
SystemC: A language that offers a lot more abstration than basic HDLs.
- Abstract Communications Protocols - you can model blocks
talking to one another, without specifying each and every
signal / connection, then easily refine the protocol and
method of communication.
- Arbitrary width datatypes - not locked to just 32, 64 bit
boundaries.
- Fixed point datatypes - very important for DSP applications
- supports 4 state logic in v1.1 (0,1,x,z)
CynApps: Cynapps presently supports 2 levels of logic, and support for
3 levels of logic has been promised in the next release (0, 1,
and Z). Also all of the above except 4 state logic.
( ESNUG 361 Networking Section ) --------------------------------- [11/16/00]
Richardson, TX -- pre-IPO startup Netrake Corporation seeks Processor Design
and Verification engineers. No headhunters, please. "mikes@netrake.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
|
|
