Editor's Note: Yay! With Genedax permanently shutting its doors this
week, I've finally found at the last minute a new home for DeepChip.com,
the ESNUG Archive Site. I'm not allowed to say who is now hosting
DeepChip because they want to do a press annoucement about it in a few
weeks. Hallelujah! -- this homelessness headache is finally over! Yes!
- John Cooley
the ESNUG guy
( ESNUG 350 Subjects ) ------------------------------------------- [4/27/00]
Item 1 : Persistant Rumors That Cadence Or Mentor Will Buy Synplicity EDA
Item 2 : Two PhysOpt Scripts To Hand Place Specific Cells Near Each Other
Item 3 : Scan Test Implications Of Clock Tree Synthesis Tools Like Ultima
Item 4 : Arranging Intentional PDEF/TCL Placement Obstructions in PhysOpt
Item 5 : Six Headaches If You're Switching From ModelSim To Cadence NC 2.1
Item 6 : How Can I Trick DC Into Synthesizing Fewer, Bigger, Richer Cells?
Item 7 : LVS with Cadence Diva And Running Dracula DRC In Standalone Mode
Item 8 : Doing Synopsys Scan Insertion Across Two Different Clock Domains
Item 9 : Exorcist Lady Questions SNUG'00 Hierarchical Vs. Flat Survey Data
Item 10 : Why Is There No On-line Synopsys Behavioral Compiler Tutorial?
Item 11 : A Review Of The Recent Verisity (Specman) User's Group Meeting
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 350 Item 1 ) --------------------------------------------- [4/27/00]
Subject: Persistant Rumors That Cadence Or Mentor Will Buy Synplicity EDA
> I heard that Synplicity is for sale and will not IPO. Who do you think
> will buy them, Cadence???
>
> - anon
From: Rick Filipkiewicz <rick@algor.co.uk>
What if it's Mentor ?
- Rick Filipkiewicz
Algorithmics Ltd. UK
---- ---- ---- ---- ---- ---- ----
From: s_clubb@netcom.co.uk (Stuart Clubb)
Hmmm.
I have heard no rumours, malicious or otherwise, but things in general must
be very bad for Synplicity not to IPO. Almost everyone wants to invest in
sexy high-tech stock these days so it makes you wonder how bad things have
gotten if the assertion is true.
I suspect it is not true.
As for Mentor buying them, why bother? A private sale in todays climate
would be indicative (IMHO) of an exercise in loss-limitation on the part of
the private investors. It may be that they might figure on playing the big
three off against each other, but I suspect neither Mentor nor Synopsys
would be particularly interested (except for some small tid-bits of
technology). That leaves Cadence in "Borg mode" again.
- Stuart Clubb
---- ---- ---- ---- ---- ---- ----
From: Rick Filipkiewicz <rick@algor.co.uk>
I was thinking more of Mentor buying Synplicity as a way of reducing the
competition!
- Rick Filipkiewicz
Algorithmics Ltd. UK
---- ---- ---- ---- ---- ---- ----
From: nine1209 on Yahoo CDN
I heard from a Venture Capitalist that Synplicity is for sale and is not
going to IPO. Who do you think will purchase them, Cadence???
- nine1209
---- ---- ---- ---- ---- ---- ----
From: whtthefk on Yahoo CDN
CDN should buy them. Synplicity cannot IPO now or in the near future.
Cadence can pick them up on the cheap, but the longer they wait the cheaper
it will get.
- whtthefk (a known Cadence employee)
( ESNUG 350 Item 2 ) --------------------------------------------- [4/27/00]
From: [ A Synopsys PhysOpt CAE ]
Subject: Two PhysOpt Scripts To Hand Place Specific Cells Near Each Other
Hi, John,
We're having PhysOpt users asking us how to place specific cells next to
each other. Typically they want to hand place specific clock tree cells
near specific register cells to minimize skew. Could you put this out on
ESNUG to reduce duplicate calls to our support guys?
First, you must query the location of the clockgate cell in question. The
following TCL procedure will get the location of the cell and create global
variables for the X and Y coordinates.
proc get_location {cell} {
global xdim ydim
redirect tmp_loc.txt { report_cell -physical $cell }
set in_file [open ./tmp_loc.txt r]
foreach line [split [read $in_file] \n] {
regexp {\(([0-9\.]*), ([0-9\.]*)\)} $line match xdim ydim
}
close $in_file
exec rm tmp_loc.txt
}
Using the following command along with cell_name gives the location of the
cell in form of a global variable {$xdim $ydim}.
psyn_shell-t> get_location cell_name
The user can take the global variables {$xdim $ydim}, and use these
locations in a script to place the register cells close to the clockgate.
All subsequent incremental PhysOpt compiles will then optimize the design
based on the new placement. The user can craft a script using the
following commands for each register of each clock gate:
set x_reg [expr $xdim + $offset_x]
set y_reg [expr $ydim + $offset_y]
echo "set_cell_location -coordinate {$x_reg $y_reg} $reg" >> set_loc.tcl
The execution of this custom script "set_loc.tcl" will change the locations
for the register and the PhysOpt incremental compile can then be performed.
- [ A Synopsys PhysOpt CAE ]
( ESNUG 350 Item 3 ) --------------------------------------------- [4/27/00]
Subject: Scan Test Implications Of Clock Tree Synthesis Tools Like Ultima
> At the SNUG'00 vendor fair I saw a tool from Ultima called ClockWise.
> Caught my attention since Chip Architect and PhysOpt don't have this
> capability yet (but will soon). However, ClockWise claims to be able to
> use clock skew as an advantage, moving the clock edges to fix setup/hold
> times. Their idea both intrigues and scares the hell out of me. This
> would have very serious implications on hold violations on scan flops.
From: Willis Hendley <willis.hendley@east.sun.com>
Hi, John,
As silicon scales down farther below 0.18 um, we have to use localized skew.
This is because global clock skews with useful cycle times and hold
specifications won't be possible. Luckily scan flops can have increased
delay on their scan-data-in ports to handle mismatches between 'useful skew'
on the functional path and 'non-useful skew' with respect to the scan
inputs. The logic cone depth and wire delays driving scan-data-in is
typically much shallower than regular data inputs.
- Willis Hendley
Sun Microsystems Chelsmford, MA
( ESNUG 350 Item 4 ) --------------------------------------------- [4/27/00]
From: [ A Synopsys PhysOpt CAE ]
Subject: Arranging Intentional PDEF/TCL Placement Obstructions in PhysOpt
Hi, John,
Here's another tip that would be useful to us if you published it in ESNUG.
There are two basic ways one can place intentional obstructions in the
PhysOpt design flow to block the tool for placing within specific zones or
blocks inside of your design:
1) Input through Floorplan PDEF
2) Created with the create_obstruction command.
Here is an example of a placement blockage in PDEF for PhysOpt. Note the
coordinates for this obstruction are in 0.01 micron units.
( CLUSTER PLACEBLOCKAGE_1
( OBSTRUCTION 221 )
( RECT 80320.0 1896600.0 128020.0 1898600.0 )
( X_BOUNDS 80320.0 128020.0 )
( Y_BOUNDS 1896600.0 1898600.0 )
)
To check the units for your PDEF, look for the following line near the top
of the PDEF file to verify the units:
( DISTANCE_UNIT 0.01 )
When you read the PDEF into PhysOpt, you will see the following warnings:
Warning: Line 2371, This obstruction becomes placement obstruction.
Obstruction size will be ignored for placment obstruction, use CLUSTER
RECT and CLUSTER X_BOUNDS/Y_BOUNDS attribute to represent the
obstruction size. (PDEFP-33)
This warning refers to the RECT statement in the PDEF example above. The
X_bounds and Y_bounds parameters actually specify the placement blockage.
To do the same thing via a TCL script, the command syntax is the same as
a wiring obstruction except for the layer number (99). See syntax below:
create_obstruction -name obstr_1 -layer 99 -coordinate {X1 Y1 X2 Y2}
where:
name: is a unique name for the obstruction
layer: needs to be a non-routing layer to be treated as a placement
obstruction.
coordinate: The coordinates for the bounding box of the obstruction.
X1: lower left x-coordinate
Y1: lower left y-coordinate
X2: upper right x-coordinate
Y2: upper right y-coordinate
NOTE: PhysOpt reports coordinates in 0.01 microns but you must input
coordinates in full microns.
To verify the layer numbers for routing so you can pick a non_routing layer,
check the PDEF. You should see something like the following in your PDEF:
( LAYER_DEF
( LAYER MET1 10 )
( LAYER MET2 12 )
( LAYER MET3 14 )
( LAYER MET4 16 )
( LAYER MET5 18 )
)
So, with the case above, we refer to layer 99 which is not a routing layer,
therefore, it becomes a placement blockage.
- [ A Synopsys PhysOpt CAE ]
( ESNUG 350 Item 5 ) --------------------------------------------- [4/27/00]
From Alan Hiren
Subject: Six Headaches If You're Switching From ModelSim To Cadence NC 2.1
I am new to Cadence Affirma NC 2.1 on Solaris. Just shifted from Modelsim.
But there are many problems which I am facing while carrying out the mixed
mode (Verilog + VHDL) simulations. It would be very kind of you if you
could clear them. I am sorry to say that I have gone throught the Cadence
documentation and it was not of much help.
1. Firstly, it was difficult getting on with terms such as database
and why do we need it. Is it same as making a project in Modelsim?
Documentation says it's better to define a scope rather than adding
adding signals of a block. What does that mean?
2. I am expected to carry out the simulations in batch mode, so I would
not be opening the GUI. But then how would I be able to open a
database and open a wave file? (It was quite straightforward in
Modelsim since we just saved the waveforms and later open the do file
with a simple do command.) I could not formulate a way of saving
wave files and opening them again. My usual practice is to add
signals eveytime with simwave by opening the GUI version (I need to
open it just for this). I have heard there are lots of flexibilties
available and I would like to make the utmost use of them. Could you
please guide me on this?
3. To remove the warnings from the stdout, I have to assign a variable
set_assert_level to 'error'. But I need to do this everytime I start
a new simulation. Is it possible to assign this variable in a file
and tell simulator to source that file when invoked? But in that
case I still require to open the GUI version which I dont want.
4. Where can I get sample script files for optimal performance of the
simulator. I would like to continue using the simulator.
5. Also there are cases where I need to change the code files just for
simulating them on NC. The changes I need to do are it requires both
the IEEE as well as the IEEE_SYNOPSYS libraries to be included. More
specifically, for some VHDL files, std_logic_arith of both libraries
need to be included. For VHDL files using conv_integer,
IEEE_SYNOPSYS.std_logic_unsigned needs to be added instead of
IEEE.std_logic_arith. For VHDL files containing direct assignment of
hex value to a std_logic_vector, the conversion is required like for
instance,
signal1 <= (X"0f");
needs to be changed to
signal1 <= to_stdlogicvector(X"0f");
How do I prevent these changes to be done in my code files? Changing
the simulator version would not be a good solution since that would
not be possible in the near future and I have to continue version.
Solutions for these problems are required for this version only.
6. One more problem is I am unable to reinvoke the simulation. It says
unable to write into so and so library file... why does it try into
this library files while reinvoking the simulation. We share a
central SUN m/c. and we have the library files mapped to files in
directory where we don't have write access.
Anybody out there sailing in the same boat ?
- Alan Hiren
---- ---- ---- ---- ---- ---- ----
> 1. Firstly, it was difficult getting on with terms such as database
> and why do we need it. Is it same as making a project in Modelsim?
> Documentation says it's better to define a scope rather than adding
> adding signals of a block. What does that mean?
From: Thomas Loftus <tloftus@intrinsix.com>
I am not clear on what you mean by "database". My guess is that you are
talking about creating a waveform database and no, that is not the same as
a project in Modelsim. I think what you are reading is saying that you
need to have code in your testbench which performs PLI calls to create a
waveform database during your simulation which you can open during or after
the simulation run. Rather than call out individual signals for this
database you can indicate the scope of the hierarchy which you need to
record. That is generally sufficient so that you don't need to
indicate specific signals.
> 2. I am expected to carry out the simulations in batch mode, so I would
> not be opening the GUI. But then how would I be able to open a
> database and open a wave file? (It was quite straightforward in
> Modelsim since we just saved the waveforms and later open the do file
> with a simple do command.) I could not formulate a way of saving
> wave files and opening them again. My usual practice is to add
> signals eveytime with simwave by opening the GUI version (I need to
> open it just for this). I have heard there are lots of flexibilties
> available and I would like to make the utmost use of them. Could you
> please guide me on this
Your testbench would include an initial block which called the appropriate
$shm_open, $shm_probe type commands to create the database at the start of
simulation (or some time during it if you have a specific event to trigger
off of).
Here's a simple example. Suppose I have a testbench called tb and a device
under test instantiated called DUT. Your code to create the waveform
database would look something like (I don't have the online docs in front
of me so forgive me if this is not exactly right.)
initial
begin
// Wait for trigger event if desired
$shm_open("waves"); // Open database named "waves"
$shm_probe(tb, "AS"); // Record tb scope and all sub hierarchy
$shm_probe(tb.dut, "A"); // Record only those signals at tb.dut scope
end
This example assumes you are using the built-in waveform tool that comes
with Cadence NC (simwave, it changes to signalscan I believe with version
2.2 so this will be slightly different.)
After your simulation run, you would invoke the waveform viewer with
"simwave waves" and all the signals you asked to be recorded should be
present. You don't need the NC gui at all.
> 3. To remove the warnings from the stdout, I have to assign a variable
> set_assert_level to 'error'. But I need to do this everytime I start
> a new simulation. Is it possible to assign this variable in a file
> and tell simulator to source that file when invoked? But in that
> case I still require to open the GUI version which I don't want.
I have used specific command line switches when performing NC Verilog
compilations and elaborations which are like:
-NOWARN XXXXX
where XXXXX is a specific name shown in each warning. This lets you turn
off specific verbose messages but lets you see others. If you want to turn
them all off, I think there is a command line switch to do that as well,
but I don't know it offhand.
> 4. Where can I get sample script files for optimal performance of the
> simulator. I would like to continue using the simulator.
I have used NC Verilog quite a bit and its performance is not dictated by
scripts, but by what is being simulated, the number of PLI calls, annotation
of SDF, and many external factors like memory availability and workstation
speed. I have not found any particular sensitivity to command line options.
Probing and PLI usage should be carefully limited for maximum performance.
There are also some coding style guidelines for maximum performance which
your Cadence A/E can provide. If you want to look at performance, use the
"profile" option which is not well documented, but which creates an
"ncprof.out" file showing statistically where the simulator spends most of
its time.
> 6. One more problem is I am unable to reinvoke the simulation. It says
> unable to write into so and so library file... why does it try into
> this library files while reinvoking the simulation. We share a
> central SUN m/c. and we have the library files mapped to files in
> directory where we don't have write access.
I don't know libraries you are referring to. Perhaps an error message would
be helpful. Obviously when you compile and elaborate your design, you need
to write the resulting "snapshot" into someplace where the simulator can
read it at run time. This would have to be created in a writable place, but
once there, it would not need to be written to be run (that I am aware of).
- Thomas Loftus
Intrinsix
---- ---- ---- ---- ---- ---- ----
> 3. To remove the warnings from the stdout, I have to assign a variable
> set_assert_level to 'error'. But I need to do this everytime I start
> a new simulation. Is it possible to assign this variable in a file
> and tell simulator to source that file when invoked? But in that
> case I still require to open the GUI version which I don't want.
From: Alan Fitch <alan.fitch@doulos.com>
In Leapfrog, there is a file called hdl.var which you can put options in
which you want to have by default. It is normally located in the directory
where you launch leapfrog, but I think you can have a default hdl.var in
your home directory as well.
> 5. Also there are cases where I need to change the code files just for
> simulating them on NC. The changes I need to do are it requires both
> the IEEE as well as the IEEE_SYNOPSYS libraries to be included. More
> specifically, for some VHDL files, std_logic_arith of both libraries
> need to be included. For VHDL files using conv_integer,
> IEEE_SYNOPSYS.std_logic_unsigned needs to be added instead of
> IEEE.std_logic_arith. For VHDL files containing direct assignment of
> hex value to a std_logic_vector, the conversion is required like for
> instance,
>
> signal1 <= (X"0f");
>
> needs to be changed to
>
> signal1 <= to_stdlogicvector(X"0f");
>
> How do I prevent these changes to be done in my code files? Changing
> the simulator version would not be a good solution since that would
> not be possible in the near future and I have to continue version.
> Solutions for these problems are required for this version only.
There may be a problem here. Leapfrog/Cadence comes with a version of
std_logic_arith which is *not* the same as the Synopsys std_logic_arith!
(That's why we encourage everyone to use Numeric_std on our courses; it's
an IEEE standard).
You need to look at the code for std_logic_arith as compiled into your
library, and see if it is the cadence or the Synopsys version. If it is
the Cadence version, you need to get your computer support people to
create a different version of the IEEE library, and compile all the
packages you need into that one. You then won't be able to see the
Cadence version, hopefully.
Leapfrog 2.6 (I think) didn't support the signal1 <= X"0f" format - so
the first thing to check is that Affirma NC supports it.
Secondly, check to see if you have the VHDL93 option enabled - this
format is only valid for std_logic_vector using VHDL93. Again, you can
set VHDL93 as a default in hdl.var (in Leapfrog, anyway!).
> 6. One more problem is I am unable to reinvoke the simulation. It says
> unable to write into so and so library file... why does it try into
> this library files while reinvoking the simulation. We share a
> central SUN m/c. and we have the library files mapped to files in
> directory where we don't have write access.
You'll soon have more libraries to get Synopsys std_logic_arith :-)
You may find the date stamps are in some way inconsistent, so that
Affirma NC is trying to recompile the IEEE library as well as your own
code. For instance, std_logic_unsigned uses (SYNOPSYS) std_logic_arith,
so if Synopsys std_logic_arith hasn't been compiled, it may be that
std_logic_unsigned is complaining??
Sorry a lot of my comments refer to Leapfrog. If NC VHDL is significantly
different, I apologise in advance...
- Alan Fitch
Doulos Ltd. Ringwood, Hampshire, UK
( ESNUG 350 Item 6 ) --------------------------------------------- [4/27/00]
From: Christian Bohm <christian.bohm@analog.com>
Subject: How Can I Trick DC Into Synthesizing Fewer, Bigger, Richer Cells?
Hi John,
First of all I have to say I really enjoy ESNUG. It's open, direct, and
pretty much unbiased. Good work! I have a question for your readers which
may be a bit off the beaten track.
Synthesising my design for a 3 layer metal process, I find that the cell
area utilisation after P&R (regardless which layout tool) ends up around 77
percent. This means that 77 percent of the chip area is covered with cells
and the rest is "white space", only to be taken up by the routing overhead.
(Okay, control logic tends to have no structure, few cells and lots of
connections, so what I see is not really surprising.)
As in now happens, my design is a bit too big to fit into the space
allocated. So I was wondering how I could use that 23 percent white space
for a few bigger, richer cells (e.g. AND-OR-INV) and reduce the wiring
overhead. My idea is while the cell area increases, the routing overhead
decreases, and the overall design area should shrink (wishful thinking?)
Power and other side effects are not a primary concern. How would one
constrain Design Compiler to achieve this? We tried editing the .lib file
to increase the wire area in wireload model. The idea being that each wire
now should have an "area penalty" associated.
wire_load ("my_wire_load") {
resistance : 0.000083 ;
capacitance : 0.000116858 ;
area : was: 1.319252 is: 5.319252; <== but didn't help a lot
(0.3% less nets)
slope : 101.342461 ;
fanout_length (1, 149.84) ;
... more entries here ...
}
To me it seems that this number is primarily used for the report_area output
but for nothing else. Correct?
We were also thinking about making nets artificially longer, so that each
wire has a timing-penalty associated (I have no synth results yet) but I'm
somehow not convinced that that's a good strategy. Any other suggestions
from ESNUG readers out there?
With respect to smaller geometries (0.18 um, 0.13 um) where it's the
interconnect delay which dominates and which causes your timing problems, a
strategy like this should really come in handy: Trying to minimize
interconnect rather-than/as-well-as cell area. Agreed? Disagreed?
- Christian Bohm
Analog Devices B.V. Somewhere, Europe
( ESNUG 350 Item 7 ) --------------------------------------------- [4/27/00]
Subject: LVS with Cadence Diva And Running Dracula DRC In Standalone Mode
> I'm using the Cadence design kit DK_hcmos7_3.0 in combination with Cadence
> DFWII 4.4.3 and I've got the following problem whenever I try to perform
> LVS using Diva: no matter how I specify the location of the rules file
> (i.e. relative to UNIX file system or relative to the technology file),
> the run always fails. This is what I find in the file si.log:
>
> Running netlist comparison program: LVS
> Begin comparison: Mar 14 16:25:58 2000
> @(#)$CDS: LVS version 4.4.3 07/07/1999 20:05 (cds230) $
> *Error* strcat: argument #1 should be either a string
> or a symbol (type template = "S") - nil
> *Error* load: error while loading file -
> "/LVS/divaLVS.rul"
> *Error* load: error while loading file - "*loadstring*"
> End comparison: Mar 14 16:25:59 2000
> si: Comparison did not complete without errors.
>
> I observed that diva copies the rules file to the LVS run directory first
> and tries to read it from there. I don't understand why Cadence Diva
> operates like this and why it fails. Does anybody know any help?
>
> - Torsten Mahnke
> TU Muenchen Germany
From: Edward J Kalenda <ed@kalenda.com>
The location of the rules file is not the cause of the error. This looks
to be an error in the rule deck. I would expect that someone did not
account for a property being missing in a combine or compare routine.
The reason Diva copies the rule deck to the run directory is historical.
Before the 4.4 release, the rules were stored in the technology library
as properties. Since LVS runs as a separate binary from DFII, it has to
have the rules in a file to access them.
When the rules became external text files in 4.4 the behavior was not
changed. The developers will commonly ask for a copy of the run
directory when you have a problem. Having the rules file in the run
directory means they don't have to ask you too send it when you forget
to include it with the testcase data.
- Ed Kalenda
---- ---- ---- ---- ---- ---- ----
From: Ben Geeraerts <ben.geeraerts@esat.kuleuven.ac.be>
Is it possible to run Dracula DRC in an interactive way (like Diva). Not
as a standalone product ??
- Ben Geeraerts Belgium
---- ---- ---- ---- ---- ---- ----
From: Edward J Kalenda <ed@kalenda.com>
I believe that is part of what InQuery does. I think they also call it
Dracula Interactive in the Cadence price book.
- Ed Kalenda
---- ---- ---- ---- ---- ---- ----
From: Ben Geeraerts <ben.geeraerts@esat.kuleuven.ac.be>
Thanks for your response. But I am still puzzled...
I can indeed view the Dracula simulation results with InQuery once a
simulation is done, but what I really need is a way to ineractively start
Dracula simulations, view them, edit design, resimulate and so on. I do
not think this is possible with the default Dracula standalone verification
tool and InQuery. You still need to start a Dracula simulation offline.
Does someone know if additional licenses are required and which binaries
are involved with this Dracula Interactive Tool ??
- Ben Geeraerts Belgium
( ESNUG 350 Item 8 ) --------------------------------------------- [4/27/00]
Subject: Doing Synopsys Scan Insertion Across Two Different Clock Domains
> If you have a design which connects flops Q to D, but the flops have
> different clocks, how do you force the Synopsys scan insertion tool to
> make the flops with one clock NOT the same chain as the flops with the
> different CLOCK? Must you hand craft your Verilog/VHDL code to allow for
> different data to be fed to Test In input of the chain? Just how smart
> is the Synopsys tool?
>
> - "Jim Jok"
From: Jan Decaluwe <jand@easics.be>
No, you don't have to change your HDL source code. The default behavior of
Test Compiler (since a couple of years) is to use separate scan chains per
clock system.
- Jan Decaluwe
Easics Leuven, Belgium
---- ---- ---- ---- ---- ---- ----
From: "Jim Jok" <jok@erols.com>
Thanks, with that knowledge I suppose I can add this other complication
which may have confused the others, too. (I am trying to fix a design which
is in silicon.)
The clocks are generated internal to the ASIC. The designers opted to use
one external clock, TESTCLOCK and when in scan mode this clock is on both
trees. I think this must have confused the tool since it mixed the scan
chains based on the connection of the Q to D connections.
I am wondering if by MUXing an external clock onto the seperate domains (so
in essence making them the same clock), the Synopsys tool thinks they are
the same clock and balanced. Any hints on driving the tool?
- "Jim Jok"
---- ---- ---- ---- ---- ---- ----
From: Jan Decaluwe <jand@easics.be>
> I am wondering if by MUXing a external clock onto the seperate domains (so
> in essence making them the same clock), the Synopsys tool thinks they are
> the same clock and balanced.
Yes, if they are driven from the same signal they are considered the same
clock for test purposes.
> So, any hints on driving the tool?
Yes, put the core of the design in a different level of hierarchy containing
everything except the clock mux and the pads. The core will have separate
inputs for the different clocks. Do scan insertion at the core level.
At the chip level, you can then run the tool with the -existing_scan
directive to recognize the scan chains.
This should do the trick for the scan chains, but when you now run ATPG at
the chip level, the clocks will again be considered the same by Test
Compiler. So if you have communication between the clock domains, the ATPG
vectors may not work.
- Jan Decaluwe
Easics Leuven, Belgium
---- ---- ---- ---- ---- ---- ----
From: Hans Lindkvist <Hans.Lindkvist@ldecs.ericsson.se>
You can manage with one scan chain. As long as the skew between the
"different clocks" in test mode (in test mode it is rather the same clock
but with skew) is limited to below half a clock cycle lockup latches in the
scan path will do the job. These latches can be added by test insertion
tools automatically. These tools does not fix problems on the mission mode
paths (which are the same as the capture mode paths). This will have to be
done up front, i.e. make the circuit immune to the maximum of the skew in
mission mode and capture mode.
My main message is that when the clocking scheme is designed, all of
mission-mode, scan-shift mode and capture-mode, have to be taken into
consideration or else the skew problems will very likely blow up in ones
face later in the design flow. At that point it can get very difficult and
expensive to fix it.
- Hans Lindkvist
Ericsson Mobile Communications AB Lund, Sweden
( ESNUG 350 Item 9 ) --------------------------------------------- [4/27/00]
From: Nancy Nettleton <Nancy.Nettleton@Eng.Sun.COM>
Subject: Exorcist Lady Questions SNUG'00 Hierarchical Vs. Flat Survey Data
Hey there John,
Something looks funny with some of these flat vs hierarchical numbers...
> ASIC design flow ############################## 59%
> COT Cadence P&R ########## 20%
> COT Avanti P&R ########## 19%
> COT in-house P&R ### 6%
> COT "other" P&R ## 4%
Here's your break-out of ASIC vs. COT: 59% vs 49%. OK. So some people are
going both ways... I buy that.
Then you show this list of fabs:
> In-House Company Fab ############### 30%
> TSMC ############ 24%
> IBM ######## 17%
> LSI ####### 14%
> Texas Instruments ##### 11%
> UMC ### 7%
> Lucent ### 6%
> STMicroelectronics ## 4%
> VLSI, Toshiba, NEC # 3%
> AMI, Samsung, Fujitsu,
> Charter, Intel, Epson,
> Mitsubishi, National 1%
Which of these fabs have a hierarchical flow? COT shops for sure. LSI, TI,
NEC, and Toshiba are just starting to proliferate theirs. All the others
are flat as Kansas.
Oh, and your SNUG'00 data on chip sizes:
> 1 - 100 Kgates ######## 16%
> 101 - 500 Kgates ############ 25%
> 501 -1000 Kgates ############## 28%
> 1 Million + ############### 31%
Most design shops won't take a design hierarchical until its over 1M gates.
The lowest gate count I've seen on a hierarchical ASIC was 750K gates, and
that was by a rabid hierarchy monger. OK, so let's say 40% of the designs
are in the range of sizes that would benefit from layout hierarchy.
Now I get to the astounding number of hierarchical designs being done:
> Flat Only ########## 20%
> Hierarchical Only ############ 24%
> Mixed (Flat & Hier.) ############################ 56%
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? And once I get them to partition it and they
start trying to close hierarchical timing, they look like greased pigs
on roller skates? Nope, nobody could fake inexperience THAT well.
Here's Crazy Nancy's Pet Theory: people think they're hierarchical when
they're not (like getting drunk and thinking you're funny...)
Most logic designers I've talked to who've done floorplanning had the
mistaken belief that their layout was being done hierarchically because
they could see their logic blocks in the layout. That's just not the
case. Its like seeing lines of RTL in a file and mistaking that for
logical partitioning. The layout is grouped, but its flat. It is not
partitioned such that each block can be laid out independently. Unless
the layout is truly partitioned with planned block interfaces, the
router determines how wires will enter and leave a block. You could no
more pull out that layout block and drop in another one than you could
pull out one piece of spaghetti and expect to instantiate another one
in its place.
Or maybe there's something else in the data that I'm just not seeing...
Maybe it's in the COT numbers... What do you think?
- Nancy Nettleton
Sun Microsystems Silicon Valley, CA
[ Editor's Note: I understand what you're saying, Nancy, but I have not
clear answers. I went back to the Synopsys people and had them
separate out only the pure COT people in the SNUG'00 survey and tally
their responses to the Hierarchical vs. Flat question:
Flat Only ######## 16%
Hierarchical Only ########## 19%
Mixed (Flat & Hier.) ################################ 65%
Which flies completely in the face of your statement that virtually
all of the fabs are mostly flat oriented.
And it gets weirder.
Synopsys surveyed 600 customers last year when they did the '99 update
training and asked them if they were COT or ASIC. They got:
ASIC ############################################ 88%
COT ###### 12%
And they also asked the same customers how they did design hand-off:
Netlist Only ###################### 45%
Netlist + Floorplan ############ 25%
GDS II ########### 23%
Netlist + Placement ####### 14%
Other ## 4%
"RTL Handoff" wasn't an option on the survey. The hand-off numbers add
up to more than 100 percent because some customers checked more than one
box on this question.
Why this is X-Files weird is how can 23 percent of the design hand-offs
be GDS II while only 12 percent of customers were COT then??? - John ]
( ESNUG 350 Item 10 ) -------------------------------------------- [4/27/00]
Subject: Why Is There No On-line Synopsys 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: Muzaffer Kal <muzaffer@kal.st>
The only reference I know is a book:
Behavioral Synthesis: Digital System Design Using the Synopsys
Behavioral Compiler, with Disk
By Knapp, David
List Price: $78.00
231 Pages
Published by Prentice Hall
Date Published: 06/1996
ISBN: 0135692520
available at www.clbooks.com
- Muzaffer Kal
---- ---- ---- ---- ---- ---- ----
From: Lars Rzymianowicz <larsrzy@ti.uni-mannheim.de>
Hmm, is this book still up-to-date? Four years is a whole generation in EDA
industry. Anyway, the Synopsys online manuals are quite good. But no BC
tutorial. :-( I'd like to have some sort of step-by-step guide for BC as
they have for the other tools...
- Lars Rzymianowicz
University of Mannheim Mannheim, Germany
( ESNUG 350 Item 11 ) -------------------------------------------- [4/27/00]
From: Greg Mokler <gmokler@dal.asp.ti.com>
Subject: A Review Of The Recent Verisity (Specman) User's Group Meeting
Hi, John,
You said you wanted more user input about Vera and Specman. Here's my
Trip Report for the recent Verisity (Specman) User's Group meeting.
Verisity's first user's group meeting was held in San Jose on April 12 - 13.
About 74 attendees actually showed up out of 115 who registered. Of these,
over half were from companies located outside the valley, and about 20
percent from overseas.
Verisity was represented by CTO and founder Yoav Hollander, VP of Marketing
Francine Fergeson, Yaron Kashai who is their expert on Formal Link and it's
use with formal verification tools, and Andy Lynch, formally of Surefire
and the author of the coverage tool SureCov, which Verisity acquired along
with SureSolve when they bought Surefire last year.
Yoav was anxious for input from users on what the company is doing wrong,
but went away disappointed. Although there were definitely some power
users there, most of the attendees were fairly new to the tool. The depth
of experience to provide the kind of feedback he was looking for just wasn't
there this year. Hopefully, this situation will change as the industry gets
more experience with Specman Elite. The Verisity folks also expressed their
desire to see future meetings being much more user driven, and has set up a
steering committee of users from attending customers to drive this.
Presentations were primarily from users, but also included several from
third party developers, outside consultants and one by Yoav. The complete
presentations are NOT available on Verisity's web site at present. In his
keynote address, Yoav called the current state of Specman Elite a "good
start" which has mechanized the easy part of verification, but said that a
lot of methodology (and the features to support it) still needs to be
invented.
Presentations
Presentation #1 Technology Roadmap . . . . . . . Yoav Hollander, Verisity
The next major release, 3.3, is scheduled to ship in late August and will
include several badly needed enhancements. Waveform viewer integration will
allow interactive tracing of events, expressions, log messages, and threads
without having to modify loaded e modules. Initial viewers supported will
include Signal Scan, Virsim, and Modelsim. Obviously, the ability to
graphically see the relationship between signal transitions and event
emissions will be a big improvement over the current event chart "feature".
For VHDL coders, this release will provide better support for the interface.
Calling VHDL procedures, the ability to force signals directly, and VHDL
strings will be supported. Also, for Modelsim only, simulator commands can
be sent to the simulator from "e?".
Future enhancements on the roadmap are support for distributed simulation
(whereby separate threads of a sim can be run on different machines), a
Java-based GUI for the coverage tool, and a "complete facelift" for
Specview. Also in the works is automatic feedback of coverage to
generation. The tool will be called Coverage Maximizer and will have two
parts. The first part will analyze the design architecture and existing
test files to intelligently identify and define coverage items. This should
help users get started on a coverage plan for their design. The second part
will evolve over time. The initial implementation of Coverage Maximizer
will be to provide automatic generation of test files (constraints to
overlay) which can then be run separately to fill coverage holes left by
previous runs. There is currently a debate within Verisity about whether or
not to provide a reactive test generation capability in which Coverage
Maximizer iteratively reads coverage metrics and generates new tests
on-the-fly to fill coverage holes.
Presentation #2 Transitioning an Internally Generated Testbench
to Specman Elite. . . . . . . . . . . . . Robert Quist, HP
Presentation #9 Replacing an Internal Tool with Specman Elite
. . . . . . . . . . . . . . . . . . . Kevin Jones, Rambus
These folks made the "leap of faith" to abandon a great deal of existing
infrastructure to adopt Specman Elite as their verification environment
despite the fact that the existing test benches had worked extremely well
on previous projects. Both speakers agreed that the results were well worth
the pain of doing so.
Robert Quist of HP sighted various reasons for this decision. The current
environment required a large amount of maintenance which could be more
economically done by a third party company. Also, the need for a "dramatic
increase" in the amount of random test generation was mentioned. Robert
presented an extensible test bench architecture which leverages the use of
verification components which were designed for module level testing and
then "bolted on" to the system level bench. He also shared some specific
coding practices that were compiled from their project post mortem.
Kevin Jones of Rambus sighted similar considerations. As a small team, his
verification staff lacked the bandwidth to maintain a tool written in LISP
by people who were no longer available to help. He sighted incremental
migration from the old tool to Specman Elite as the reason for their
ability to stay productive during the process.
Both speakers also emphasized the advantages of having access to metrics
for measuring and reporting status of the verification effort to management
via Specman's coverage features.
Presentation #3 Generation for CPUs . . Ori Chazan, National Semiconductor
Classic techniques for obtaining test cases for CPU designs present
problems: using existing software applications, assuming that they exist,
typically provides only partial coverage of the design's test space, while
writing directed tests may miss or fail to identify many corner cases. Ori
presented two methods for generation of random tests for CPU verification.
In the first method, which he called "correct by construction" a program
(list of instructions) is generated up front prior to running the HDL
simulator. Constraints are defined which ensure that every generated
instruction is legal, both syntactically and semantically. Since the
"legalness" of an instruction depends upon the current state of the CPU
registers and memory, this approach requires that the full state of the CPU
be maintained within the Specman environment and updated after each
instruction is generated. By using this method, then, every instruction of
the generated program is guaranteed to be valid "by induction". Ori's group
found that this approach can be problematic: in many cases, the definition
of constraints to ensure that only legal instructions are generated are too
difficult to express. Under these conditions, an alternate method of
instruction generation is needed. In Ori's second method, a candidate
instructions is generated using a less ambitious set of constraints that
ensure the instruction is syntactically legal & also that state-independent
semantic considerations are accounted for during generation. Each
instruction is submitted to the simulator, then, based on information from
the simulator, the remaining conditions for "legalness" are checked. If
some constraint has been violated, then the candidate instruction is
rejected, and the simulator state is rolled back, otherwise, the instruction
is added to a list (to preserve the program) and the simulator state is left
as is.
Presentation #4 SoC Verification with Seamless . . . Brian Bailey, Mentor
Brian discussed work being done by the VSI Alliance. This system level
working group is trying to define rules for using, exchanging, verifying,
and integrating Virtual Components in an effort to make design reuse more
practical. He then gave a presentation of Seamless and it?s use with
Specman Elite. From the work that's been done by Verisity and Mentor,
Specman can access S/W symbols, and memory state of a processor as it
fetches and executes object code.
Presentation #5 Denali/Specman Integration . . . . . . . Sean Smith, Cisco
Sean Smith has been using Denali memory models in conjunction with Specman
for several years. He discussed the mechanics and benefits of this
methodology. He says that the ability to access memory from "e" and to
have memories generate callbacks to ?e? has raised his ability to verify
systems to another level. His arguments were extremely convincing. Anyone
using Specman to verify a system with external memories or large internal
blocks of memory should take a serious look at this presentation! Also,
Sean's paper included a web link where example code can be downloaded:
http://netmediasolutions.com/verification/oo_verification_examples.zip
Presentation #6 How to Build an eVC . . . . . . . Janick Bergeron, Qualis
Because verification requires a larger effort than design and is not
subject to limitations of target technology, testability requirements, or
synchronous design rules, Janick believes that reuse of verification
components is essential and practical. He presented a number of specific
practices which must be followed to quickly produce a good reusable
component, class libraries, Specman coding guidelines, etc.
Presentation #7 RTL-based Object-oriented Models . . J Marc Edwards, Cisco
Since the industry is trying to move to higher levels of abstraction in
design using oo languages like C++, it makes sense to consider "e" as a
candidate: an oo language with the ability to handle temporal concepts is,
like Specman, a natural for this application. Also, the generation engine
could be used to generate objects on-the-fly at the architectural level,
thus bringing automation to the exploratory phases of system design. Cisco
has funded some university research to develop an "e"-to-Verilog translator.
The initial approach will be to restrict "e" to a subset of constructs
which are easily mapped to Verilog. Later, more abstract concepts such as
inferring memories from "e" data structures will be explored.
Presentation #8 How to verify an ATM Switch . . Heath Chambers, Consultant
Heath discussed his experiences using Specman to verify a large ATM switch.
This was a classic application of the tool that really demonstrates it's
capabilities. It was also a good presentation of some of the typical
mistakes that are made when using the tool for the first time. The
impressive part is that the project was very successful despite all the
mistakes. More experience with the methodology promises big payoffs!
Roundtables
There were also a number of roundtable discussions covering various topics.
Several interesting developments were discussed:
- "e" language standardization - A steering committee will be formed in
the next several months to drive this effort consisting of parties with
a stake in the language, including "two major EDA vendors".
- Porting of temporal language to verilog - Verisity has agreed to
contribute their temporal language to OVI.
- Formal Link update - Verisity sees a need for a unified environment
wherein a single source drives both simulation and formal verification.
Taking advantage of the fact that a subset of "e" already has formal
semantics (temporal language, etc.) and that model checker properties
are, presumably, easier to debug using simulation. Verisity plans to
simplify the model checking methodology by providing synthesis of "e"
to model checking properties. Formal Link is a tool that Verisity
demo'd at DAC last year as a front end to SMV - a formal verification
tool developed at Cadence, UC Berkeley Labs. It is currently being
integrated with a commercial model checker from a "major EDA vendor"
(hmmm, how many major EDA vendors have these products? ) and will be
announced soon. The tool takes Specman temporal checks as input and
synthesizes model checker queries.
Lowlights
Considering that this was the first user's group meeting, there really
weren't a lot of negatives other than the users' aforementioned lack of
experience with the tool. The meeting had a day and a half of
presentations/roundtables (which could have been condensed down to a day)
and, since it was scheduled in the middle of the week, consumed about 3 days
of time for those of us who were coming in from out of the area. So maybe
the timing could have been better. Verisity has already said that next
year, the program will be extended to 2 full days with some advanced
training sessions.
One of the users in the audience asked Janick Bergeron why he recommended
Vera over Specman at the last meeting of SNUG. We all wanted to hear his
answer, but never got one.
- Greg Mokler
Texas Instruments, Inc. Dallas, TX
============================================================================
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."
|
|
