( ESNUG 397 Item 6 ) --------------------------------------------- [07/24/02]
Subject: ( ESNUG 396 #2 ) Two Users Defend Their Monterey Dolphin Tape-outs
> I'm an engineer that uses Aristo IC-Wizard of Monterey. With Dolphin
>
> 1. There are currently, 0 tapeouts (!) were done using Dolphin only.
> The tapeouts in Infineon and in Zoran use Silicon Ensamble as a
> router. In addition, both tapeouts were done using Cadence tools
> for clock.
>
> 2. All 3 "tapeout" uses a huge R&D support by Monterey.
>
> 3. The tool itself is extremely slow, and require a lot of special
> tricks and bypasses.
>
> 4. There is no real connection between Dolphin timing engine and Aristo
> IC-Wizard. We have heard a lot promises, with 0 results.
>
> I do not know where Mr. Goering found 30 tapeouts. If it is so, why is it
> so confidential?? It seems like someone's trying to fool ESNUG readers.
>
> - [ The Truth Is Out There ]
From: Hartmut Hiller <hartmut.hiller@infineon.com>
Dear Mr. Cooley,
Off and on I read your articles (often helpful and interesting stuff to do
my job). This time I found something I have to respond to because it is
pretty untrue. I am the the responsible development director of the
department that did the 2 tapeouts with Monterey most probably refered to
above. All I can state to the "e-mail" above is:
1. Signal routing and clocktree insertion was completely done
using Monterey tools. Layout verification (DRC, LVS, ...)
with Cadence tools (which are mandatory for sign off at Infineon).
2. We were very pleased with the Monterey support (also from R&D)
which was normal from my point of view as a customer.
I have no clue where the "anonymous engineer that uses Aristo IC-Wizard" got
his information from.
- Hartmut Hiller
Infineon Germany
---- ---- ---- ---- ---- ---- ----
From: Nir Sever <nir@zoran.co.il>
Hi John,
About IC Wizard, I don't have any recent experience with it. However, my
understanding is that the new IC Wizard version 2.3 is actually using the
Sonar timing engine.
About routing, I agree, the Montery tool is slow. We didn't use Dolphin on
our first tape-out. Does this mean that Monterey didn't have a tape-out?
In this case Synopsys PhysOpt has 0 tape outs, because they also didn't do
routing. I think the consensus is that for physical synthesis what counts
is a routable placement that meets timing with a clock tree included.
The comment about the clock tree wasn't true for us. We did use the Dolphin
clock tree successfully, and it is actually one of the things we were very
impressed with. Dolphin performance (except for the router) was acceptable,
and because it is multi-threaded, is scalable. Frankly, if the results are
good, I don't mind if it took few hours more to achieve that. Don't forget
that Dolphin does more than other tools. It does placement and timing and
clock tree and x-talk and scan chains all in parallel.
About R&D support -- well, Monterey did give us good support. The tool is
new, no question about it, and we had very short time to learn. However we
did most of the work ourselves. I'm happy to say that on the second
tape-out, we got only one hotfix which is the only one since the official
release of Monerey 2.1.
Here are the details of my March 2002 Monterey tape-out.
Our design was 1 M gates, TSMC 0.18 um. There were many clock domains,
extensive clock gating, and the main clock ran at 135 MHz. The design was
hierarchical, with lots of hard macros, and we used an abutment floorplan.
Monterey Is A *Different* Type Of Flow
--------------------------------------
The Monterey flow is *fundamentally* different than what we were used to.
Instead of the traditional step-by-step stages approach in which you do
1.) placement, 2.) placement optimization, 3.) timing optimization,
4.) clock tree insertion, 5.) propagated clock timing optimization,
6.) power routing, 7.) detail routing
We now had a single tool that does *all* of the above up to global routing
in parallel in *one* stage, and detail routing as its last stage. We had to
adapt our flow accordingly.
The main stages of our Monterey flow were:
Init: Read the libraries, netlist and constraints and set the knobs.
Build the power grid.
Sonar: Run the entire optimization (physical synthesis placement,
congestion, clock tree, scan chain optimization) up to the last
square level, a level at which the timing can be determined
with high accuracy.
Place: Complete the run till detail placement and global routing.
Route: Detail routing while fixing timing and cross talk violations.
Step 0: Files Needed For Dolphin
--------------------------------
Before we started using Dolphin, we needed to prepare our library and design
files. For libraries you need to load two types of files:
1. Physical libraries: These are called MTF files (Monterey Technology
File) and are generated by the MTC (Monterey Technology Compiler) tool.
MTC has two functions. Creating the extraction coefficients file by
running QuickCap, and modeling the cells for the P&R from either LEF
or GDS. You load the MTF files into Dolphin with the read_mtf command.
2. Synopsys libraries: You can load min & max libraries at the same time.
Dolphin reads .lib files directly. No need for any translation. The
only thing to watch here is that if you want to use the scan chain
reordering feature, the test_cell feature must exist on *all* the scan
flops. Use the read_slf command to read the Synopsys libraries, and
set_timing_libraries to specify your libraries for min-max analysis.
The design files you need are:
1. Netlist in Verilog format
2. Constraints is TCL format - Directly out of PrimeTime
3. A floorplan in DEF format
In our flow, we decided to break the constraints to two parts: All the clock
related constraints as well as the clock tree commands are in one file, and
all the rest of the constraints are in the other one. Since the clocks file
contains more information than what PrimeTime needs, it is convenient to
keep it separate, while all the other constraints are directly from
PrimeTime.
We also maintain two more files called insertions and ignored_ports. I'll
explain about these later.
Building The Clocks
-------------------
The first issue we had to deal with was defining our clock gating scheme.
We use gated clocks extensively to reduce power. Our experience with
Cadence CTgen was that clock tree synthesis had problems creating a good
clock tree when there's gated clocks.
In Dolphin we had to do two things in order to build a clock tree:
1. Define the clocks for the timing engine. Here we used the standard
Synopsys PrimeTime commands create_clock, create_generated_clock,
set_clock_uncertainty and set_clock_latency.
2. Define the physical constraints for the clock tree using the
set_clock_tree command.
We were happy to see that Dolphin produced a high quality clock tree,
although the clock skew is somewhat higher than what we would like to see.
This is also where we found the first major bug. set_clock_latency would
define the latency to the flops, but also to the clock qualifiers (which
we call gqual). This is wrong, since the clock qualifiers should have less
latency than the flops. We implemented a TCL workaround, and later this
was fixed in Dolphin. You can now define a different set_clock_latency on
the clk input pin of the gqual.
Dolphin's clock tree engine has abilities not often seen in other tools:
- balance_interclock_skew: Automatically balances the insertion delays
of different clock trees. In the past I used to take a two passes
approach: Run all clock trees with no insertion delay limit, find the
largest insertion delay of all, and use this number to constrain all
the clock trees. This feature makes it much easier.
- useful_skew_settings: Turn on useful skew during timing optimization.
You can specify the maximum skew allowed for fixing timing.
- set_clock_leaf_insertion_delay: This command sets an insertion delay on
a clock output pin. It is useful if you have an embedded block with
clock tree already built in, or if this is a hierarchical design and
you want to create hierarchical clock tree.
A typical clocks file will look like this:
# Define clocks
create_clock -name clk -period 6.9 \
-waveform [list 0 3.45] [get_pins pll/clk]
create_generated_clock -name clkdiv7 -source [get_clocks clk] \
-divide_by 7 [get_pins igqual/q_clk]
# Define clock uncertainty
set_clock_uncertainty 0.5 [all_clocks] -setup
# Define clock insertion
set_clock_latency $clkInsertionDelay [all_clocks]
set_clock_latency $clkLeafInsertionDelay [get_pins iqual/clk]
# Define clock tree
set_clock_tree -source_pin [get_pins pll/clk] \
-name clk \
-max_skew $clkMaxSkew \
-max_transition $clkMaxTransition \
-max_fanout $clkMaxFanout \
-buffer_list $clkBufList \
-inverter_list $clkInvList
# Define generated clock trees
set_clock_tree -source_pin [get_pins iqual/q_clk] \
-name clkdiv7 \
-max_skew $clkMaxSkew \
-max_transition $clkMaxTransition \
-max_fanout $clkMaxFanout \
-buffer_list $clkBufList \
-inverter_list $clkInvList
# Balance skew between clocks (if you have more than one
# real (not generated) clock)
balance_interclock_skew \
-source_pins [list [get_pins pll/clk pll/int_vidclk] ] \
-max_skew $clkMaxSkew
# Use useful skew
useful_skew_settings -synthesis on -set_max_skew [expr 2*$clkMaxSkew]
# Balance clk output pins
set_clock_leaf_insertion_delay -pin clk_cpu -max_rise 2.6 \
-max_fall 2.6 -min_rise 1.9 -min_fall 1.9
You might have noticed that my TCL file above contains few variables such
as clkInsertionDelay, clkMaxSkew, etc. We decided to make our scripts as
general as possible, and use variables to set the values specific to
certain blocks.
Constraints
-----------
We found out that a good set of constraints is extremely important. Dolphin
is sensitive to over constrainting. Most important is not to have your I/O
pins over constrained, because this will have a significant impact on your
results. One enhancement request that we had to Monterey is to support
group_path to separate the optimization of the I/O pins from the clock group.
Today group_path is supported only for reporting.
Some more constraint issues to watch:
- Never put set_input_delay on clock input pins or set_output_delay
on clock output pins.
- Large set_load on a clock output pin will produce larger clock skew.
- Don't put any set_dont_touch or a pre-placed cell (which the tool
consider as a set_dont_touch) on your high fanout nets (clocks, reset,
scan enable, etc.). This affects the clock & buffer tree algorithms.
Another thing we did was modify the timing on the I/O pins to include the
predicted insertion delay. In our methodology, the logic designers
synthesize with ideal clock, arriving at time 0. In order to model the
insertion delay:
We predict the insertion delay for each clock, and record this number
in the insertions file. If there is any input not affected by clock
insertion (such as signals coming from outside the chip, or from the
PLL), record these in the ignore_ports file. Now, we run a script that's
based on these two files that will modify the set_input_delay and
set_output_delay constraints. We also model this insertion with the
set_clock_latency command.
When the clock tree is built, Dolphin automatically switches to propagated
clock mode, and set_clock_latency is replaced by the real clock insertion.
Step 1: Our Init Script
-----------------------
Our initialization script was very complex. All the preparation for running
Dolphin is done here. Below is our current script. (Some parts containing
specific Zoran IP were removed.)
# Incorporate block specific design parameters (passed through variables)
source cmds/design_vars.tcl
# Include the common tcl files - include procedures and some
# global Dolphin parameters
source ${montereyCmdsDir}/strategies.tcl
source ${montereyCmdsDir}/util.tcl
source ${montereyCmdsDir}/defutil.tcl
# Read the project libraries
source ${projectLoaderFile}
set_timing_library -report > reports/${design}.init.libraries.rpt
report_operating_conditions > reports/${design}.init.op_cond.rpt
# Read the design
read_netlist -verilog \
-top_module ${design} \
./inputs/${design}.wire
# Define clocks and clock trees
source ./inputs/${design}.clocks.tcl
# Read constraints
source ./inputs/${design}.ptsh
# Default global parameters
set_max_transition 2.0
set_max_pin_fanout 20
# Define scan optimization. Automatically define chains if this file exists.
set scanChainsRead 0
if [file exists ./inputs/${design}.scan.tcl] {
source ./inputs/${design}.scan.tcl
set scanChainsRead 1
}
# Define Power Nets
if {[info exists powerNet]} {
power_net -default ${powerNet}
} else {
power_net -default vdd!
}
if {[info exists groundNet]} {
ground_net -default ${groundNet}
} else {
ground_net -default gnd!
}
# Floorplanning
# Read Floorplan DEF file
read_def -read_rows -power_routing \
./inputs/${design}.def
# Use filler cell
if {[info exists insertFillerCells] && ${insertFillerCells}} {
if {![info exists fillerCellsList]} {
set fillerCellsList {feedth feedth3 feedth9}
}
use_fillercell -lefcells ${fillerCellsList}
}
# Run floorplan based checkers
# The checkers names should speak for themselves.
if {![info exists runCheckers] || ${runCheckers}} {
set error 0
set numUnplacedCells \
[reportUnplacedCells reports/${design}.init.unplaced_cells.rpt]
if {${numUnplacedCells} > 0} {
puts "Error: found unplaced mega cells."
puts "Please check reports/${design}.init.unplaced_cells.rpt"
set error 1
}
set numUnplacedPorts \
[reportUnplacedPorts reports/${design}.init.unplaced_ports.rpt]
if {${numUnplacedPorts} > 0} {
puts "Error: found unplaced io ports."
puts "Please check reports/${design}.init.unplaced_ports.rpt"
set error 1
}
if {${error}} {
puts "ERROR ERROR ERROR ERROR !!! Exiting"
exit 1
}
}
if {${powerRouting} == "init"} {
set_proute_rail -nets "gnd!" "vdd!" -hor_layer M1
if {${powerRoutingKeepOut} == "on"} {
# Generate the keepouts for routing
makePowerRailsKeepOut inputs/${design}.def inputs/${design}.rows
}
# Run the power route
power_route
}
# Buffer the Output ports (later)
if {[info exists ioBufferSwitch] && ${ioBufferSwitch} == "on"} {
if {![info exists ioBufferList]} {
set ioBufferList {buffda buffd7 buffd1}
}
buffer_ports -ports [all_outputs] -cells [get_lib_cells ${ioBufferList}]
}
# Save the design and parameters
write_checkpoint -name init
# Generate initial timing reports
# Zero WL
update_timing -no_interconnect
write_script reports/${design}.init.constrains.tcl
# reports
report_constraint \
-all_violators > reports/${design}.init.report_constraint.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type max > reports/${design}.init.max.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type min > reports/${design}.init.min.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type max -from [all_inputs] \
-to [all_outputs] > reports/${design}.init.snake.rpt
reportSlopeViolations reports/${design}.init.slope.rpt
# Goodbye
exit
Dolphin Strategies
------------------
One of the nice things in Dolphin is the idea of a strategy. This is a
collection of variables or knobs used to control the flow and the effort
levels of the different optimization stages. Dolphin has GUI that walks
you through those knobs, and in the end you can dump a strategy. Later
you can just set this strategy as you current one. We have found that
two different strategies covered all our blocks pretty well.
Power Routing
-------------
In most other P&R tool I've used before, the row power routing (for example
Sroute followpin in Silicon Ensemble) is done after detail placement. In
Dolphin you do it before, so the placement can consider the added wires and
stacked vias while doing congestion optimization.
Checkers
--------
After we loaded all the library and design files, we ran various checkers.
These are TCL routines we wrote to flag unwanted situations in the design,
and to collect information. For example, we look for flops without resets,
non-driven pins, floating tri-state busses, unplaced macro cells and pins,
etc.
Zero Wire Load Timing
---------------------
Another idea I would like to point out is zero wire load timing reports.
We used them to flag non-realistic constraints or constraint errors. You
want to make sure that with zero wire load, all your slacks are positive.
Any negative slack is a potential constraint problem.
Step 2: Running Sonar
---------------------
We are now ready to run Sonar. Sonar gets the design to a level where the
timing can be predicted with good accuracy. This is the virtual prototyping
part of Dolphin. In the early releases of Dolphin, the correlation between
Sonar and the final results weren't so good. This had since been improved
significantly, and Sonar reports are very well correlated to the final
timing reports. We find them to be slightly pessimistic, which we think
is good for a virtual prototyping methodology.
One important thing I'd like to emphasize is that Dolphin and Sonar aren't
two different tools. As you can see in the script below, Sonar is actually
a command within Dolphin. There is only one binary we use which is the
Dolphin binary. While in Sonar, you can do manual optimization stages to
further optimize your design. Here you see one example. We found out that
running size_design after Sonar level is reached helps solve our remaining
slope violations.
Here is our Sonar script:
# Incorporate block specific design parameters (passed through variables)
source cmds/design_vars.tcl
# Include the common tcl files - include procedures and some global
# Dolphin parameters
source ${montereyCmdsDir}/strategies.tcl
source ${montereyCmdsDir}/util.tcl
source ${montereyCmdsDir}/defutil.tcl
# Read the checkpoint saved in the Init run
read_checkpoint -ignore_validation_errors -name init
# Always update timing after reading a checkpoint ...
update_timing
# Load sonar tool
load_sonar
load_expert
# Run sonar
sonar
# As usual - make sure timing is up to date
update_timing
# Try to fix the slope violators
reportSlopeViolations reports/${design}.sonar.pre.slope.rpt
size_design -select DESIGN_RULE_VIOLATOR -cost FIX_SLOPE_VIOL
# Save the result of Sonar in a checkpoint
write_checkpoint -name sonar
# As usual - make sure timing is up to date
update_timing
# Write a design quality measures report
write_sonar_report reports/${design}.sonar.rpt
# Generate several reports
report_constraint \
-all_violators > reports/${design}.sonar.report_constraint.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type max > reports/${design}.sonar.max.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type min > reports/${design}.sonar.min.rpt
reportSlopeViolations reports/${design}.sonar.slope.rpt
reportUtilization inputs/${design}.def \
reports/${design}.sonar.utilization.rpt
# Save the results - DEF, Verilog Netlist, Spef
write_def -convert_factor 2000 results/${design}.sonar.def
write_netlist -flat -verilog results/${design}.sonar.v
write_parasitics -spef results/${design}.sonar.spef
# Goodbye
exit
Step 3: Place
-------------
After we were satisfied with the timing results we have in Sonar, we did the
detailed placement and global routing. Sonar usually take less than half of
the total Dolphin run time, but we have seen cases in which Sonar run times
are much longer. (This might be related to over constrained I/O pins.) One
thing I would like to explain here is about the clock tree. Our clock trees
are defined in the very beginning. While in Sonar, Dolphin knows about the
clock trees and starts building them, so the area taken by the clock buffers
& routing is already accounted for. However, in Sonar, the clock insertion
isn't yet very accurate, so the timing reports are still using ideal clock
with our specified latency. Before running the final placement we set the
propagated clocks flag. When this flag is set, Dolphin will automatically
switch to propagated clock mode when the clock insertion delay becomes
accurate. Below is our place script. Here too I removed some portions with
Zoran specific IP.
# Incorporate block specific design parameters (passed through variables)
source cmds/design_vars.tcl
# Include the common tcl files - include procedures and some global
# Dolphin parameters
source ${montereyCmdsDir}/strategies.tcl
source ${montereyCmdsDir}/util.tcl
source ${montereyCmdsDir}/defutil.tcl
# Read the checkpoint saved in the Sonar run
read_checkpoint -ignore_validation_errors -name sonar
# Tell Dolphin to use propagated clock if the run is with propagated clocks
if {${propagated}} {
set_propagated_clock [all_clocks]
lo_settings -propagated_mode_optimization on
}
# Always update timing after reading a checkpoint ...
update_timing
# Run detail placement
run
# Save the result of Place in a checkpoint
write_checkpoint -name place
# As usual - make sure timing is up to date
update_timing
# Write a design quality measures report
write_report reports/${design}.place.rpt
# Generate several reports
report_constraint \
-all_violators > reports/${design}.place.report_constraint.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type max > reports/${design}.place.max.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type min > reports/${design}.place.min.rpt
reportSlopeViolations reports/${design}.place.slope.rpt
reportClockTree reports/${design}.place.clktree.rpt
skew_dump -file reports/${design}.place.skew.rpt
update_timing
report_clock_tree -text reports/${design}.place.clock.rpt
report_clock_tree -timing \
-text reports/${design}.place.clock_timing.rpt
reportUtilization inputs/${design}.def \
reports/${design}.place.utilization.rpt
# Save the results - DEF, Verilog Netlist, Spef
write_def -convert_factor 2000 results/${design}.place.def
write_lef results/${design}.place.lef
write_netlist -flat -verilog results/${design}.place.v
write_parasitics -spef results/${design}.place.spef
# Goodbye
exit
Step 4: Route
-------------
As I said before, on our first tape out, we decided to take the Dolphin
placement results into Cadence's Silicon Ensemble for routing in order
to save the time and effort required to qualify the Monterey router.
Since then, we have qualified their router and the script below is how
we use it today. One of the key issues we are having with the Monterey
router is its run time, which is longer than Silicon Ensemble on the
same design. We have been told that run time would improve on the next
release. We have seen few cases where Dolphin leaves small pieces of
metal related to its automatic same net spacing fixing (notch fill).
Another bug was related to minimum area and end of line rule violation
on block pins. This was solved by writing a small TCL script to put keep
out regions around them. Other than that I can say that the Monterey
router has pretty advanced features such as shape base routing, antenna
fixing with metal hopping and diode insertion, support for asymmetric
via overhang (end of line rules different in horizontal and vertical)
and cross talk avoidance. Below is our route script:
# Incorporate block specific design parameters (passed through variables)
source cmds/design_vars.tcl
# Include the common tcl files - include procedures and
# some global Dolphin parameters
source ${montereyCmdsDir}/strategies.tcl
source ${montereyCmdsDir}/util.tcl
source ${montereyCmdsDir}/defutil.tcl
# Read the checkpoint saved in the Place run
read_checkpoint -ignore_validation_errors -name place
# Always update timing after reading a checkpoint ...
update_timing
# Routing setting
settings -use_global_grid on
# Detailed routing
# Pin keep outs to solve MIN_AREA and EOL DRC violations
createPinKeepOut 0.84 5
droute_settings -antenna fix
droute_settings -global_track_assignment on
droute_settings -chkpt post_second_phase on
droute_settings -chkpt post_clean_up on
droute_settings -chkpt antenna
antenna_settings -single_layer on
antenna_settings -accumulate_layer off
antenna_settings -conservative_accumulate_layer off
antenna_settings -gate_share_charge on
antenna_settings -sidewall on
antenna_settings -toparea off
antenna_settings -unlimited_protection off
antenna_settings -diodeCell adiode
antenna_settings -diodePin i
# Route
detail_route
update_drcs
update_timing
get_nets -of [all_nets] \
-filter {!is_complete} > reports/${design}.route.unrouted.rpt
# Save the result of Routing in a checkpoint
update_timing
write_checkpoint -name route
# As usual - make sure timing is up to date
update_timing
# Write a design quality measures report
write_report reports/${design}.route.rpt
# Generate several reports
report_constraint \
-all_violators > reports/${design}.route.report_constraint.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type max > reports/${design}.route.max.rpt
report_timing -max_paths 100 -nworst 1 \
-delay_type min > reports/${design}.route.min.rpt
report_scan reports/${design}.route.scan.rpt
reportSlopeViolations reports/${design}.route.slope.rpt
reportClockTree reports/${design}.route.clktree.rpt
skew_dump -file reports/${design}.route.skew.rpt
update_timing
report_clock_tree -text reports/${design}.route.clock.rpt
report_clock_tree -timing \
-text reports/${design}.route.timing_clock.rpt
# Save the results - DEF, Verilog Netlist, Spef
write_def -convert_factor 2000 results/${design}.route.def
write_netlist -flat -verilog results/${design}.route.v
write_netlist -flat -use_pin_name -spice results/${design}.route.cdl
write_parasitics -spef results/${design}.route.spef
write_gds2 -io_text on \
-layer_file ${processLibDir}/technology/tsmc18_5m.dolphin.map \
results/${design}.route.gds
# Goodbye
exit
Timing Correlation & Tech Support
---------------------------------
We are constantly comparing Dolphin timing reports to those produced by
PrimeTime. Given the same DSPF file produced by Dolphin, we are seeing
almost identical results. We also compared the extraction results to our
sign off extractor (Arcadia), and we are seeing excellent correlation.
The only place we have some miscorrelation is when we run transistor level
PathMill on the design. This is most likely related to the quality of the
library characterization more than anything else.
One thing that we find slightly confusing is the format of the timing
reports. Dolphin timing reports are in the same format as PrimeTime with
one exception. While in PrimeTime the timing is reported on the output pin
of a cell. In Dolphin it is on the input pin.
For support, Monterey has been very responsive. They listen to our requests
and suggestions. I hope they'll keep this attitude even when they'll become
a bigger company with more customers.
- Nir Sever
Zoran Israel
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,063 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.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
|
|
