Editor's Note: It's weird how too much synthesis can rot one's brain.
Last Sunday I was stuck in a hotel room, without car, in a quasi-rural
part the South. From the map I saw I was about 3 miles from town, but
on the wrong side of a river that only had an Interstate highway bridge
over it. (Walking on those bridges is a great way to get a "free"
ride to the nearest State Police barracks.) Bored, I decided to walk
to town anyway. When I got to the Forbidden Bridge, I looked down and
saw that although the river was very wide, the water level was quite
low. I decided to "rock hop" across the river. It took over 2 hours
of trial & error trying to figure out the right path that would get
me across -- and all during that time I couldn't stop thinking about
damned synthesis algorithms that modeled my path search pattern! :^(
- John Cooley
the ESNUG guy
P.S. When I got to the other side, the people there were surprized to
see me. It just stunned them all. Them: "You *walked* across that
river?" Me: "Yup." Them: "YOU'RE crazy!" Me: "I was bored. Boredom
does that to people." Eventually I went into town, had dinner, and
caught a taxi back to my hotel. I told the taxi driver about how
shocked those people were and he replied: "Oh, that's because there's
a dam not too far up river that opens up at random times. That river
becomes a mad rush of water in an instant." <yikes!> :^0
ESNUG 256 Item 1 ) -------------------------------------------- [11/96]
Subject: ( ESNUG 255 #4 ) Internal Tri-State Vs. MUXes Rules Of Thumb
> The rule of thumb I use is:
>
> - Less than/equal to 4 devices on a bus, multiplex.
> - Less than/equal to 8 devices, probably mux, maybe tri-state.
> - Less than/equal to 12 devices, probably tri-state.
> - More than 12 devices, tri-state.
From: dtkain@CCGATE.HAC.COM (Dan Kain)
Dear John,
I thought you might like the approach I am using on my current ASIC
design. I have an internal bus in the ASIC that has to read
approximately 100 registers. I mux the registers internal to each
of my approximately 5k gate partitions that get synthesized by
Synopsys. When I mux inside the partition, I have a "case" statement
with the default/others choice with the output all zeros if none
of the registers are selected. I then daisy chain "OR" the partition
outputs from one partition to the next. This approach minimizes the
routing between partitions and so does not require lots of routing
like the external mux approach would require. This approach only
requires a 1x driver to drive the next partition since there is only a
single load when you "OR" which is much better than tri-stating.
- Dan Kain
Hughes
---- ---- ---- ---- ---- ---- ----
From: rprice@procy.gi.com (rick price)
Hey John,
One very serious problem with tri-states that wasn't addressed is the
possibility of creating a tri-state net which can't be driven by the
largest tri-state driver in the cell library, (i.e. the net capacitance
is larger than the max_cap attribute of the tri-state driver.) The 0.35
ASIC libraries I've worked with have been fairly limited when it comes
to tri-state cell drive selections. This situation is problematic
since most designers lean toward the use of tri-state nets when the
number of loads is large. Worse still is that with the deep
sub-micron designs the estimated pre and post layout net capacitances
can very significantly so a designer may not know a problem
exists until after the design has been layed out.
I think both tri-states and muxes have their place in ASIC designs,
but before using either the pros and cons most be know to be
successful.
- Rick Price
General Instrument
---- ---- ---- ---- ---- ---- ----
From: Oren Rubinstein <oren@waterloo.hp.com>
John,
One more reason for choosing tri-state drivers over MUXes is the physical
size and location of the blocks that you want to connect.
In the MUX approach, you can have many wires going back and forth between
the blocks; if these wires are long, the load is high, you need stronger
drivers for them, etc. And, of course, it's harder to route the chip.
So I would ammend the above rules to say "equivalent devices on the bus",
(i.e. include the load of the wires and the bigger drivers in the
calculation.)
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
---- ---- ---- ---- ---- ---- ----
From: Steve Sharp <sharp@xilinx.com>
Hi John,
The age-old "tri-state vs. mux" questions takes even more twists when
one considers FPGAs. In the Xilinx devices, you have tri-state drivers
with dedicated lines (hense a different problem than ASICs where
porosity of the cell is a concern) and often much better timing if you
use the tri-states to build a large mux. So in an FPGA, the question
often becomes "when should I use tri-states to implement a large mux"
and not the other way around. I whole-heartedly agree with the addage of
learing along the way. I feel much the same about the VHDL vs. Verilog
debate.
- Steve Sharp
Xilinx
---- ---- ---- ---- ---- ---- ----
From: Chuck Benz <benz@npss.enet.dec.com>
John,
Here's one more spot of drivel regarding on-chip tristate busses.
When I spent a few years hanging around with the custom CPU guys in
Hudson, MA (even before they started sniffing that Alpha stuff), they
expressed concerns about connecting diffusion on one side of a chip to
diffusion on the other side - noise in the power bus could make that
dangerous if it was enough to back bias the parasitic diodes. Enough
coulombs, and BANG! latchup. Doesn't mean that they didn't use such
structures, but they used tools that could give an estimate of the
coulomb count so that they would never be surprised ! (Haven't seen
that sort of tool in the ASIC world, yet).
File this under holy wars, eh ?
- Chuck Benz
Digital Equipment Corp.
( ESNUG 256 Item 2 ) -------------------------------------------- [11/96]
Subject: (ESNUG 254 #4 255 #3) Can't Reset "max_capacitance" Post-layout!
> ... (DC_SHELL couldn't multiply the value itself because
> the value was a string not a floating point). I then used perl
> to multiply the numbers and add the other syntax of the command.
>
> Here is the dc_shell script (just fill in YOUR_LIB_NAME):
> ...
> max_cap = get_attribute(fullname, max_capacitance)
> ...
> You can use perl to multiply the number and format the file into a
> dc_shell script to be read back into synopsys ...
From: "David C. Black" <dblack@ink.apple.com>
John,
I loved Jeff Scott's solution except that there is a minor optimization
that can be had. He apparently didn't realize that the return from the
get_attribute command is actually a list consisting of zero or one
elements. This can be processed as follows (replacing respective part of
Jeffrey's script):
$max_cap_list = get_attribute fullname "max_capacitance"
if($max_cap_list) {
foreach ($max_cap,$max_cap_list) {
set_attribute fullname "max_capacitance" (1.25 * $max_cap)
}/*endforeach*/
}/*endif*/
If preferred, you may echo the set_attribute line to a file for later
execution. Just remember that the in-line version is more reliable in
case your library changes and you might forget to update a script. On
the other hand, stability in the file for regression might be preferred.
SCRIPTING NOTE/TIP: I put a dollar sign in front of all user defined
variables in Synopsys to avoid potential collisions with current and/or
future keywords in dc_shell. Also, I quote all synopsys keyword
arguments unless I intend to use a variable.
This comes from experience where another designer tried:
design = "top";
...
all_designs = find(design,"*")
Synopsys complained of syntax because it was processing find(top,"*")!
Instead, we now use:
$design = "top";
...
all_designs = find("design","*");
Since Synopsys is always adding new and even hidden features to their
syntax, I chose to take preventive measures. Too bad Synopsys doesn't
advertise a reasonable safe naming space BTW, I dislike my_ in all
variables, and $ is quite natural to anyone with UNIX(tm) scripting
experience.
- David C. Black
Apple Computer
---- ---- ---- ---- ---- ---- ----
From: sgolson@trilobyte.com (Steve Golson)
John,
The get_attribute doesn't return a string; it returns a list. If it was
a string there would be no problem, because dc_shell will coerce the
string to a number when it needs to.
What you need to do is extract the number from the list. Here is a
trick using foreach that works great. It extracts the first (and only)
element from the list and returns it in the variable "thecap":
dc_shell> get_attribute access05_5v/AND2X2/A capacitance
Performing get_attribute on port 'A'.
{0.012400}
dc_shell> foreach (thecap, dc_shell_status) { ; }
1
dc_shell> list thecap
thecap = 0.012400
1
So your script would look like
library = YOUR_LIB_NAME
cells_in_lib = library + "/" + "*"
cells = find( cell, cells_in_lib)
foreach ( cellname, cells ) {
pins_in_cell = cellname + "/" + "*"
pins = find( pin, pins_in_cell)
list pins
foreach ( pinname, pins ) {
fullname = cellname + "/" + pinname
list fullname
get_attribute fullname max_capacitance
if (dc_shell_status) {
foreach (thecap, dc_shell_status) { ; }
newcap = thecap * 1.25
set_attribute fullname max_capacitance newcap
}
}
}
No need to use perl.
Let me know how it works for you.
- Steve Golson
Trilobyte Systems
---- ---- ---- ---- ---- ---- ----
From: eugena@taec.com (Eugena Talvola)
Hi John,
I have modified the max_capacitance setting script to do everything
within dc_shell. It's probably more convenient than running dc_shell
and perl.
library = YOUR_LIBRARY
cells_in_lib = library + "/" + "*"
cells = find( cell, cells_in_lib)
foreach ( cellname, cells ) {
pins_in_cell = cellname + "/" + "*"
pins = find( pin, pins_in_cell)
list pins
foreach ( pinname, pins ) {
fullname = cellname + "/" + pinname
pindir = get_attribute(fullname,pin_direction) > /dev/null
list fullname
if (pindir == "out" || pindir == "inout"){
get_attribute fullname max_capacitance
if(dc_shell_status) {
max_cap = get_attribute(fullname,max_capacitance)
echo "set_attribute" fullname "max_capacitance" max_cap >> cap.list}
}
}
}
sh "cat cap.list | sed -e 's/[{}]//g' > .normal_max_cap"
sh "awk '{$4 = 1.5 * $4; print $0}' .normal_max_cap > new_max_cap.inc"
include new_max_cap.inc
Change 1.5 to whatever multiplication factor you want all max_cap
values will be modified uniformly. You can always modify some values
further in ".normal_max_cap" if there are other requirements.
- Eugena Talvola
Toshiba America Electronic Components, Inc
( ESNUG 256 Item 3 ) -------------------------------------------- [11/96]
Subject: ( ESNUG 255 #6 ) Can't Constrain "Ideal" PLL Generated Clocks
> I'm trying to create a clock that comes from an internal clock driver.
> I've got no clock tree, just a global clock net, so Synopsys sees
> 10,000 loads on the clock driver. This is a pre-layout netlist, so I
> just want to see an ideal clock. I've tried "set_load 0 CLKNET" but
> this only gets rid of the wire capacitance, there's still 130pf of
> capacitance from clock input pins of all the flops. I've tried:
>
> create_clock_no_input_delay = true
>
> but this doesn't seem to do anything. I've also looked at the
> attribute "propagated_clock", but it's not set. (Isn't this a common
> problem with prelayout netlists that contain PLL's?)
>
> The only thing that works is temporarily disconnecting the clock
> net from it's driver, creating a port, making the clock net to new
> port connection, and then doing a "set_drive 0 new_port". Obviously
> this method is not preferred. Any better ideas?
From: Oren Rubinstein <oren@waterloo.hp.com>
John,
Our standard solution is to instantiate a phony cell called "clock_tree".
You can give it a delay, which sometimes is useful in simulations, and
you can create a Synopsys model for it with a drive strength of 0.
When the chip is routed, this cell is replaced by the real clock tree.
A similar approach would be to put the drive strength of 0 directly in
the PLL model.
- Oren Rubinstein
Hewlett-Packard (Canada) Ltd.
---- ---- ---- ---- ---- ---- ----
From: Neil Hastie <hastie@isti.fr>
John,
We hit exactly the same problem with our last design. The solution is
to get your friendly ASIC library supplier to produce a dummy clock
buffer model. (Or do it yourself if you possess a Synopsys Library
Compiler.) This clock buffer model should have zero delay independent
of output load. Use this model until you get a real clock tree.
Hope this helps.....
- Neil Hastie
International Supercomputing Technology Institute
Mulhouse, France
---- ---- ---- ---- ---- ---- ----
From: mcur@alcatraz.rtc.sc.ti.com (Mark A. Curry)
Hi John,
What's probably happening is that Synopsys is still calculating a
delay from the wire-load resistance times the 130pf pin capacitance.
Try setting the resistance of that net to zero:
set_resistance 0 CLKNET
- Mark Curry
Texas Instruments ASIC Design Center - San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: John_J_Lim_at_3-AP02A@CCGATE.HAC.COM (John Lim)
Hi John
It sounds the like the problem Paul is having is that the clock net is
being buffered up (like crazy) when he tries to compile. I had a
similar case when using an internal clock driver (from a clock
generator). The way I handled it was to put a "set_dont_touch_network
CLKGEN/CLK" where CLKGEN was the clock generator block name and CLK is
the output pin from that block. By setting a dont_touch_network, the
tool will not consider the net for design rule constraints thus
leaving the net unbuffered. Hope this helps.
- John Lim
Hughes Space and Communications
( ESNUG 256 Item 4 ) -------------------------------------------- [11/96]
Subject: ( ESNUG 251 #8 ) Test Compiler "Moody" With Test_Mode & Reset_n
> I have a question about disabling asynchronous resets during test mode.
> Test Compiler requires all asynchronous resets to be disabled during
> test mode. Should this include our primary input "reset_n" ? I have
> included this gating and I am still having problems with Test Compiler.
> The problems result on only a small amount of the flip-flops and seems
> to depend on how Test Compiler generates the logic for this gating. I
> have always thought that strobing reset should reset all of the flip
> flops in the design even if test_mode (another primary input) is a '1'.
>
> Assume active low asynchronous reset for the flip flop and when signal1
> = '1' then we want to reset the flop. There is no problem when:
>
> (reset_n and (test_mode or not signal1))
>
> There is a problem when:
>
> ((test_mode nand reset_n) nand (reset_n nand signal1))
>
> Even though Test Compiler is infering an asynchonous reset port on
> reset_n. It is not able to realize that reset_n will be a '1' when
> shifting in and out data. I have been told by a Synopsys FAE that
> test_mode= '1' should not allow reset_n to reset the flip flop although
> this has not been sitting well with me. Any advice on ESNUG would be
> greatly appreciated.
From: Bill Armstrong <army@hlds.com>
John,
This is probably rooted in the fact that it is fairly easy to generate
a set of test patterns to test an asynchronous reset and what Test
Compiler, TC, is trying to do.
TC is not only adding scan chains to the circuit, but also generating
sets of serial and parallel test vectors to cover as many stuck-at
faults in the design. The problem, I believe, is Test Compiler does
not automatically know the difference between a regular input signal
and an asynchronous reset signal. Although you'd think, by requiring
an additional property (similar to clk pins) on the flip-flops, TC
could be made to understand these types of asynchronous signals,
after all a clock signal is just a special type of asynchronous
signal.
Getting back to the point, I feel it necessary to give a little
synopsis (no pun intended, notice the spelling) on what TC actually
does when generating test patterns. TC, if memory serves and in very
basic terms, puts the circuit in normal operation, sets all of the
input signals to some state, generates a clock, and puts the circuit
into scan mode where, during several clocks, the scan registers are
serially shifted out of the circuit. These will become the known
"good" results for comparison during silicon testing. While serially
shifting data out TC is also serially shifting new data into the scan
chain to propagate to normal outputs in the next normal clock
operation. TC then puts the circuit back into normal mode, stores the
normal outputs to be used as known "good" values for testing silicon,
sets the inputs signals to another state, generates another clock,
puts the circuit into test mode, and starts serially shifting the scan
registers again. TC repeats this process until a percentage of faults
have been covered (storing results if it improves the coverage),
i.e. the faults can be controlled, setting of inputs and clocking, and
observed, either at the serial output points of the scan chain or the
parallel (normal) outputs of the circuit. Whoa, that's a mouthful. I
hope I haven't bored everyone.
Now, since TC does not know the difference between a regular,
synchronous, signal an asynchronous reset it could, and would, set the
reset such that all of the flip-flops were cleared after being setup,
during the previous serial shift operation, to propagate known values
to the normal outputs. This would reek havoc on the fault analysis TC
is trying to do and the fault coverage would be less than what could
be achievable. To explain a little further, during TC's analysis it's
looking for changes on outputs based on different patterns it feeds
into the scan chain. If the flip-flops were randomly reset the normal
outputs would be in the same state as a previous reset, independent of
what was fed into the scan chain, and TC would think this combination
of scan chain values was not valid (had no affect on the outputs),
when in fact, it may be the only combinations of values to affect a
particular node (or fault) which would propagate to an output, if the
reset signal was not active.
I think, maybe, I wrote too much. I must mention one more thing,
however, I believe Synopsys has a way of disabling asynchronous
signals in TC. The thing is you have to tell TC which signals to
disable, but this seems easier than messing with the HDL code to add
unnecessary gates, don't you think?
- Bill Armstrong
High Level Design Systems
( ESNUG 256 Item 5 ) -------------------------------------------- [11/96]
From: ajayn@sol-tx.sps.mot.com (Ajay Nath)
Subject: How Do I Constrain My Funky "Ordered-Input" Combinational Cell?
Hi John,
Here is a query for the Synopsys gurus out there.
I have a *combinational* library cell with multiple inputs is designed in
such a way that it is critical for the inputs to maintain an ordered
relationship with one another. Is it possible to model such a constraint
into the library cell, such that Synopsys will enforce this order?
Consider a cell with function f(a,b,c). Due to circuit design issues,
the function requires that input "a" be set up prior to input "b." In
other words, input a has a setup requirement with respect to input "b"
for the function to be correct.
The library attribute "timing_type" does not have any setup/hold values
for *combinational* circuits. Does anyone have any ideas on how to force
synthesis to design in this relationship? If this cannot added to the
library cell description, is there a generic approach to solving this
problem using DC commands?
- Ajay Nath
Motorola
( ESNUG 256 Networking Section ) -------------------------------- [11/96]
Dublin, Ireland - Massana have vacancies in algorithm devel. & IC design
for digital comms/signal processing apps. "paul.costigan@massana.ie"
|
|
