> From: Jeff Waite <Jeff.Waite@NetergyNet.COM>
> Subject: User Discovers Hidden Switch "hdlin_enable_presto" In DC 00.05
>
> Hey John,
>
> I recently became aware of an apparently undocumented variable in ver
> 2000.05 of Design Compiler: hdlin_enable_presto
>
> Synopsys informed me that setting this true will help the HDL Compiler
> "work better" but I haven't had a chance to test this out (yet). I was
> curious if anyone else had heard of this variable or had any feedback on
> it. Thanks.
>
> - Jeff Waite
> Netergy Networks, Inc.
EDITOR'S NOTE: Jeff, I can't wait to find out what *this* hidden switch
truely does. Don't get me wrong. I like switches. They've pulled my ass
out of the synthesis fire more times than I can count. It's just that
this "presto" is so vague... It makes HDL Compiler "work better"???!!?
Huh? Exactly what does "work better" mean? And if it's true (i.e. it
does make it somehow "work better") why is it a switch? Why would anyone
want "working-not-so-good" as default? Something fishy is going on here,
Jeff. I don't think Synopsys told you the whole story.
- John Cooley
the ESNUG guy
( ESNUG 356 Subjects ) ------------------------------------------- [8/03/00]
Item 1 : ( ESNUG 355 #13 ) 2nd Plea For Help On Opposite-Input Tri-states
Item 2 : Cadence Diva LVS Tricks For Differentiating Identical Devices
Item 3 : ( ESNUG 355 #3 ) Verplex, Synopsys Formality, and Scan/BIST/JTAG
Item 4 : ( ESNUG 355 #2 ) Synchronizers & Timing Problems With Reset Trees
Item 5 : ( ESNUG 355 #17 ) Ways To Convert Xilinx Gates Into ASIC Gates
Item 6 : ( ESNUG 355 #14 ) Find The Driving Cell Of A Specific Net In DC
Item 7 : ( ESNUG 355 #9 ) DC, Multiple Clocks, RTL MUXing For Scan Testing
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 356 Item 1 ) --------------------------------------------- [8/03/00]
Subject: ( ESNUG 355 #13 ) 2nd Plea For Help On Opposite-Input Tri-states
> In the "early" days of ESNUG there was a thread talking about a Synopsys
> bug concerning the usage of tri-state buffers that have 2 enable inputs
> that require opposite logic levels. I just ran into the same problem
> and am trying to find a solution. Was there a solution posted (that I
> didn't find)?
>
> I tried to use the 'pin_opposite' attribute in the library but Design
> Compiler failed to map the tri-state buffers. I tried the 'x_function'
> with the same result. I tried the 'contention_condition' with the result
> that Design Compiler mapped the tri-state buffers but tied one input to
> VCC (as it did without any special attribute).
>
> I think there must be someone who has solved this problem.
>
> - Volker Rzehak
> Texas Instruments Deutschland Germany
From: Volker Rzehak <v-rzehak@ti.com>
John,
Unfortunately I didn't receive any feedback from my post on ESNUG and I'm
not able to solve the problem up to now. I am quite stuck. The only
solution I can think of at the moment is either to do it manually or use
tristate buffers with one input (and bigger area requirements). Help!
- Volker Rzehak
Texas Instruments Deutschland Germany
( ESNUG 356 Item 2 ) --------------------------------------------- [8/03/00]
Subject: Cadence Diva LVS Tricks For Differentiating Identical Devices
> I have a little problem, I made a layout of a circuit which is symetrical
> in architecture but not in parameters: A differential input with 2
> resistors load. The only difference is transistor width.
>
> When I do a LVS, the netlists don't match, the netlister would want me to
> invert my 2 transistors. When I add an output pin, the problem is solved
> (the circuit becoming non-symetrical).
>
> Anybody know how to do to solve this problem without adding a new pin??
>
> - Sami Aissa
> Matra Nortel
From: Jay Lessert <jdl@teleport.com>
Since you haven't told us what tool you're using, the tool-independent way
is: Simply label (not pin) one of the internal nodes in both the schematic
and layout.
- Jay Lessert Portland, OR
---- ---- ---- ---- ---- ---- ----
From: Jim Thompson <Jim_T@analog-innovations.com>
Yep, that's the way I do it. Although sometimes even that doesn't work, so
the layout guy and I work in concert and add dummy resistors (metal) to
trick the LVS software into looking from the right direction.
- Jim Thompson
Analog Innovations, Inc. Phoenix, AZ
---- ---- ---- ---- ---- ---- ----
From: Michael Salvo <salvom@prodigy.net>
I'll assume were talking about a Cadence LVS run with Diva here, and add one
more possibility. Using Diva LVS, you can attach a "signature" property to
extracted devices when running Diva EXT.
(You should be able to find exact syntax on Cadence Openbook or SourceLink.)
This assigns a unique integer to each instance. In theory, if all the
parameters match for two instances of the same device, the devices are
identical anyway, and you aren't worried about it.
You could set it up by saying some variable "X" is your integer, and given
"w" (width) & l(length), you can do something like X=int(w*1e6 + l). Make
sure, just in case, you don't set this up so that different values of w & l
can yield the same "X". The more CDF variables you can use, the more you
can rely on a unique result, and for practical purposes you should probably
try to incorporate any variables you would normally netlist. In practice,
if you set this up in a test case with all your process devices and a good
amount of symmetry, and add the signature rountines this way for devices
getting confused until it seems to clear up, you can probably eliminate LVS
confusion without needing to add labels.
Having said this, there are still two catches:
(1) Somewhere in the int() function or the Diva extractor, (maybe the
signature routine itself,) there is usually some roundoff error... you
can explore this further by just adding some printf's in your EXT file
if you need. You'll want to round *up* the total value before
truncating to an integer type. Round-off error occurs after 8 decimal
places, and if you're setting up your code to require a match within a
tight tolerance, it won't help you if your Diva decks tell you
"1+1=0". (Of course, Cadence says this isn't a big enough problem to
fix anytime soon, and doesn't see the urgency in having its multi-
million-dollar toolset *not* giving you "1+1=0" from roundoff... but
that's another story.)
(2) The signature routine will cause LVS error reporting to be changed,
and it will be less informative. At this point, for the "altered"
devices, LVS is comparing the device and its signature, not the device
and separate parameters...still you should quickly be able to find and
figure out what's the matter, and the goal of an accurate LVS run
that's easier to use to debug seems to me to be worth the sacrifice.
If you set up the signature routine correctly, all the parameter info is
there anyway, ready to use... you just have to look at it.
- Michael Salvo
---- ---- ---- ---- ---- ---- ----
From: Edward J Kalenda <ed@kalenda.com>
The LVS rule parameterMatchType can be used to differentiate between
otherwise identical devices. It works by allowing the user to generate an
integer value which becomes a device subtype, incorporated into the
signature of the device instance. The main problem with using this rule is
that it does not work very well in the following case.
Two resistors are in the layout and two are in the schematic. There is no
visible difference based on how they are wired. In the layout, one has a
value of 99 while the other has a value of 199. The schematic resistors
have the value 105 and 190.
Looking at this, you would say (being able to deal with fuzzy logic as
you are) the 99 goes with 105 and 199 does with 190. LVS, not being very
bright about things like fuzzy logic, does not use the parameters to
help it along. So you use parameterMatchType to help.
The formula chosen in the required SKILL function is fix(R/100.0) since
most of your resistors are under one thousand ohms. 99 become 0. 105,
190 and 199 all become 1. Now we have a resistor with subtype 0 and
three resistors with subtype 1.
LVS now guesses that the one layout subtype 1 resistors matches to one
of the two schematic subtype 1 resistors. It then sees that there are no
subtype 0 resistors in the schematic and never manages to match the
remaining layout resistor to anything. And, by random chance, it matched
the wrong schematic resistor when it made the guess.
Not very helpful.
Enter parameterMatchDegree. A rule which allows LVS to ask the user
SKILL function how well every possible pair of layout to schematic
devices match. Since the set on each side is relatively small, this does
not take long, and it does not change the device type. Sounds very
useful, sort of does that fuzzy logic thing, too bad it has not been
coded into LVS.
- Ed Kalenda
---- ---- ---- ---- ---- ---- ----
From: Michael Salvo <salvom@prodigy.net>
Pretty much, I agree with your analysis, and it points up *exactly* why you
need to be careful with signatures.
First, you can have two different resistors with identical R... which is one
reason I mentioned (and suggested) both "w" & "l" in my earlier letter.
Yes, it seems like overkill to some, but it's easy enough to add the 2-4
lines of extra code and make your LVS run more reliable.
Second, I wouldn't be truncating any part of the value of a netlisted
parameter used in the signature... I'd be more inclined to make it R*1 or
R*(10^(+int)) if I was going to use "R" at all. To make this scheme work,
you need to use all the precision on each netlisted variable that you can
get. If your grid is DSM, maybe you want to multiply W & l each by another
100 for the purpose of the signature routine... over and above the factors I
suggested earlier, that is.
Third, especially as you remove significant digits, you add to the
possibility of roundoff error. What you did was essentially reproduce the
issue I had with "1+1=0" in a different circumstance. (Actually, you give
1=1 and 1=0, which is a variation of the problem, but a more common version
that programmers run into with "int" or "fix" functions in many languages.
This should also tell you how cautious you have to be about this particular
problem.)
- Michael Salvo
---- ---- ---- ---- ---- ---- ----
From: Edward J Kalenda <ed@kalenda.com>
Unless you can get your resistors to be drawn to the exactly correct
value to match the schematic, you pretty much have to trim the low order
digits away or you won't get any match at all. That's part of the
problem with parameterMatchType, it actually changes the device type so
different subtypes cannot be matched.
Your proposal makes each resistor value into a separate subtype so there
is no possibility of slightly different values being matched. In most
rule decks I have seen, there is a tolerance built into the property
comparison routines to allow for small differences in the value between
the layout and the schematic.
By adding L and W, you actually restrict the designer even further. Not
only does the resistance have to be exactly correct, you also require
that the W and L be the same. No longer can the designer have any leeway
to make the device a little shorter and thinner or longer and wider to
accommodate the environment the resistor is drawn in. Bends in the
device are almost impossible since they change the final resistor value
for a given L and W. Perhaps you are not including the bend factors,
which reduces the accuracy of your extraction, especially for the
smaller valued devices.
Personally, I'd like to see more people asking for better algorithms in
LVS. Except for runtime issues, there is no reason LVS cannot try each
of the possible matches and use the one that results in the least number
of unmatched devices. Kind of like a chess program set to "annihilate
the human" does to find the best possible move. Couple that with helpful
hints like my suggested parameterMatchDegree rule and it may be able to
find the correct match every single time there is one, with tolerable
runtimes.
- Ed Kalenda
---- ---- ---- ---- ---- ---- ----
From: Michael Salvo <salvom@prodigy.net>
Again, there's a lot to agree with here, partly based on what you're trying
to do.
Still, using pcells and a fixed sheet rho, if you were to use "R" or
"Rtotal" for a resistor, calculating an exact value might be valuable. You
could actually use LVS as a tool to identify versions before and after
process changes, for example, and make sure you replaced obsolete devices.
My slant on this is to make the tool as accurate as you can make it, and
make sure the user doesn't get "false positives". (And why would you want a
different equation or different constants between layout and schematic,
anyway? You *should* be able to get exact matches.) My own concern
centers around this: allowing a match where none should exist.
I'll also say my experience is *not* writing Diva code for bleeding-edge,
hundred-million-transistor chips, where, if it runs at all, speed has to be
a priority, and you're probably talking about hierarchical over flat
netlisting.
As for defining "slightly different" resistor values, you can build a
tolerance into the code after getting as exact a match as you can in the
signature routine. As you pointed out, you've got to be careful about how
much precision you use, because you can get false matches or false
mismatches if precision and tolerance aren't set right. Also, because of
roundoff within Cadence tools, you have to have *some* tolerance in the
code. Period. I just prefer a small tolerance when I can get away with it.
I'd also agree entirely that bends make Diva extraction more
difficult...though not entirely impossible...but even if you consider this,
there are places out there that don't use snaking resistors or snaking
MOS's, and probably don't calculate metal resistances except for some
parasitic analysis that doesn't touch Diva. Or, you could have a (hidden?)
parameter in your schematic-side CDF that would let you backannotate R (or
other parameters) when you find out you have to add bends in a device being
extracted. (Obviously, that's not the ideal solution, but I think it may be
better than dummy components to force a match.) Regardless, there should be
an equation somewhere that tells you how to handle bends in calculations if
you use them, and, again, there are lots of different directions you can
take from there.
Ultimately, it's figuring out the best tools and methodology to do what you
need. And I think we've proved this is a fairly complex topic by how much
we've been writing on a side-topic to the original message.
And I will have to try your suggestion of parameterMatchDegree when I get a
chance...sounds like an interesting solution!
- Michael Salvo
---- ---- ---- ---- ---- ---- ----
From: Edward J Kalenda <ed@kalenda.com>
I wish you *could* try using parameterMatchDegree, but it is not in LVS.
It is a feature that I feel should be added as a replacement for the
almost totally useless parameterMatchType, which should be deleted.
- Ed Kalenda
( ESNUG 356 Item 3 ) --------------------------------------------- [8/03/00]
Subject: ( ESNUG 355 #3 ) Verplex, Synopsys Formality, and Scan/BIST/JTAG
> I was considering using formal verification. However some questions came
> to mind on how it actually works.
>
> Internal scan and boundary scan were inserted into the design using Test
> Compiler. At this point is it not true that the RTL and the gate netlist
> are no longer functionally equivalent? Does formal verification handle
> this effectivively. Also my ASIC vendor required that the ATPG vectors
> and a subset of the functional vectors be simulated at gate level using
> estimated pre-route delay for min and max conditions. So I had to spent
> a lot of CPU time doing simulations anyway. Is top level design
> verification the proper place for formal verification?
>
> - Lou Villarosa, Jr.
> Paradyne Corporation
From: Scott Evans <scott@sonicsinc.com>
When I used the Verplex software it handled it just fine. You had to tie
off the scan enable so functionally it becomes equivalent to the original
circuit. Not sure how the other formal tools handle this but I'm sure it
is similar.
- Scott Evans
Sonics Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: London Jin <jinl@taec.toshiba.com>
Hi John,
There are three modes in a design with JTAG and internal scan. They are
mission mode, JTAG mode, and scan mode.
Mission mode, namely, this is the mode you do not see JTAG logic and
internal scan paths. In other words, JTAG logic and scan paths are
transparent. How to get you to this mode? JTAG logic should be
transparent by default (IEEE 1149.1 Standard). You better verify your
TAP controller if your design does not behave in that way. You can force
your design to the mission mode by A) controlling the TRST pin (TRST =0)
if you have this pin, asynchronous reset; or B) controlling TMS = 11111
with 5 TCK's (synchronous reset) if you do not have TRST pin.
The way to control internal scan to get you to mission varies from scan
style to scan style. You need to control the scan enable pin if you use
MUXed-scan style so that it selects system data on the MUXed-scan cells.
With the above control, the design with both JTAG & internal scan should
be functional equivalent to the design without JTAG & internal scan.
That is how you run formal verification.
Regarding to ATPG vector simulation, please note that: 1) ATPG vectors
are generated in scan mode, not in mission mode; 2) ATPG vectors are
generated with the goal of fault detection, not the goal of functional
verification, although ATPG has to understand your logic to simulate the
fault effect.
- London Jin
Toshiba San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Erik Jessen <Erik.Jessen@Vixel.com>
Hi, John,
1) The final netlist should be logically equivalent to RTL, if scan/JTAG/
/nand-tree/BIST are all disabled. So you just need to do that in your
equivalency-checker script (my Verplex script for comparing a million-
gate ASIC (RTL v. final gates, with NAND-tree, JTAG, 8-chains of scan
with multiple clock domains is about 20 lines long, with 1 line per
JTAG/NAND/etc. to disable them).
2) You still need to simulate a subset of functional vectors, to make sure
that you didn't blow it in your static timing analyzer (it happens, esp.
if you missed a clock-domain interface)
3) You need to simulate a subset of scan vectors for the same reason
4) Definitely do equivalency checking! Our runs are around an hour, and
100% verify that the entire chip. How long would it take for you to
run ALL your sims at gate level? Days? Weeks? And you still would
only catch the bugs that you simulated, and watched for (so maybe 70%
of your design is tested).
We've caught problems with EC due to synthesis bugs, or due to places where
somebody had `ifdef in their RTL, hardcoding what gates to use, and the
gates didn't exactly match the functionality of the RTL. We might not have
caught this in sims, but Verplex definitely did.
- Erik Jessen
Vixel Corp.
---- ---- ---- ---- ---- ---- ----
From: Shamai Eisenmann <shamai@tiogatech.com>
Hi John,
You can set an input to a specific value in most EC tools. Set your
scan_enable and/or scan_mode pins to 0 (i.e. disable the scan chain) and
then your deign should be equivalent to the RTL.
- Shamai Eisenmann
Tioga Technologies
---- ---- ---- ---- ---- ---- ----
From: Pierre Monteil <pierre.monteil@st.com>
Hi John,
You have just to remove your scan outputs, and to force your scan_enable to
logic 0.... If you use Synopsys Formality, it can be a good way to reduce
run-time to remove local scan on each sub-bloc:
foreach all_blocs [ find_references CONT:/LIB_NAME/* -hier ] {
current_design $all_blocs
echo "design : $all_blocs
foreach scan_port [find_ports $scan_enable] {
set_constant -type port $scan_port 0
}
foreach scan_port [find_ports $scan_out] {
remove_object -type port $scan_port
}
}
On core design, we earn weeks of simulation... More than that, equivalence
checking is very fast for verifying automated/manual IPO.
- Pierre Monteil
ST Microelectronics Grenoble, France
---- ---- ---- ---- ---- ---- ----
From: [ Synopsys Support ]
John,
In response to this (ESNUG 355 Item 3), since I have done it may a time:
Set up your formal verification run so it is checking mission mode (Disable
scan & JTAG logic by setting proper values on SCAN_ENABLE and TMS/TDI)
using set_constant on the implementation design (POST SCAN netlist) then
perform the formal verification. This will verify that the mission mode
logic was not upset by the scan/JTAG insertion. JTAG & Scan functionality
will still have to be verified with vectors.
After this pass do not set any constants this will perform formal
verification on test mode & mission mode. Setting the constants is only
required for pre-scan vs. post-scan verification.
- [ Synopsys Support ]
( ESNUG 356 Item 4 ) --------------------------------------------- [8/03/00]
Subject: ( ESNUG 355 #2 ) Synchronizers & Timing Problems With Reset Trees
> I have a reset net in my design. I am using "set_ideal_net" command in
> Design Compiler, but I still see huge SN/RN to Q/QN delays in my SDF file
> for any FF connected to the reset net. My design is hierarchical. Does
> anyone know how to take care of this problem?
>
> - Hooman Dadrassan
From: Paul Zimmer <pzimmer@cisco.com>
This problem is probably that the reset net has a very large risetime. His
risetime value doesn't show up directly in the SDF (because SDF is only
delay information), but it shows up indirectly as very long setup/hold/prop
times on flops.
In your case, the slow risetime on the reset is causing the extraction tool
(the one that generates the SDF - I gather you are doing this with DC?)
to predict a long reset2q time.
If you are indeed using DC, you might try doing "set_drive 0" on the driving
cell's output pin and/or "set_resistance 0" on the net. This is assuming
that you have some other fix in mind for the real chip (like using a clock
tree macro).
- Paul Zimmer
Cisco Systems
( ESNUG 356 Item 5 ) --------------------------------------------- [8/03/00]
Subject: ( ESNUG 355 #17 ) Ways To Convert Xilinx Gates Into ASIC Gates
> I was just wandering if you know what the ratio of the newer FPGA gates to
> ASIC gates is? I have asked Xilinx but they couldn't tell me. I am new
> to the FPGA/ASIC process and am trying to come up to speed. Even a
> ballpark conversion ratio would be helpful.
>
> - Chris Frailey
> Motorola
From: Frank Emnett <frank@aiec.com>
John,
The number I use is about 5:1. Most recently, I had a 200K gate design
(including about 10% memory area) that filled up a Xilinx XCV1000 at 100%
utilization. Didn't use much of its memory resources, though. I've heard
similar figures from at least two other Xilinx users (4:1 or 5:1).
- Frank Emnett
Automotive Integrated Electronics Corp.
---- ---- ---- ---- ---- ---- ----
From: Jeffrey Ebert <ebert@sonicsinc.com>
John,
My favorite FPGA metric is the buildable system (BS) gate. Here is a usage
example from the inventor of this metric, Tim Colleran in Electronic News:
"By the way, did I mention that Actel will introduce it's new BS1000M
family next year, the biggest device has[sic] contains one billion
complete and total BS gates. Count them if you can!"
The full article can be found at the URL below, and it is well worth a read
by all your FPGA-using ESNUG readers.
http://www.electronicnews.com/enews/Issue/1999/05171999/20actas.asp
- Jeff Ebert
Sonics, Inc.
---- ---- ---- ---- ---- ---- ----
From: Lynn Reed <Lynn.Reed@tekmos.com>
Hi, John,
We have converted about 10 Virtex FPGAs into ASICs. We are seeing the gate
count conversion ratio running close to 1:1 using the Xilinx gate count in
the map.mrp report. This was not always the case. I believe it is due to
several reasons.
1. Better synthesis tools provide greater utilization efficiencies.
2. Increased RAM use in the designs. Small RAMs do not translate
efficiently into ASICs.
3. Increased use of Xilinx cores, such as FIR filters, which are very
efficient in using Xilinx resources.
Regards,
- Lynn Reed
Tekmos
---- ---- ---- ---- ---- ---- ----
From: Al Czamara <czamara@asic-alliance.com>
Hi, John.
Here's what I got from the Xilinx staff recently ...
We actually came up with a formula to report an equivalent ASIC gate count
from our mapping tools, the problem is that the formula actually looks at
the actual resources used in an FPGA. So, if you have a design that is
running through our tools, we will (in version 3.1i) report an equivalent
ASIC gate count. It basically assigns ASIC gate equivalents to each of the
elements that might have been used in the FPGA and is therefore pretty good,
but very design dependent. Here are the numbers that we use in reporting
ASIC equivalent gates for our designs:
Frag Virtex ASIC equivalent
gates
---------------------------------------
4-input LUT 6
4-input ROM 32
3-input LUT na
16x1 RAM 64
32x1 RAM 128
16 Shift Reg LUT 64
CLB flop 8
CLB latch 5
IOB flop 8
IOB latch 5
IOB Sync latch na
TBUF 3
Block RAM 16,384
BSCAN 48
Clk DLL 7,000
F5 MUX 3
F6 MUX 3
MUXCY 3
XORCY 3
I don't know if this helps or not. This is supposed to take into account
ASIC and FPGA routing factors, so you wouldn't need to adjust it in any way.
From my unscientific and very limited experience with the Virtex
architectures, the general rule of thumb that I've used is to take 2/3 of
the FPGA system gates and that roughly equates to ASIC gates (i.e., A V300's
300,000 system gates are about 200,000 ASIC gates). But as you can see,
depending on the design, YMMV.
- Al Czamara
ASIC Alliance
---- ---- ---- ---- ---- ---- ----
From: Ted Boydston <tboydsto@harris.com>
Hi John,
We have been converting ASICs to FPGAs for a while now. Typically we have
been seeing 20 Honeywell 0.35u SOI gates per Virtex slice. The spread I
have seen has been as low as 15 and as high as 30, depending on clock speeds
and how full the Virtex is.
If you do some quick math, one can calculate the typical ASIC gates for a
Virtex 1000, which has a 64x96 CLB array:
( 64*96 CLB )* ( 2 Slices/CLB )* ( 20 Gates/Slice ) = 245,760 Gates.
Note that this number excludes block ram, which we typically do not use.
Also, this is purely a Xilinx Virtex logic to Honeywell 0.35u SOI logic
comparison -- your ASIC vendor may differ a bit. If your wondering, as
Harris did, why that number is one-quarter the 1M system gates advertised,
blame Xilinx marketing: they love to include block RAMs when coming up with
that million gate "system-gate" number.
Typically, we divide the Xilinx-marketing-derived "system gates" (Xilinx
Virtex 1000 has 1M such system gates) by 8 to get actual place and routable
"gate array gates" (or about 125K gates). This leaves about 50% of the
device open for design expansion and fixes in the lab. It also provides
routing margin for faster designs. If you are sure that the size of your
array will not change, you could use a divide by 5 or 6 to get the gate
array gate number from system gates.
Xilinx has a detailed analysis of this very subject in an application note
at http://www.xilinx.com/xapp/xapp059.pdf. The application note only covers
XC4000 and XC5000 parts; however, you can extrapolate to Virtex parts
because a 4000 series CLB is almost equivalent to a Virtex slice.
Have Fun!
- Ted Boydston
Harris GCSD
( ESNUG 356 Item 6 ) --------------------------------------------- [8/03/00]
Subject: ( ESNUG 355 #14 ) Find The Driving Cell Of A Specific Net In DC
> It would be great if someone could help me on this. SOLVNET on the web
> hasn't been helpful... I am running Synopsys v1999.05. I would like to
> replace the driver of a a specific net in Synopsys' design, with a driver
> of my own choosing. It would seem I need to:
>
> 1. find the net ("find" command)
> 2. get the driving cell of the net
> 3. delete this cell ("delete_cell" command)
> 4. create a new cell and tie its ports to that of the old cell
> ("create_cell")
>
> It is easy to find the net, with the "find" command. However, I am having
> great difficulty getting the driving cell of the net, once I find the net.
> I can do an "all_connected" on this net, but that gives me a pin list, and
> it includes the loads of the net. I would like to get the driving cell of
> the net, so I can use it as an argument to "delete_cell".
>
> Can anyone tell me how to find the driving cell of a net, assuming I have
> found the net? FYI, we don't have the TCL license.
>
> - Matt Gavin
> Rockwell Collins
From: Bob Cook <rcook@avici.com>
John,
The following command will return the cell driving the net net_name.
cell_name = cell_of(all_fanin(-to find(net, net_name) -level 0))
By the way, if the new cell has the same pinout as the old cell,
you can use the change_link command to make the replacement.
(instead of delete_cell, create_cell, connect_net, ...)
change_link cell_name lib_name/lib_cell
Hope this helps Matt.
- Bob Cook
Avici Systems
---- ---- ---- ---- ---- ---- ----
From: Ken Scott <kenneth.scott@conexant.com>
Hi John,
Here is a script which gets Matt most of the way to finding the driving cell
of a net:
/* the -hier option causes all_connected to return the list */
/* of all pins connected to a net, no matter if they are in */
/* the current_design or in a lower level of hierarchy. It */
/* also prunes out any ports which may be connected to the net. */
pins = all_connected ( -hier find( net NETNAME ) );
/* you can narrown down this list to the single driver PIN by */
/* filtering on the direction of the pin attribute. */
out_pins = filter( pins "@pin_direction == out" );
/* now you need to do some perl magic, which I'm not so familiar with.
Take the output of the echo command: {cellname/pinname} and use
perl to:
1) remove the {}
2) truncate the "/pinname" from what remains
3) insert the remaining text into a command:
dc = find( cell "truncated_cell_name" ); */
echo out_pins > /tmp/foo
sh perl_script_here < /tmp/foo > /tmp/gor
include /tmp/gor
/* at this point, the variable 'dc' now represents the driving cell */
Hope this helps,
- Ken Scott
Conexant
---- ---- ---- ---- ---- ---- ----
From: Paul Zimmer <pzimmer@cisco.com>
John,
The short answer is, maybe you should look at the command "change_link".
If you can't use change_link (because the fct'ty doesn't match), you can
find the driving pin of the net by using:
filter(all_connected(the_net),"@pin_direction == out")
Hope this helps.
- Paul Zimmer
Cisco Systems
---- ---- ---- ---- ---- ---- ----
From: Brian Kane <briank@torrentnet.com>
John, I think
all_fanin -levels 0 -flat -to find(net, foobar) -only_cells
does what Matt wants.
- Brian Kane
Ericsson IP Infrastructure Silver Spring, MD
---- ---- ---- ---- ---- ---- ----
From: Oren Rubinstein <orubinstein@3dfx.com>
John, here's what Matt needs:
net_name = ...
drv_pin = filter(all_connected(net_name), "@pin_direction == out")
drv_cell = cell_of(drv_pin)
That should get him there.
- Oren Rubinstein
3DFX, Inc.
---- ---- ---- ---- ---- ---- ----
From: Jim Horning <jim.horning@lmco.com>
John,
I did this once upon a time, perhaps a variation will work for Matt.
current_design = widget
driver_cell = all_fanin(-to tclk -only_cells)
echo driver_cell > /tmp/dctemp.tmp
driver_cell1 = ""
driver_cell1 = execute( -s "sh ./script/strip_brace.pl /tmp/dctemp.tmp" )
remove_cell driver_cell
create_cell driver_cell1 mylib/inv6
connect_net "clk" (driver_cell1 + "/A")
connect_net "tclk" (driver_cell1 + "/Q")
set_dont_touch driver_cell1 true
Where strip_brace.pl was:
#!/usr/local/bin/perl
while (<>) {
s/[{}]//g;
print;
}
Good luck.
- Jim Horning
Lockheed-Martin
---- ---- ---- ---- ---- ---- ----
From: Tom Cruz <tomcruz@us.ibm.com>
Hi, John,
Below is a quick and dirty example script that will find the driving pin
on a net or list of nets (assuming there isn't more than one cell driving
the net.)
/* Enter the list of nets to change */
LIST_OF_NETS = { n1200 n1201 }
/* Get a list of instance on the net */
foreach(nt, LIST_OF_NETS) {
inst_list = all_connected(find(net,nt))
/* Loop through each instance on the net looking for the output pin */
foreach (item, inst_list) {
pin_dir = get_attribute(item, pin_direction)
if (pin_dir == "out" ) {
/* get the cell name */
drive_cell_tmp = cell_of (item)
foreach(drive_cell, drive_cell_tmp) { } /* knocks the
brackets off */
echo drive_cell "Is the driving cell for net " nt
/* Now do any disconnect, creates etc below */
} /* end if pin_dir */
} /* end foreach item */
} /* end foreach nt */
It should get you part the way there... (I added a few nets so I could
debug it.)
- Tom Cruz
IBM Microelectronics Division
---- ---- ---- ---- ---- ---- ----
From: Matt Gavin <mtgavin@collins.rockwell.com>
To: Tom Cruz <tomcruz@us.ibm.com>
Tom,
Thanks for your help. I am now able to get the driving cell, thanks. Now,
how do I get Synopsys to return the list of all pins on this cell? I need
this info so I can put the cell's fanin nets, on the new cell's fanin. (I
can do an "all_connected" on the cell's input pin, once I get it.)
Unfortunately, all_fanin and all_connected only work on pins and nets,
not cells.
This is harder than I expected!
- Matt Gavin
Rockwell Collins
---- ---- ---- ---- ---- ---- ----
From: Tom Cruz <tomcruz@us.ibm.com>
To: Matt Gavin <mtgavin@collins.rockwell.com>
Hi Matt,
Yes, it is a little more involved than one might think, but not impossible.
To answer your question, if you want to know the list of pins on a cell, do
this:
assuming the cell name is U13158
pin_list = find(pin,U13158/*)
Then pin_list will contain all the pins - for example:
{"U13158/Z", "U13158/A", "U13158/B"}
If you were trying to add it to the little script that I sent it would be
like this (after the section that says do any disconnects, creates etc */ )
pin_list = find(pin,(drive_cell + "/*" ))
echo pin_list
You still may have to use the synopsys execute command along with the unix
command cut to cut off the pin name and build a string for hooking up the
new cell.
Hope this helps
- Tom Cruz
IBM Microelectronics Division
---- ---- ---- ---- ---- ---- ----
From: Matt Gavin <mtgavin@collins.rockwell.com>
To: Tom Cruz <tomcruz@us.ibm.com>
Thanks Tom.
FYI, I figured out how to get pins from the cell, similar to what you
mentioned (use "find" after concatenating the cell with the star operator).
I found the solution on SOLVNET, ID Synthesis-167.html. You have to first
convert the cell to a string variable in order to concatenate the "/*" to
find the pins. They use the "foreach" command as a roundabout way of doing
this. Seems a bit ugly, but it works. At least it's not as ugly as
exiting to UNIX to have perl modify the cell name.
My script to replace Synopsys' buffer with my own, is now thus: All it
assumes is that the name of the net driven by the buffer, is c_clock.
/* convert clock buffer driving c_clock from cdqn0 to cdqn3 */
/* synopsys puts in the cdqn0 since it knows */
/* it is a clock */
/*-------------------------------*/
/* CLK_TOW cdqn3 (~166 loads) */
/*-------------------------------*/
/* find old cdqn */
drv_pin = filter (all_connected(c_clock ),"@pin_direction==out")
drv_cell = cell_of(drv_pin)
/* convert drv_cell to a string */
foreach(drv_cell_str,drv_cell) { }
/* connect driving cell's input to new buffers' input */
/* tie c_clock to new cell */
src_pin = filter (find (pin,drv_cell_str + "/*"),"@pin_direction==in")
create_cell clk_cdqn find(cell,Driver_lib + "/cdqn3")
connect_net all_connected(src_pin) clk_cdqn/A
connect_net c_clock clk_cdqn/Z
remove_cell drv_cell
set_dont_touch find(cell, clk_cdqn)
/* make sure it all worked */
all_connected clk_cdqn/A
all_connected clk_cdqn/Z
all_connected c_clock
No assumptions about the cell or pin names are made. This makes
the script very robust. (John - please post this to ESNUG for me - thanks
to everyone who helped me.)
- Matt Gavin
Rockwell Collins
( ESNUG 356 Item 7 ) --------------------------------------------- [8/03/00]
Subject: ( ESNUG 355 #9 ) DC, Multiple Clocks, RTL MUXing For Scan Testing
> My design is a multiple clock domain design. In scan mode, however, there
> is only one clock: master_clock from chip pin. In order to balance the
> clocks, I need to MUX all clocks including the master_clock.
>
> wire scan_clk = scan_mode ? master_clk : master_clk;
>
> Design Compiler recognizes that this is feedthrough logic, and thus no
> MUXing logic is generated at all. I talked to Synopsys tech support, and
> was told that there was no way to generate MUXing logic with the above
> code. I seeks for designers' help.
>
> - London Jin
> Toshiba San Jose, CA
From: Allen Brown <allen_brown@agilent.com>
John,
No problem for London. Just remember: hierarchy is your friend.
module part_including_clk_mux ( master_clk1, master_clk2, ... );
input master_clk1, master_clk2;
wire scan_clk;
scan_clk = scan_mode ? master_clk1 : master_clk2;
endmodule // part_including_clk_mux
module container_for_above (...)
wire master_clk;
part_including_clk_mux p1 (
.master_clk1(master_clk),
.master_clk2(master_clk), ...);
endmodule // container_for_above
Now synthesize part_including_clk_mux separately from container_for_above.
You will get your MUX.
- Allen Brown
Agilent Technologies
---- ---- ---- ---- ---- ---- ----
From: Steven Murphy <steven.a.murphy@lmco.com>
Hi, John,
The solution we used was to directly instantiate a MUX from the gate level
library. If you need to balance the delay to the different clock trees then
you will probably have to do the balancing by hand (we did) beyond just
adding the MUX. The clock tree balancer we used (LSI Logic) only handled one
clock domain at a time and did not balance across clock domains. If the
clock domains are of different sizes then the total delay difference through
the various clock trees can be very large. You should estimate the delay
difference now and add some delay buffers to the net list on the scan clock
input to each MUX. Again, directly instantiate gate level cells. These
buffers can then be moved around in the layout to finish the balancing.
Adding them now is much easier than adding them to the gate level netlist.
Also, be careful when it comes to buffering the scan_mode signal going to
the I/O pads for boundary scan. If you let Synopsys do the buffering without
floorplan information then you will end up with a real mess of the same
buffer driving different sides of the chip.
- Steven Murphy
Lockheed-Martin
---- ---- ---- ---- ---- ---- ----
From: Will Leavitt <leavitt@giganet.com>
Hi, John,
Clock control is too important to leave to synthesis. I would instantiate
the exact gates you want in the clock path. This gives you exactly what you
want, and you can give the gates nice repeatable instance names to
facilitate hand placing them during chip layout. Use an ifdef, so that
gates are used during synthesis and RTL is used for simulation, otherwise
you'll kill your simulation speed.
`ifdef synthesis_only
// synopsys dc_script_begin
// dont_touch u_master_clk_mux*
// synopsys dc_script_end
MUX21HC u_master_clk_mux (.A(master_clk), .B(master_clk),
.S(scan_mode), .Z(scan_clk));
`else
wire scan_clk = scan_mode ? master_clk : master_clk;
`endif
Good luck
- Will Leavitt
Giganet, Inc.
---- ---- ---- ---- ---- ---- ----
From: London Jin <jinl@taec.toshiba.com>
To: Will Leavitt <leavitt@giganet.com>
Hi Will,
Thank you very much for your offer. What I tried to avoid is to instantiate
a technology/vendor specific MUX in my RTL code in order to make the code
technology independent and portable in future. The best solution I have
found from solvit is to instantiate a GTECH MUX. I am still not very happy
for this solution either.
Thank you again.
- London Jin
Toshiba San Jose, CA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 11,000+ other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@world.std.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
