From: bdb91@aol.com ( true name unknown )
John,
Amazing, I could not have come up with a better quote than the one I
saw from you in EE Times. No, not the one about Cadence being a
monopoly, anyone with any knowledge of the industry simply disregards
your rhetoric as coming from a very small man. I am talking about the
"morality is irrelevent" line. How clueless a man are you? You write
that and then have the nerve to sponsor a childrens charity banner on
the bottom of your home page.
You handed me a gift. I could not have come up with anything funnier
or more degrading to yourself! Your quote is now plastered on the
signature of every email I send out. You are given full credit of
course.
Thank you, Thank you, Thank you.
- [ Unsigned ]
( ESNUG 372 Subjects ) ------------------------------------------ [05/31/01]
Item 1 : Wall St. Curious About Numerical/Cadabra/Avanti/Mentor RET Tools
Item 2 : What Linux Processors, Motherboards, Version Of Linux Do You Use?
Item 3 : What's It Like Using PhysOpt With Standard Cells And 100+ SRAMS?
Item 4 : ( ESNUG 371 #2 ) Tricks For Undoing PhysOpt Clustering Congestion
Item 5 : ( ESNUG 371 #17 ) Why Buy A 16550 UART When You Can Get It Free?
Item 6 : ( ESNUG 370 #1 ) Avanti P&R Can't Do Ultima ClockWise's Output
Item 7 : Users OK With Avanti News, But Silicon Perspectives Is Screwed
Item 8 : ( ESNUG 371 #7 ) Oops, Actually Formality Can Handle 2D Arrays!
Item 9 : ( ESNUG 371 #4 ) PhysOpt Workarounds For Bidirectional Ports
Item 10 : ( ESNUG 371 #11 ) Verplex Takes Minutes When Formality Takes Days
Item 11 : The 4 GB PhysOpt Memory Limit & How To Reduce PhysOpt Memory Usage
Item 12 : ( ESNUG 370 #12 ) How To Design A Synthesizable Link List FIFO?
Item 13 : Avanti Does NOT Hold Us Hostage Any More Than Synopsys/Cadence Do
Item 14 : Annoying Verilog Netlist Read Problems With Design Compiler 00.05
Item 15 : ( ESNUG 370 #3 ) DC Instance Names Having Device Types In Them
Item 16 : ( ESNUG 365 #9 ) Chip Express Clock Buffer Insertion Nightmare
Item 17 : ( ESNUG 371 #6 ) TimeMill Troubles Reporting Transition Times
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 372 Item 1 ) -------------------------------------------- [05/31/01]
From: Jennifer Jordan <Jennifer.Jordan@blak.com>
Subject: Wall St. Curious About Numerical/Cadabra/Avanti/Mentor RET Tools
Hi John,
Who, if anyone, is using Numerical Tech's tools for RET? I see Cadabra
gaining traction in standard cell building, but all the sparkle around
Numerical is about strong phase shifting. So who's using Numerical RET
and how are the RET tools stacking up compared to Mentor and Avanti's
RET offerings?
- Jennifer Jordan
Sr. Equity Research Analyst
Wells Fargo Van Kasper Portland, OR
( ESNUG 372 Item 2 ) -------------------------------------------- [05/31/01]
From: [ Chicken Little ]
Subject: What Linux Processors, Motherboards, Version Of Linux Do You Use?
John,
We're _exclusively_ a Sun (1000's of 'em) house, a decree from on high,
because [ reason deleted to preserve anonymity]. Moving to Linux/PC
hardware is a very hot political potato at this company. I don't want
to attract any heat. Just looking for some information.
I hope you can understand my position and keep me anonymous.
I'm interested in what Linux hardware people are running:
1.) Which Processors, motherboards, amount of memory, are you using?
2.) Which flavor of Linux are they running?
3.) Single/multi-processor boxes?
Can you organise a poll, John?
- [ Chicken Little ]
( ESNUG 372 Item 3 ) -------------------------------------------- [05/31/01]
From: Qi Chen <qchen@gennum.com>
Subject: What's It Like Using PhysOpt With Standard Cells And 100+ SRAMS?
Hi, John,
There are a lot of SRAM macros (over 100) in our design, and around 20% of
die size is used for standard cells. Does anyone has experience with
PhysOpt to optimize the design like ours?
- Qi Chen
Gennum Corp.
( ESNUG 372 Item 4 ) -------------------------------------------- [05/31/01]
Subject: ( ESNUG 371 #2 ) Tricks For Undoing PhysOpt Clustering Congestion
> Though our design's overall row utilization is low, about 55%, PhysOpt
> (since it doesn't have real global routing) keeps clustering cells to
> create very high density areas. This happens with -congestion option,
> even when we leave empty space around the cluster. This congestion makes
> our design unroutable.
>
> - [ Shrek's Donkey ]
From: [ Synopsys R&D ]
John,
Let me be absolutely clear. We have a global router within PhysOpt to
estimate congestion. Our customers have run 170+ designs through PhysOpt
and our congestion analysis correlated very well with IBM, Avanti, and
Cadence detailed routers. To use our global router, set congestion_effort
to [low | medium | high]. The higher you set it, the more detailed (but
more CPU intensive the congestion estimates are.)
As for [ Shrek's Donkey ], I am sorry that he is having so much trouble.
There are a number of reasons this may be happening and various antidotes.
One way to avoid congestion and limit clustering is to use the following
switch:
set_congestion_options -max_utilization 0.85
The default is 0.95 and the user should try some lower values (0.85 is in
the example). Also, there are a number of articles in Solvit on techniques
to avoid congestion which may help this user.
- [ Synopsys R&D ]
---- ---- ---- ---- ---- ---- ----
From: Wei Chen <chenw2@sd.conexant.com>
Hi John,
I am a PhysOpt user, and have seen the same clustering especially on low
utlization floor plans with tight timing constraints. Synopsys does
provide a command called set_congestion_options which is very usefull. This
command has several options: -horizontal, -vertical, and -max_util
I have, so far, only used the -max_util option which turned out to be very
successful. The value of max utilization can be rather delicate, small
variations can cause long run times. The option does not take effect
unless the -congestion option is used during compile.
- Wei Chen
Mindspeed Technologies, a Conexant Business
( ESNUG 372 Item 5 ) -------------------------------------------- [05/31/01]
Subject: ( ESNUG 371 #17 ) Why Buy A 16550 UART When You Can Get It Free?
> Recently I encountered the Ketchum tool you mentioned in your SNUG'01
> Trip Report. We were using DW_16550 UART in our design, and during usual
> simulation process, I uncovered few functional bugs. We were close to
> the tape out, so the situation was very tense, but, luckily, Synopsys's
> designers came up with a quick fix. It would be better not to have bugs
> in Synopsys DW IP at all, but "nobody's perfect".
>
> - Vladimir Sindalovsky
> Agere Systems
From: Rudolf Usselmann <rudi@asics.ws>
John,
Here is another work around:
Go to http://www.opencores.org and download a FREE 16550 compatible UART
(includes all source code).
- Rudolf Usselmann
---- ---- ---- ---- ---- ---- ----
From: Vladimir Sindalovsky <sindalovsky@agere.com>
John,
As for the bugs and fixes for DW_16550, John, you know that DesignWare HDL
is encrypted, and the only description I can try to fix is synthesized
netlist. That is why I relied 90% on Synopsys to fix the bugs I reported.
The only one I was able to fix myself was related to asynchronous ISA
interface. It was a commonplace error made in synchronizing ISA read and
write strobes. The signals were sampled once on the rising edge of internal
clock, and after that ANDed with the asynchronous strobe itself in order to
derive trailing edge of a strobe. Due to the asynchronous nature of the
strobes the resulting signal has a possible duration from 0 to one period
of internal clock. It was easy to additionally synchronize ISA signals in
DW_16550 wrapper, so now it is a two-stage shift register, and the trailing
edge pulse is always one period wide. However this imposes a limitation on
the minimum duration of the strobes as well as back-to-back timing, ISA bus
is slow enough in respect to the internal clock rate, so this cheesy fix
can be used.
The other bugs I found (which has been already fixed by Synopsys) are:
1. When different sources of the host interrupt are enabled, and multiple
events causing the interrupt occur, read of IIR (Interrupt
Identification) register causes not only the highest priority interrupt
to be cleared, but Transmitter Holding Register Empty (THRE) interrupt
source to be cleared too. When all other sources of interrupt are
cleared, THRE does not cause the interrupt, although this source is
enabled. IIR register reflects a No Pending Interrupt condition
under these circumstances. Line Status Register (LSR) still shows a
correct THRE status in bits 6 and 5.
2. This bug is a real deja vu because I helped to fix the exactly same bug
in the chip released several years ago. Bits 2, 3 and 4 in LSR are set
when a word at the top of RX FIFO has a break indication, framing error
or parity error correspondingly. Normally those bits are latched on the
read of the previous word from RX FIFO. However, if RX FIFO is empty
and the first character written into it has one of the mentioned errors,
it is immediately moved to the top of RX FIFO, and error bits has to be
latch on FIFO write rather than FIFO read. This bug exhibits itself under
described circumstances as an RX FIFO error bit (bit 7 in LSR) being set,
and neither one of bits 2, 3 or 4 ever set to a one.
The bugs, supposedly found by Ketchum, will be fixed in couple of weeks,
and the list of bugs was published by Synopsys in ESNUG last week.
- Vladimir Sindalovsky
Agere Systems
( ESNUG 372 Item 6 ) -------------------------------------------- [05/31/01]
Subject: ( ESNUG 370 #1 ) Avanti P&R Can't Do Ultima ClockWise's Output
> Through ESNUG 352, I heard of Ultima Tech's Clockwise tool. I evaluated
> it about 8-9 months ago. Clockwise is a piece of junk. It's a clever
> idea, but the interfaces to other tools are extremely unstable. While
> passing data back-and-forth from Ultima to Avant, I ran into several
> issues. The Ultima support staff provided 2-3 patches within 2 weeks
> of our eval to fix these problems. I just don't know how they can sell
> this tool. Maybe now they've improved it.
>
> - Himanshu Bhatnagar
> Conexant
From: Jon Stahl <jstahl@avici.com>
Hi John,
At the time I used Clockwise it was at the early stages of their inital
release, and (as I stated in what I wrote to ESNUG) I also ran into
several bugs. The interface I used was one I wrote to get into LSI Logic's
internal tools (they were not using Avanti at the time) and it was trivial
to do. Himanshu used ClockWise with Avanti -- not me -- I used ClockWise
with LSI internal tools.
I do know that ClockWise was originally written to work with Cadence, and
that Avanti was to be a later bolt on.
ClockWise worked for me on a design I was having major problems getting
timing closure on (saved me more than 1 ns) and we have working silicon
back. But, again, this wasn't with Avanti tools.
- Jon Stahl
Avici Systems N. Billerica, MA
( ESNUG 372 Item 7 ) -------------------------------------------- [05/31/01]
Subject: Users OK With Avanti News, But Silicon Perspectives Is Screwed
> Given the recent developements in the Avanti/Cadence lawsuit(s) this week,
> how many of you expect to be using Avanti tools a year from now? In your
> opinion, are we going to end up back in the days where Cadence owns the
> monopoly in backend tools (yet again)?
>
> - John Cooley
> the ESNUG guy
From: [ Intel Inside ]
John,
Please keep me anon as usual...
I don't think anyone has a monopoly in backend tools, but Avanti seems to be
the leader. Naturally, Cadence is going to attempt to financially destroy
them with civil litigation. I doubt this will impact Avanti AE support
because it would have to first "exist" to be effected... :)
All things considered, I'm sure I'll still be using Avanti P&R and
verification tools this time next year. Am I supposed to stop using them
because of their ethical digressions? Yeah, right. Also, since the state
of the economy is putting most company's budgets on a lean diet, it will be
difficult for Cadence to gain back any market share this year. Smaller,
younger (and cheaper) companies will probably be pretty busy at DAC.
Cadence has damaged their image much like Mentor did with their Falcon
Framework fiasco in the early 90's. Cadence's Integration Ensemble is at
least the third time where they have said, "We have the solution that merges
the logical and physical!" What the hell happened to their prior platforms?
They didn't work as advertised. How many times did the villagers listen to
the little boy who cried "Wolf"?
- [ Intel Inside ]
---- ---- ---- ---- ---- ---- ----
From: Nir Sever <nir@zoran.co.il>
Hi John,
I'm not an Avanti user myself, but I wouldn't go and switch my physical
design tools because of the recent court plea. The investment is too big,
and I'm sure that when the day will come for Avanti to pay, the court will
consider the situation the Avant customers face and will make sure Avanti
and their customers can survive.
Other than that, Cadence isn't the only other player. Synopsys is becoming
more and more dominant in the physical design world, and so are Mentor and
other smaller players (Sequence, Simplex, Magma, Monterey and others).
- Nir Sever
Zoran Corp. Israel
---- ---- ---- ---- ---- ---- ----
From: Gary Smith <gary.smith@gartner.com>
Hi, John,
Avanti's biggest problem is not the damage award to Cadence, it's getting
the IP Implementation tools out on the market. If they don't introduce a
physical synthesizer soon they are likely to lose the backend business to
Magma, Monterey, Synopsys (once Route66 ships) and Cadence. The size of
the award to Cadence is still being decided but the tobacco cases of the
mid-90's and the more recent breast implant settlements have not bankrupted
the companies that were found guilty. The court system seems to working
towards keeping existing businesses out of bankruptcy.
- Gary Smith
DataQuest San Jose, CA
P.S. John, why is it that everyone that wants to see Avanti killed off are
all liberal Democrats that oppose the death penalty for people?
---- ---- ---- ---- ---- ---- ----
From: Phil Hoppes <phoppes@intersil.com>
Hi, John,
I have to believe EVERYBODY knew Avanti was guilty. Guilt wasn't the point.
Cadence back end tools sucked and Avanti was the only sane choice if you
wanted to get the job done without doubling your staff and dumping your
bank account in support fees.
Today, at least we see some promise with Monterey, Magma, and heaven forbid,
maybe even Synopsys if they can ever get their act together and get a
detailed router. There are more choices today than there were 5 years
ago. What will be interesting will be to see just where this all goes.
Fast Forward. Avanti loses to Cadence. Avanti files Chapter 11. Synopsys
buys Avanti router technology for 5 cents on the dollar. Synopsys finally
gets the router it's been looking to buy from VLSI a.k.a. Compass (a.k.a.
Avanti.)
- Phil Hoppes
Intersil
---- ---- ---- ---- ---- ---- ----
From: Paula Jones <paula@newiic.com>
Hi John,
Hope you've been following the San Jose Mercury News' coverage of the Avanti
verdict. See http://www0.mercurycenter.com/business/top/083028.htm
Yesterday's Dan Gilmore's column was great, too:
http://cgi.mercurycenter.com/premium/business/docs/gillmor23.htm
It's titled, "Maybe we need a corporate death penalty". He thinks Avanti,
as a company, should be broken up.
- Paula Jones
---- ---- ---- ---- ---- ---- ----
From: [ Beach Bum ]
John, anon please.
An interesting sidebar to this whole Avanti fiasco is how it affects Silicon
Perspective. Gerry sold his buddies down the river for his get-out-of-jail-
free card. Meanwhile, the buddy that got the longest potential jail sentence
(6 years in prison) is Mitch Igusa, who is also the chief architect at
Silicon Perspective. What happens to that company's products if Mitch's
sitting in jail for 6 years?
- [ Beach Bum ]
( ESNUG 372 Item 8 ) -------------------------------------------- [05/31/01]
Subject: ( ESNUG 371 #7 ) Oops, Actually Formality Can Handle 2D Arrays!
> I'm using in my VHDL code 2 dimensional arrays. For example:
>
> type t_array is array(natural range <>) of std_logic_vector(7 downto 0);
> signal s_array : t_array(15 downto 0);
>
> Our formal verification tool, Formality, has a hard time with signals like
> this. Our support guy from Synopsys rewrote the 2D arrays to a 1D array:
>
> std_logic_vector(127 downto 0)
>
> Now Formality can handle the design. He recommended not to use 2D arrays
> in future designs, either in Verilog or VHDL.
>
> I find that some Synopsys tools are not that great on VHDL. DC and
> Formality still don't support all of VHDL-93. Further, some VHDL-93
> constructs that are supported by DC are not supported by Formality. So
> that makes me wonder what peoples experience is with other formal
> verification tools with respect to 2D array's.
>
> - Menno Spijker
> Mitel Semiconductor Ottawa, Canada
From: [ A Formality CAE ]
Hi, John,
Menno's code is, in fact, supported by Formality.
Here is an example that uses the VHDL type and signal exactly as submitted.
This example is fully supported in Formality:
library ieee;
use ieee.std_logic_1164.all;
USE IEEE.std_logic_unsigned.all;
entity regarray is
port( a : in std_logic_vector (7 downto 0);
clk : in std_logic;
index : in std_logic_vector(3 downto 0);
dout : out std_logic_vector (7 downto 0));
end regarray;
architecture one of regarray is
type t_array is array(natural range <>) of std_logic_vector(7 downto 0);
signal s_array : t_array(15 downto 0);
begin
process(clk)
begin
if(clk'event and clk='1') then
s_array(conv_integer(index)) <= a;
end if;
end process;
dout <= s_array(conv_integer(index));
end one;
There are however, multiple ways to code arrays in VHDL. Maybe Menno just
gave the wrong example. Currently, neither DC (2000.11) nor Formality
support the following syntax for multidimensional arrays:
type m_array is array(15 downto 0, 7 downto 0) of std_logic ;
In addition, VHDL93 support (same subset as DC) will be available with the
Formality 2001.08 release in August.
- [ A Formality CAE ]
---- ---- ---- ---- ---- ---- ----
From: Raimund Soenning <raimund.soenning@philips.com>
Dear John,
In January, while still at my former company, I made an evaluation of 3
formal verification tools (Avanti Design Verifyer, Verplex Tuxedo, Mentor
FormalPro). None of them could actually resolve the 2-D array problem
either but only when DC transformed them into 1-D arrays during synthesis.
On the other hand the problem is very easy to overcome by writing some
nice mapping rules - just one line per array. This applied for all 3 tools.
- Raimund Soenning
Philips Semiconductor Starnberg, Germany
( ESNUG 372 Item 9 ) -------------------------------------------- [05/31/01]
Subject: ( ESNUG 371 #4 ) PhysOpt Workarounds For Bidirectional Ports
> We currently have an issue with Synopsys Physical Compiler not fixing hold
> time violations on bidirectional ports. It seems clear that PhysOpt
> understands what the violations are; we don't understand why they are not
> being fixed.
>
> - Dave Dixon
> Micron
From: [ A PhysOpt AE In The UK ]
Hi, John,
A couple of months ago I had to explain this to a customer and provide him
a workaround to the problem. I enhanced this and created a SolvNET article
which you can find with the keywords 'hold' and 'bidir'.
QUESTION:
Is there any way I can get Design Compiler (& PhysOpt) to fix hold-time
requirements on bidirectional ports?
ANSWER:
Currently Design Compiler (& PhysOpt) is incapable of fixing hold-time
requirements that are placed on a bidirectional port. The best solution to
this problem is to use separate input and output ports rather than a
bidirectional port.
At the top level, you can combine the separate signals into a combined
three-state bus.
If, however, you do not want to change the code, there might be a solution
that allows you to fix hold-time within Design Compiler (& PhysOpt).
Consider the following design, which has one cell driving the bidirectional
port. This bidirectional port has a (minimum) constraint placed on it
through set_output_delay. The driving cell is a library cell or subdesign
called BIDI.
signals in my module bidirectional cell or design port
/---------\
write_signal >>----------------| |
| BIDI |-----------<<>> bidir port
read_signal <<----------------| |
\---------/
|
direction >>--------------------/
The write_signal, read_signal, and direction commands are signals used
inside the module. To fix hold-time violations on these interface paths,
you can use a method that temporarily splits the bidirectional port by
putting this driving cell in a higher-level design. Now you can easily fix
(recalculate) the hold-time, after which you place the BIDI driving cell
back into the design.
Here are the steps.
1. First, constrain the design as usual, by using create_clock,
set_output_delay, and so on.
2. Group all cells, excluding the bidirectional drivers, in a separate
level of hierarchy, and characterize this level to get the correct
constraints:
group [get_cell -filter {@ref_name!=BIDI}] -design temp -cell itemp
characterize itemp
current_design temp
3. After you enable hold-time fixing, compile:
set_fix_hold [all_clocks]
compile -only_design_rule
4. Go back to the original design and ungroup:
current_design test
ungroup -simple itemp
This article is Methodology-224.html, the title is "Design Compiler Not
Fixing Hold-Time on Bidirectional Port" and applies to PhysOpt as well.
I hope this helps, John.
- [ A PhysOpt AE In The UK ]
( ESNUG 372 Item 10 ) ------------------------------------------- [05/31/01]
Subject: ( ESNUG 371 #11 ) Verplex Takes Minutes When Formality Takes Days
> Concerning run time performance we have seen a significant improvement in
> the recent year and some designs that used to be inconclusive now succeed.
> I'm talking about Formality 1999.10-FM1.0 vs. Formality 2000.05-FM2.0.
>
> I can give you some examples: one design was a RTL-to-Gate ~40K gates. It
> used to be inconclusive and now passes in ~2.5 hours. Another Gate2Gate
> design that was inconclusive now passes in 2 days. In this case I have
> just the container sizes around 20Mb (~500K gates). Often divisions send
> us containers in order not to make the code available. In effect this is
> a strange case for Gate2Gate but I think that designers took the first and
> the last version of gate netlists through a very complex flow.
>
> In these experiments we run Formality on the same machine: Sun Solaris
> 248MHz with 3.5 Gb memory.
>
> - Umberto Rossi
> STMicroelectronics Agrate Brianza, Italy
From: Tom David <tomd@cygnal.com>
Hi John,
With respect to the gentleman from ST's comments about Formality: here's
some live data from Verplex-LEC for a just completed design.
Design: about 44K gates with gated clocks and scan. (There were 2,917
comparison points.)
a) Gate-to-gate comparisons run in approx 7 mins on an Ultra II-300MHz
with 512MB.
b) Gate-to-RTL runs in approx 57 mins on an Ultra II-440MHz with 512MB.
The RTL and gates don't have exactly the same hierarchy either since
some blocks get flattened in our synthesis tool.
The above machines run Sun OS 5.6.
- Tom David
Cygnal
[ Editor's Note: Yes, Verplex has a rep for being much faster, but
since this isn't a case of running the same design on both Formality
and Verplex, it's somewhat misleading. Just my $.02. - John ]
( ESNUG 372 Item 11 ) ------------------------------------------- [05/31/01]
From: [ A PhysOpt AC in Chicago ]
Subject: The 4 GB PhysOpt Memory Limit & How To Reduce PhysOpt Memory Usage
John,
I thought your readers doing big designs with PhysOpt might be interested
in some tips for reducing the amount of memory PhysOpy uses. Our advertised
capacity for Physical Compiler for gates-to-placed-gates runs is around 350K
instances (due to the current 4 GB memory footprint), but this capacity can
be influenced by a number of things. Here's what you need to check if you
need to squeeze the memory required for your design:
1. Command-line switches: Make sure that you are using the appropriate
switches for your design. The high effort, congestion, and area
recovery switches can be useful in some situations but do come with
a memory (and runtime) penalty.
2. Constraints: Just like Design Compiler and PrimeTime, path exceptions
can consume large amounts of memory. Be on the lookout for excessive
use of wildcards. Maybe you were overconstraining as part of your DC
synthesis strategy, but now that you are using actual placement-based
delays in PhysOpt, some of those constraints are no longer needed.
Critical range can also cause increased memory use because it forces
PhysOpt to simultaneously optimize more than just the worst path.
Don't just think of timing and DRC constraints -- physical constraints
like the "set_bounds" command take memory as well. Make sure they are
needed before you use them. They cost memory!
3. LEF detail for black boxes: If you have access to it, look at the LEF
for cells like RAMs and cores and see how detailed it is. If you're
treating the entire area of the cell as a complete obstruction, there
is little to be gained by having detailed modelling of every metal
shape. If you see this, work with your layout folks to get a better
(less detailed) abstraction of the cell.
4. Unusable routing layers in LEF: The LEF usually represents all of the
routing layers available for a given technology. In many cases, not
all of these layers are intended to be used for signal routing. Look
especially for names like M0 or METAL0, which are likely not true metal
layers. You get two big benefits from removing these types of layers.
First, they often have different RC characteristics from the other
layers which can skew the automatic calculations PhysOpt does. Second,
this will reduce the number of layers the router within the tool has to
account for, with a corresponding reduction in the memory usage.
5. Filler cells: Check your floorplan to see if you are using filler cells
to act as obstructions. Memory efficiency is much improved if you
remove them and represent them in one of two different ways available
within PhysOpt:
Method 1: Use the create_obstruction command to define them as
placement or routing blockages
Method 2: If the fillers are being used in the neighborhood of a
fixed cell like a RAM, use set_keepout_margin to define
an area where cells are completely prohibited (i.e.,
"hard" keepout) or discouraged (i.e., "soft" keeout)
6. PNETs: If the die area is not highly utilized, you can remove some of
the PNETs. Start with the PNETs that connect power to the standard
cells since they do not affect the placement of the cells. Try to
leave in any PNETs that do restrict placement. You can also consider
modelling the PNETs as complete obstructions via the create_obstruction
command.
7. Die area: Again, for low utilization designs, remove some of the area
available for placement. It's best if you can actually remove site
rows from the floorplan, but the create_obstruction command is another
option. Make sure to also remove any PNETs in the obstructed area to
get further memory savings.
Follow these 7 steps, John, and you'll maximize your PhysOpt memory usage.
- [ A PhysOpt AC in Chicago ]
( ESNUG 372 Item 12 ) ------------------------------------------- [05/31/01]
Subject: ( ESNUG 370 #12 ) How To Design A Synthesizable Link List FIFO?
> Do you know anybody who has designed a synthesizable link-list FIFO?
> Would they like to share your code with me? I would also like to know
> how a link-list FIFO is different from a regular FIFO and their
> advantages/disadvantages.
>
> - Kusuma Arkalgud
> Jasmine Networks
From: Tom Coonan <Thomas.Coonan@Sciatl.com>
Hi, John,
We have such beasts here at Scientific Atlanta, but I don't think I can
share them. Sorry. I think the idea in our case was how to efficiently
deal with many multiple channels of data that all need a FIFO. For example,
imagine a DMA type of module that supports 32 channels. A FIFO is required
for each channel. The straight-forward tact is a dedicated FIFO RAM per
channel which probably means 32 RAMs all sized to handle the maximum
conceivable depth. This is perhaps wasteful and you end up with a lot of
distinct RAMs which may have layout or test implications. Alternatively,
use a single RAM and linked-lists for sharing the storage on an as-needed
basis. You literally implement a FREE list and a USED list and your FIFO
ADD/GET operations translate into list insertion and removal operations.
Each "channel" has its own registers pointing to the FREE/USED lists. Not
much different from the SW-based linked list code. State machine logic is
perfectly capable of doing all this.
If you can statistically garuntee that the sum total "depth" across all
channels is much less than the sum of all your worst-case FIFO depths; then
maybe you have saved a lot of RAM. There is data overhead in the RAM for
all the pointers and flags. You also are sharing/arbitrating access to the
single RAM, of course. This adds significant complexity and is much more
slippery to analyse from a systems perspective, so I'd recommend you
consider this very, very critically. You may be trading something
deterministic for something statistical. Sort of like how many Embedded
Systems programmers tend to shy away from using the heap unless absolutely
necessary. Good luck.
- Tom Coonan
Scientific Atlanta
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys DW AE ]
Hi John,
There is a synthesizable Linked-List FIFO controller in the DesignWare
Foundation library (DW_llfifocntl_s1_df). It can support up to 16
independent queues in the same physical memory. Hopefully this saves
Kusuma a considerable amount of design effort.
If he doesn't have the online docs handy, he can access SOLD (Synopsys
On-Line Documentation) from SolvNET. Just log into
http://solvnet.synopsys.com/
and click on "Search Documentation" in the upper right. He wants the
DesignWare document collection, under "2000.11/Other Manuals/DesignWare".
- [ A Synopsys DW AE ]
---- ---- ---- ---- ---- ---- ----
From: Atul Bhalla <atul@0-in.com>
Hello John,
Regarding Kusuma'a request for a Linked List FIFO, he may be able to find
something at http://www.opencores.com/projects.shtml
In order to verify his Linked List FIFO, try one of our monitors at:
http://www.0-in.com/subpages/prodtech/0in_cw_monitors.html
- Atul Bhalla
0-In Design Automation San Jose, CA
( ESNUG 372 Item 13 ) ------------------------------------------- [05/31/01]
Subject: Avanti Does NOT Hold Us Hostage Any More Than Synopsys/Cadence Do
> Dan's experience isn't unique. "Just don't heap too much praise upon
> Avanti until you get to know them," warned Dale Lomelino of Philips
> Semiconductors. "If anything, they have more warts and blemishes than
> Synopsys and Cadence combined. Avanti does not want to support standard
> formats like PDEF or LEF/DEF. Instead, they prefer to lock you into
> their 'unified binary Milkyway database' -- and hold you hostage."
>
> What use is any Best In Class P&R tool if you can't interface to it?
>
> - from "That Other Avanti Issue" ( EE Times 5/07/01 )
From: John McGehee <johnm@voomtown.com>
Hi, John,
Lately I have been reading in ESNUG users having trouble interfacing to
Avanti tools. Interfacing any two tools is difficult, but I do not think
that interfacing to Avanti is any harder than to other tools.
It's my job at Voom to build a multi-vendor flow that tapes out chips. I
do this using industry standard formats supported by Avanti, like Verilog,
Synopsys .lib, LEF, DEF, SPF, SPEF, SDC, SPICE, and GDSII. Set them up
right, and these formats provide the interfaces required for tapeout.
The most important unsupported format is PDEF3, but your web site provides
a PDEF3 translator implemented in Scheme at
http://www.deepchip.com/downloads/PhysOptAvanti.zip.
The PDEF3 translator worked great for me on a recent tapeout using Synopsys
PhysOpt with Avanti Apollo.
If you need more data from Milkyway, you can extract it using Scheme. When
someone needed a PDEF3 translator, they just wrote one. I see no
unsurmountable problems here.
- John McGehee
Voom, Inc.
( ESNUG 372 Item 14 ) ------------------------------------------- [05/31/01]
From: "Neel Das" <neel.das@corrent.com>
Subject: Annoying Verilog Netlist Read Problems With Design Compiler 00.05
Hi John,
We found a bug in the Verilog netlist read function in Design Compiler.
This bug doesn't affect RTL reads. Synopsys is looking into this as well.
1. This is the command that I've used with v2000.05:
dc_shell-t> read_file -f vl_netlist A.v
Loading vl_netlist file 'A.v'
Error: read format 'vl_netlist' is no longer supported.
Please use 'read -f verilog -netlist' instead. (VERIL-1)
Error: Can't read 'vl_netlist' file 'A.v'.(UID-59)
No designs were read
2. However, when I tried to use their 'suggested' command, it didn't work!
dc_shell-t> read -f verilog -netlist A.v
Error: wrong # args: should be "read channelId ?numChars?" or "read
?-nonewline? channelId"
Use error_info for more info. (CMD-013)
3. Here's what worked:
dc_shell-t> read_file -f verilog -netlist A.v
Loading verilog file 'A.v'
Performing 'read' command.
Compiling source netlist file A.v
New Verilog reader completed successfully.
end
Current design is now 'A.db:A'
A
dc_shell-t>
So, if you're reading in a Verilog netlist, please use the 3rd option.
- Neel Das
Corrent Corporation
( ESNUG 372 Item 15 ) ------------------------------------------- [05/31/01]
Subject: ( ESNUG 370 #3 ) DC Instance Names Having Device Types In Them
> Do you think Synopsys could be convinced to do something more meaningful
> with device instance names other than U1, U2 and U3? Wouldn't U_nand2_0
> and U_NR4B_33 be more meaningful?
>
> - Iain Clark
> LSI Logic
From: Nir Sever <nir@zoran.co.il>
Hi John,
Why would you need to code the device type in the instance name? The next
argument in the instantiation statement IS the device. I prefer having
the instance name to represent the place in the hierarchy from which this
instance was created.
- Nir Sever
Zoran Israel
---- ---- ---- ---- ---- ---- ----
From: Leo Butler <lbutler@brocade.com>
To: Iain Clark <irc@lsil.com>
Hi, Iain.
Saw your name in lights, had to write to hassle you. ;-)
Sounds like a job for a Perl script to me. I have some code that reads LEF
and builds a cell library database, which could be used in conjunction with
parsing the Verilog netlist and finally renaming any instances of cells that
were in the LEF (LSI's cells, for instance) to include the cell name.
I wouldn't want to use this for layout, but for reporting it ought to be
fine. My issue with using it for backend is the name length. I've run into
issues where database size was affected by long instance names. Some tool
coders just don't understand the concept of a hash to avoid such issues...
Last thought, perhaps lsinetlist could be updated to do this, too. We all
want a tool to read a netlist and create a data structure, and it would be
great if there was then an API to allow you to write some code to manipulate
the database. More Perl, perhaps? :-)
- Leo Butler
Brocade Communications San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Iain Clark <irc@lsil.com>
To: Leo Butler <lbutler@brocade.com>
Leo,
I certainly recognize the possibility of internal tools but that's not
efficient nor elegant but in my mental model of the perfect universe the
tool vendor addresses the customer's needs. If I were to build this thing,
I'd make it uniquify every instance name as well. I think I'm only adding
about 7 chars per name. Right now, I'd only make it operate on leaf level
cells. I might make it spit out the maximum name mength as well.
Can you expand on your last paragraph somewhat? It may be that lsivega
is the better place for this functionality.
- Iain Clark
LSI Logic
---- ---- ---- ---- ---- ---- ----
From: Leo Butler <lbutler@brocade.com>
To: Iain Clark <irc@lsil.com>
Hi, Iain.
Agreed, lsivega is probably the perfect place for it. The idea being we all
want to read a netlist and do "something" to it; how nice to have that
functionality handled for us and then provide an API to access/manipulate
the data structure.
I'm not sure what issues you run into while reading the netlist with the
less-descriptive names, so I don't have any specific solutions. Just
curious, have you ever used Debussy? It is more than a waveform viewer;
it reads the netlist and traces paths into and out of hierarchy. Pretty
cool, used over here for debugging all the time.
Just a thought.
- Leo Butler
Brocade Communications San Jose, CA
---- ---- ---- ---- ---- ---- ----
From: Pinhong Chen <phchenb@tsmc.com>
Hi, John,
I saw Iain's email to ESNUG with a title "Why can't DC instance name have
device name in them?". Well, you can use the following perl script to
modify your gate-level netlist:
#!/usr/bin/env perl
$/=";";
$dont=0;
while(<>){
if(/(\w+)\s+(\S+?)\s*\(/o){
$dev=$1;
$iname=$2;
if($dev ne "module"){
$iname =~ s/\bU(\d+)/U_${dev}_$1/o;
s/(\w+\s+)(\S+?)(\s*\()/$1$iname$3/o;
}
}
print;
}
Hope this helps!
- Pinhong Chen
TSMC San Jose, CA
( ESNUG 372 Item 16 ) ------------------------------------------- [05/31/01]
Subject: ( ESNUG 365 #9 ) Chip Express Clock Buffer Insertion Nightmare
> Chip Express claims that Synopsys should be able to automatically insert
> the (correctly sized) buffers for us. (Larger buffer sizes are used for
> larger clock domains). However this has never worked for us. This is
> SUPPOSED to work through two mechanisms: the 'max_capacitance' attribute,
> and the 'connection_class' attribute. Their library puts a
> connection_class of CLOCK_NETWORK on all its flop clock inputs (and
> NO connection class on its combinatorial cell inputs). The clock buffer
> output also has the CLOCK_NETWORK connection class. So Design Compiler
> should (in theory) use one of these clock buffers to fix connection_class
> violations on clock nets, and the correct size will be chosen via the
> max_capacitance attributes on the buffer output. ...
>
> Does anyone have a remedy for this? We are at our wits' end here, and
> we get VERY little support from Chip Express.
>
> - Matt Gavin
> Rockwell Collins
From: Robert Wiegand <RWiegand@NxtWaveComm.com>
Hi John,
I used to deal with Chip Express library issues my previous life at Creative
Labs. At the time I used the cx2001 library, but many of the hand repairs I
had to do migrated into their newer libraries as well.
First of all, to address the clock tree issues, I would NOT allow Synopsys
to attempt to insert Chipx's buffers. Instead, I would have a dedicated
clocks block, a pads block, and the chip core instanced from the top level.
In the clocks block, I would hand instantiate the required buffers for clock
and reset trees. At the time, Chipx did not want to deal with scan enables,
so I let Synopsys buffer them for me. The pads block had all the required
pad cells instantiated. The core was compiled with ideal clocks, but
defined to account for insertion delay and skew (this was very important for
multiple and divided clocks). One nice thing about these clock and reset
buffer cells, is that they were actually correltated to post layout results.
This would allow me to propagate my clocks at the full chip level pre-layout
to do any final fixes before shipping the netlist. To battle the
connection_class problems, I would eliminate them when I set up the library
as follows:
(I would set the cell_library variable to the name of the library being
used, and of course make sure the commands work before using the /dev/null
redirection)
echo "***********************************************************"
echo "*** Setting up ideal clock drivers and cells ***"
echo "***********************************************************"
remove_attribute cell_library + "/*/CP" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/CPN" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/G" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/GN" connection_class -quiet >
/dev/null
dont_use cell_library + "/cdq*" > /dev/null
echo "***********************************************************"
echo "*** Setting up ideal reset drivers and cells ***"
echo "***********************************************************"
remove_attribute cell_library + "/*/CLN" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/PR" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/*/PRN" connection_class -quiet >
/dev/null
dont_use cell_library + "/rdq*" > /dev/null
echo "***********************************************************"
echo "*** Fixing clock and reset driver attributes ***"
echo "***********************************************************"
remove_attribute cell_library + "/cdq*/A" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/cdq*/Z" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/rdq*/A" connection_class -quiet >
/dev/null
remove_attribute cell_library + "/rdq*/Z" connection_class -quiet >
/dev/null
There were other problems with the library that I would fix as well. Chipx
would try to control fanout with capacitance only, making any max_fanout
commands useless. There was no default fanout load attribute in the libray,
and some -- but not all -- pins had a 0 fanout_load attribute. That means
that you could drive thousands of these pins and Synopsys would not even
know it! Here's how I fixed that:
echo" ** Fixing fanout_load attributes on library cell input pins **"
set_attribute filter(find(pin,cell_library + "/*/*"),"@fanout_load ==
0.000000") fanout_load 1 -quiet > /dev/null
Another problem was one particular cell's output pin didn't have a
max_fanout attribute set on it. Here's how I fixed that:
set_attribute cx2001_core/iv10d/Z max_fanout 6 -type float
Hope this help!
- Bob Wiegand
NxtWave Communications Langhorne, PA
( ESNUG 372 Item 17 ) ------------------------------------------- [05/31/01]
Subject: ( ESNUG 371 #6 ) TimeMill Troubles Reporting Transition Times
> I want to know if TimeMill can report nets with transition time greater
> than a specific threshold value. If so, which version of the TimeMill
> release can do this?
>
> - Raj Sayana
> MoSys, Inc. Sunnyvale, CA
From: [ A TimeMill CAE ]
John,
Nets with transition time greater than a specific threshold value can be
reported using the report_node_u command. Also, worst case rise/fall time
estimation can be done using the report_node_maxrf command. These commands
are available in version 5.2 and above.
Syntax:
report_node_u [status=1|2] [u_time=rf_time] [no=node_name1]
[no=node_name2] [except=node1]
OR
report_node_u [status=1|2] [rise=r_time] [fall=f_time]
[no=node_name1] [no=node_name2] [except=node1]
command
argument definition
-----------------------------------------------------
1|2 1: checks only nodes with fanout
(default if no nodes are specified)
2: reports all nodes
rf_time max time specified nodes can remain in
U-state before being reported (default = 5ns)
r_time max time a node's rising edge can remain
in U-state
f_time max time a node's falling edge can
remain in U-state
node_name* nodes to be diagnosed
node* nodes excluded from operation
Note that the U-state threshold voltages can be controlled with the
set_node_thresh command.
Example1:
report_node_u u_time=2.7ns no=adder.*
This example reports U-state warning for all matched nodes staying in
U-state longer than 2.7ns.
Example2:
report_node_u rise=3.5ns fall=2.7ns no=adder.*
This example reports U-state warning for all matched nodes staying in
U-state on the falling edge longer than 2.7ns or on the rising edge longer
than 3.5ns.
Syntax:
report_node_maxrf thresh_time node_name(s) [except=node1]
command
argument definition
-----------------------------------------------------
thresh_time rise/fall time threshold
node_name(s) nodes to be diagnosed
node* nodes excluded from operation
Example:
report_node_maxrf 5ns *
This example checks all nodes for worst-case rise or fall times exceeding
5ns. The worst-case rise/fall estimation uses total lumped capacitance of
the node and the effective resistance of the least conductive element
channel connected to the node.
- [ A TimeMill CAE ]
---- ---- ---- ---- ---- ---- ----
From: Raj Sayana <raj@mosys.com>
Hi John,
Please thank Synopsys for the information. I've found report_node_maxrf
gave very erroneous results. Perhaps they should either fix it or disable
the command. report_node_u is on the fly measurement & hence more accurate.
- Raj Sayana
MoSys
---- ---- ---- ---- ---- ---- ----
From [ Epic Support ]
Hi, Raj,
report_node_maxrf could be screwed up because it actually does the
estimation job according to node lump C value. And report_node_u is
checking during simulation while monitoring real transition time.
Thanks for your feedback!
- [ Epic Support ]
============================================================================
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
|
|
