> I have used IEEE Term Life insurance (great rates!) for the last 20
> years. In 1998, they changed underwriters and instituted a 20% discount
> for non-smokers. Apparently they sent out a notice that this was going
> to happen and that the DEFAULT for all current insureds was that they
> were SMOKERS. If you were not a smoker you were supposed to proactively
> notify them. On the policy renewals that are sent semi-annually there
> is no indication that you are classified as a smoker. Long story short,
> I reviewed my recent renewal, thought the rates were high and went to
> the web site to get an on-line quote. There was a big difference in the
> price (about 20%) so I called and found out that since 1998 I have been
> charged the SMOKERs rate!
>
> I inquired about a refund for the excess premiums - no deal. If any of
> the ESNUG subscribers signed up for this insurance prior to 1998 then
> they should check to make sure that their smoking status is correct.
>
> - Dave Peeters
> Crest Microsystems Cerritos, CA
From: David Guan <David_Guan@pmc-sierra.com>
Hi, John,
I was in the exact same boat about one year ago. I argued with them on
two counts:
a) I never received the so called "notice";
b) The smoking status does not show up in the renewal notice.
Long story short: after sending two faxes (that were "not received" :)
and talking to three supervisors, finally I told them that I gave them
15 days to fix it. I threatened to file a complaint to the state
insurance department if it is not fixed.
I also told them that if they fix it, I will increase my coverage.
They fixed it in 2 hours! But it took two more months before the refund
was sent back to me. Dave may want to try to talk to a supervisor again.
- David Guan
PMC-Sierra
---- ---- ---- ---- ---- ---- ----
From: Mary Harris <Mary.E.Harris@jhuapl.edu>
Hi, John,
Thanks for passing this along. I just checked my rates and found that
I could have saved about $100 per year. Up until a few years ago,
that would have covered my annual IEEE membership fee!
- Mary Harris
Johns Hopkins University Applied Physics Laboratory
( ESNUG 402 Subjects ) ------------------------------------------- [10/23/02]
Item 1: Your Old Custom Cell Libraries & Newer Synopsys Versions Won't Mix
Item 2: Newbies Discuss Cadence Silicon Ensemble / Virtuoso / DW Basics
Item 3: ( ESNUG 401 #6 ) Flip Your DUT & Reference When Using Formality
Item 4: Cadence Virtuoso 4.4.5 "Segmentation Faults" When I Widen Clk Nets
Item 5: Small Company Needs Low Cost Linter, Wonders About Cadence HAL
Item 6: ( ESNUG 400 #13 ) Get UNIX Shell Capabilities In Synopsys Tools
Item 7: A Report On What Went On At Last Month's Magma User Group Meeting
Item 8: ( ESNUG 400 #15 ) Formality vs. Chrysalis & What About FormalPro?
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 402 Item 1 ) --------------------------------------------- [10/23/02]
From: Joe Gilray <jg@cvs.agilent.com>
Subject: Your Old Custom Cell Libraries & Newer Synopsys Versions Won't Mix
John,
Be careful when using old custom cell libraries with newer versions of
Synopsys tools.
We had an old custom cell library that we had used successfully for a while,
but when we switched to PrimeTime v2002.03-SP1 (or v2002.09) we found that
the SDF generated was very different from that generated by v2001.08-SP1-1.
We were seeing net delays that were in the -100 ps range and quite a few
RC-005 warnings.
With the help of the Support Center we tracked the problem down to the fact
that our custom cell library didn't have the voltage defined so PrimeTime
was using the default value of 5V! This problem didn't show up in older
versions of PrimeTime because they used only one set of thresholds.
You can check your libraries with 'report_lib' or by using:
report_delay_calculation -thresholds
which showed the following for our case (note the from-pin voltage)
Calculation Rise Rise Fall Fall Slew Rail
Thresholds: Delay Slew Delay Slew Derate Voltage
----------------------------------------------------------------
from-pin 50 20->80 50 80->20 1.000 5.000
to-pin 50 20->80 50 80->20 1.000 1.080
Another way to work around the problem is to use:
set lib_thresholds_per_lib false
but I hesitate to suggest it as a long-term solution as it could cause
analogous problems when there *are* libraries with individual thresholds.
The online docs for lib_thresholds_per_lib are very useful, too.
- Joe Gilray
Agilent Technologies Corvallis, OR
( ESNUG 402 Item 2 ) --------------------------------------------- [10/23/02]
Subject: Newbies Discuss Cadence Silicon Ensemble / Virtuoso / DW Basics
> I am a new user of Silicon Ensemble. I read up the documentation on it,
> but still had a few basic questions about it. I am trying to see if I
> could use just the router to route a placed design of mine. Could someone
> tell me if I still need to create both the LEF and DEF files, if so, is it
> possible to create these from the layout (having the design to be routed)
> and the technology file respectively?
>
> Can I do away with the timing and the constraints file, because all my
> routing will be very simple without any timing goals? What would be the
> essential files for a route to be performed in my case?
>
> - S. Hemanth
From: Regis Caillet <regis.caillet@dspfactory.ch>
Yes, you can use wroute in stand alone. You give it the LEF, DEF & wroute.cfg.
LEF gives it all information on the process technology, cells, memories and
other stuff. DEF gives the placement of your cells, memories, pad, size of
floorplan, the ring of alimentation and the netlist. Wroute.cfg indicates to
wroute where to find the files, how you want to route and other stuff.
How did you create your floorplan, placement ?!
- Regis Caillet
DSP Factory Switzerland
---- ---- ---- ---- ---- ---- ----
From: S. Hemanth <shemanthk@yahoo.com>
Hi Regis,
Regarding your question about my floorplan or placement, depending on the
circuit, the positions of the various components are fixed and I draw this
floorplan or placement out in Virtuoso. Then I somehow want to be able to
use this for routing. I plan to use SE wroute in a synthesis flow with
different sizes for the components, with the placement being fixed. Is it
possible not to generate the LEF and DEF files everytime, but just do it
once and use them with parameterized sizes? Also, do you know if I can
automatically produce the LEF file from the technology file?
- S. Hemanth
---- ---- ---- ---- ---- ---- ----
From: Regis Caillet <regis.caillet@dspfactory.ch>
To produce your LEF file, you can read all your individual LEF files into SE
and export it into one big file out. SE exports a LEF file, but it is in
binary, not ASCII that you can read.
import lef filename "directory/name_tech_file.lef" ; [always the first]
import lef filename "directory/name_cells_file.lef" ; [as you want th order
for the others one]
import lef filename "directory/name_memories_file.lef" ;
import lef filename "directory/name_pads_file.lef" ;
...
Why don't you just make your floorplan with SE ?!
- Regis Caillet
DSP Factory Switzerland
---- ---- ---- ---- ---- ---- ----
From: Shrirang Yardi <syardi@hotmail.com>
Hi,
I am also a new user to Cadence SE. I read the documentation and found that
one needs to have a gds2.map file to export your layout from SE to Virtuoso.
I am not able to find the gds2.map file in my Cadence installation. Is this
file supposed to be provided by the vendor?
- Shrirang Yardi
---- ---- ---- ---- ---- ---- ----
From: Muzaffer Kal <kal@dspia.com>
If you have the technology information from your foundry you should be able
to generate the gds2.map file yourself. Basically open the library LEF
file, look at the header to see the names of metals and vias then find the
process manual to see which layer numbers they use for those layers and put
them in the gds2.map.
- Muzaffer Kal
DSPIA Inc.
---- ---- ---- ---- ---- ---- ----
From: Han Speek <Han.Speek@philips.com>
Hi, Yardi,
The gds2.map file you need for this is technology-dependent, so if it's at
all provided it should come from the foundry (assuming you're using a design
kit, it should be part of that). But there's a good chance you'll have to
make your own. Have a look at the stream layers section of the tech file
for the info about how layer names and purposes map to numbers.
But why are you using gds2 anyway to take the design back to Virtuoso?
Normally the DEF format is used for this, and you can write that out without
any additional technology file. Then in Virtuoso, do an "Import DEF", and
you'll end up with a layout that has the cell abstracts. Then, from the top
menu bar, do a "Floorplan -> Replace view" to swap the layouts in for the
abstracts (don't forget to select "all" !), and finally select "Layout" from
the Tools menu to get the normal layout editor menus back.
Then, if gds2 is required anyway, you can now simply stream out the layout
view using the CIW Export Stream functionality.
- Han Speek
Philips
---- ---- ---- ---- ---- ---- ----
From: Regis Caillet <regis.caillet@dspfactory.ch>
Yardi, you should see on cadence web site:
http://sourcelink.cadence.com/docs/db/kdb/1999/Dec/1836672.html
It's in SourceLink.
- Regis Caillet
DSP Factory Switzerland
---- ---- ---- ---- ---- ---- ----
From: Dmitriy Shurin <shurin@bgumail.bgu.ac.il>
Hi,
I have a digital library that includes all the necessary files for working
with SE and Synopsys, but the layout cellviews for basic cells were not
supplied. After I was done with SE, I tried to transfer the result into
a layout editor, but since my layout view is absent, I get a huge number of
warnings and (of course) no layout. The problem is that not only the layout
of basic cells is absent, but the *routing* that was made by SE is also
missing! Is it possible that the layer/purpose of the routing made by SE
is metalX/net and not metalX/drawing or is there another reason my routing
is also absent in LE?
- Dmitriy Shurin
Ben Gurion University Israel
---- ---- ---- ---- ---- ---- ----
From: Paul Fields <psf2001uk@yahoo.com>
Hello Dmitriy,
There should be a GDS II stream-map file that SE reads when it writes-out
the GDS II data from the routed design. Maybe you already got this with the
library, or maybe you will need to write this yourself.
You should also check that this layer mapping (e.g. metal1 = 14) matches the
technology file and mapping file you use in your layout editor. If these
are consistent, at least you will be able to see all of the metal and via
layers created by SE.
I don't know if you are using the Cadence Virtuoso layout editor. If you
are, what you could do is to make a libary called myLib, attached to the
technology file for your process, and stream-in the GDS II of your library
cells into here. If you have RAMs or other blocks, you might want to make
other libraries for these. Then, stream the GDS II file written by SE into
another library, and reference the libraries myLib, myRAM, etc., when you
stream-in. In the File/Import/Stream.../Options form, set:
Retain Reference Library (No Merge) - YES
Reference library order myLib myRAM myADC
Use a space-seperated or comma-seperated list.
OK this, then OK stream-in form - PIPO.LOG will show:
(inv1/layout) - (referenced, but not defined, no data created)
(dffr/layout) - (referenced, but not defined, no data created)
When streaming-out your design, to make a "full" GDS II file, do not select
"Retain Reference Library (No Merge) - then stream-out will write-out ALL
cells.
- Paul Fields
---- ---- ---- ---- ---- ---- ----
From: Alistair McEwan <alistair@robots.ox.ac.uk>
Hi,
What is a clock root net (or pin)? SE reports that it cannot find one in my
design when I try to run clockroute. Is this the recommended way to route
the clock or should WROUTE be used just selecting the clock net?
I used PRflattern to generate an autolayout of my design and the
FloorplanP&R|Silicon Ensemble to set the vdd! and gnd! nets special. Then
I exported to a DEF. There is a line in the macro file provided by the
fab which states "change net '<Netname>' use clock ;" SE didn't understand
this so I edited the DEF in a text editor and added the line + USE CLOCK
to the CLK net section. I don't have a verilog model of my design either
so I disabled all the verilog parts of the macro file. The CTGen section
works fine. I've given the slew rate, delay and waveform constraints for
the root_iopin 'clk' in the ctgen constraint file.
But as soon as the macro file reaches clockroute it complains that it cannot
find any root clock nets or pins. I read a very old post that warned that
clockroute is not the router of choice, but rather to use WROUTE just on the
clock net. This just seems to treat my clock net as a regular signal net
which is not acceptable as the path width is minimum and therefore will not
be able to carry the required current.
Every tutorial I've read doesn't seem to cover clock generation. Does
anyone know of one that does?
- Alistair McEwan
Oxford University England
---- ---- ---- ---- ---- ---- ----
From: Regis Caillet <regis.caillet@dspfactory.ch>
To route your clock with Wroute, you need to change this variable before you
actually lauch wroute itself:
SET VAR WROUTE.SELECTNET.FIRST true ; -- indicates to route a categorie
of nets before the others
SET VAR WROUTE.SELECTENETS "@clock" ; -- which nets or type of nets to
route in first
When you applied CTGen on your design, at the end it propose to load the
change of the netlist (with the gui). If you use CTGen in stand alone, you
need to import the change manually after CTGen.
- Regis Caillet
DSP Factory Switzerland
---- ---- ---- ---- ---- ---- ----
From: Chenbo Liu <philewar@icc.sh.cn>
Hi, folks,
For saving the cost in mask, one customer choose to route their design with
one metal layer in Silicon Ensemble. It seems impossible unless you do it
by hand. But I'm not sure and turn to you for help. Any suggestions?
- Chenbo Liu
Bentium, Ltd. China
---- ---- ---- ---- ---- ---- ----
From: Han Speek <Han.Speek@philips.com>
Hi,
I don't think that can really be done. You "need" a second routing layer,
even if only to make crossings over your power lines. You could use
polysilicon as the second routing layer - but SE isn't really very good at
that. :-( And generating proper abstracts for routing with poly isn't
quite trivial either. In fact, I'm not convinced that it can even be
done with Cadence's current routing tools.
So to summarize:
1) you need a second routing layer to make crossings in your routing
and
2) you have to pick that second layer with the tool's capabilities in
mind.
My choice would be to go for a second metal layer.
- Han Speek
Philips
---- ---- ---- ---- ---- ---- ----
From: Paul Fields <psf2001uk@yahoo.com>
Generally, you would use poly as the "second" layer. Obviously, given the
much larger sheet rho of poly (maybe 30 Ohms per square, vs. 30 milli-Ohms
per square for metal), you need to be very careful to avoid the use of poly
in clock lines (maybe route the clocks first so they can use metal wherever
they go, or hand-wire in a dedicated metal clock wire in each channel, and
tap it directly into each flop clock input).
SE certainly **used** to support 1.5 routing layers (i.e. 1 metal + 1 poly)
in the technology set-up you could raise the cost of using poly so that it
was only used for short hops. You would use metal to route along the
channels, and then poly to cross between different tracks in the routing
channel, and hook up to cell inputs/outputs.
This was pretty much standard practice with the older (cheaper) processes in
the 1 to 3+ micron size. Blocks were much smaller of course, so you could
manually inspect clocks and critical paths after routing.
I used to dream of 2 layers of metal....
- Paul Fields
---- ---- ---- ---- ---- ---- ----
From: Chenbo Liu <philewar@icc.sh.cn>
My design is about several K gate counts, and my question is if it's a must
to ungroup all Synopsys DesignWare components before going into SE. Or can
SE handle it all the same?
- Chenbo Liu
Bentium, Ltd. China
---- ---- ---- ---- ---- ---- ----
From: Arvin Patel <apatel@chello.no>
Hi Chenbo
There should be no need to ungroup DesignWare components before reading the
netlist into SE. SE flattens the design anyway after it has been read in.
However you might want to ungroup the DesignWare components anyway, not
because SE needs it, but because Design Compiler can optimise the logic
further to possibly produce a better result after ungrouping the DesignWare
(DW). Note that this means that information about DW is lost and any
optimisations by changing DW components architectures is not possible.
- Arvin Patel
Chello Broadband Norway
( ESNUG 402 Item 3 ) --------------------------------------------- [10/23/02]
Subject: ( ESNUG 401 #6 ) Flip Your DUT & Reference When Using Formality
> On a recent project we completed a 7 M gate design in 0.13u technology.
> The front-end team used Formality for formal verification & during the
> back-end work that I participated in we used Verplex LEC. I was surprised
> that we uncovered some floating signals (inputs to an ARM core) in the
> netlist that was not detected by Formality. I am not sure if this was an
> operator error or a lack of capability in the tool.
>
> - Urban Jangren
> QThink
From: Glen McDonnell <gmcdonne@ati.com>
John,
I have some feedback for the author of ESNUG 401 #6: We Found Verplex LEC
Caught Some Errors That Formality Had Missed
The default behavior for Formality is to treat an undriven net as 'X'. If
this 'X' makes no difference on the vectors, then the verification still
succeeds. As an example, if the reference and implementation designs both
leave the input floating, then it is still a successful verification.
Formality does in fact report floating pins, but not as an verification
error. In the "formality.log" file for the session, there will be a message
"Info: Reference pin <pin> is undriven." Unfortunately, for some reason it
only reports on the reference design. Since the distinction is arbitrary,
I like to reverse what you would normally be the reference/implementation
designs so I get the undriven pin check on the version of the design that
is closest to tapeout.
- Glen McDonnell
ATI Technologies
( ESNUG 402 Item 4 ) --------------------------------------------- [10/23/02]
Subject: Cadence Virtuoso 4.4.5 "Segmentation Faults" When I Widen Clk Nets
> I'm trying to widen the paths of my clk net in Virtuoso. I thought I
> could do this by choosing Connectivity | Mark Net but cds445 completely
> crashes with 'segmentation fault' when I try this. Anyone know why?
> (It works for much smaller nets, my clk net sees at least 100 gates.)
>
> More importantly is there another way to select all the paths of a net and
> increase their width? I've tried Edit | Search but there doesn't seem to
> be a field for Net Name when selecting paths. Is it possible in Floorplan
> P&R | Silicon Ensemble?
>
> The problem arose because I didn't mark the clk net as a special net
> before P&R in SE, so the path widths are all minimum. Is there a good
> guide anywhere on how to do clock routing properly and how to mark the
> clock net before creating the DEF?
>
> - Alistair McEwan
> Oxford University England
From: Andrew Beckett <andrewb@cadence.com>
Hi Alastair,
I found a problem reported where Mark Net crashes if you are doing Mark net
during an edit-in-place. This was fixed in subversion 4.4.5.100.22 (you can
check by using the Help->About... menu in the CIW).
I found another PCR which was fixed in 4.4.5.100.14, too.
You might also want to check your OS patches with the checkSysConf utility
(you probably will have to go via EuroPractice to get an up to date version
of this from SourceLink).
I thought there was a search criteria for net name on the form. However,
you could always just do something like:
net=dbFindNetByName(geGetEditCellView() "yourNetName")
foreach(fig net~>figs
geSelectFig(fig)
)
This will select all the figures on the specified net name.
- Andrew Beckett
Cadence
( ESNUG 402 Item 5 ) --------------------------------------------- [10/23/02]
From: Jeff Winston <jwinston@engim.com>
Subject: Small Company Needs Low Cost Linter, Wonders About Cadence HAL
Hi John,
Our little company will soon be looking for a Verilog linter. We don't
need a 5-figure, GUI-heavy "Design Analysis tool". We just want a linter.
Preferably something straightforward and inexpensive (ideally, like
Verilint before it was sold to Avanti.) I'm guessing there are some good
tools out there filling the price/functionality space that Verilint left
behind, but being from smaller outfits they may not be well marketed. I
was wondering if anyone had any recommendations. I was also wondering
what experience people have had with Cadence's "HAL" Linter.
Thanks very much in advance.
- Jeff Winston
Engim, Inc. Acton, MA
( ESNUG 402 Item 6 ) --------------------------------------------- [10/23/02]
Subject: ( ESNUG 400 #13 ) Get UNIX Shell Capabilities In Synopsys Tools
> I've been working with Design Compiler for a while now and I've noticed
> that the Synopsys shell is lacking all the great features that are usually
> present in a UNIX shell (ie, command/path completion, up arrow/down arrow
> history, etc.) I've found a lot of Perl/TCL wrappers that add these
> features, but I'd like to find something that works directly inside the
> tool. I'd like to avoid wrappers since they tend to get messy.
>
> I found a tclreadline module that allows me to get Shell capabilities.
> The problem is that I can't read in the compiled module since Synopsys has
> disabled the TCL "load" command. Know of any way to turn on the TCL load
> command? :)
>
> - Milan Bhatt
> Intel
From: Marco Trunzer <Marco.Trunzer@de.bosch.com>
Hi, John,
Milan should ask Synopsys directly to do this. I did this some releases ago
for a fully featured "package" command in PrimeTime - and Synopsys
re-introduced it. But "load" doesn't yet work in PrimeTime either.
He's right, a tclreadline would be a great benefit.
- Marco Trunzer
Robert Bosch GmbH Reutlingen, Germany
---- ---- ---- ---- ---- ---- ----
From: [ A Known Ambit BuildGates User ]
Hi, John. Please keep me anonymous. Thanks.
I would like to react to Milan Bhatt's question.
Cadence BuildGates and BuildGates Extreme have all the capability he needs.
We didn't bother to BEG Synopsys to implement such good features in DC or
PhysOpt because if Synopsys didn't respond to bad logic problems quickly,
they won't care about new features like that.
We issued a bad logic bug in 2002.05-SP1 and Synopsys said the release in
2003/Q2 will solve it. :-( That's almost half year after. BTW, we have
found several bad logic problems in either 2001.08 or 2002.05. Most of the
cases are caused by the new Presto HDL compiler. It is default in 2001.08
and 2002.05 now and in FCII 3.7.1.
I think ESNUG users need to know this. Our workaround is to turn off
Presto. Solved most problems. How did we find the problems? Verplex LEC.
- [ A Known Ambit BuildGates User ]
---- ---- ---- ---- ---- ---- ----
From: Jon Stahl <jstahl@avici.com>
Hi John,
If Milan is an Emacs user, an excellent way to accomplish a uniform powerful
shell-like interface to *any* command line tool is to use the "Shell mode".
To do this, just start a shell buffer using "M-x shell". Inside of this
buffer, you can execute any command line tool and have access to your
typical shell features of command and path completion, history, etc.
Furthermore, you also have access to all emacs commands for things like
cutting and pasting text into/out of the buffer, searching the buffer, etc.
This is great for editing long command lines -- you get to do it within
your text editor.
You can also start and rename multiple buffers from the default "*Shell*"
to useful tags like "pt_wc" (e.g. primetime worst case), "pt_bc", and
telnet to other machines within buffers to spread the load.
- Jon Stahl
Avici
---- ---- ---- ---- ---- ---- ----
From: Brendan O'Connor <brendan.r.oconnor@intel.com>
John -
I was faced with the same issue re dc_shell and "normal" UNIX shell things
(up arrow, filename completion). The solution I came across, though not
intuitive, I've come to depend on. I have now switched to running all my
dc_shell sessions within an emacs shell. It gives you filename completion
( tab ), command history ( ESC-p, ESC-n ). You also have the ability to
scroll backwards and forwards in the shell since it's just an emacs buffer.
One thing you need to do is to do "set sh_enable_page_mode false" so that
when you do a 'man' or 'report_*' the built in dc_shell pager doesn't try
to page things for you ... you can just scroll back in the buffer using
emacs pgup, pgdn and the arrow keys.
I look forward to this feature becoming available in DC. In the meantime,
however, I'm quite happy running dc_shell under emacs.
- Brendan O'Connor
Intel
---- ---- ---- ---- ---- ---- ----
From: Paul Zimmer <pzimmer@cisco.com>
To: Milan Bhatt <milan.c.bhatt@intel.com>
Milan,
This isn't tcl-specific, but I use:
ile for sun
ied for hp
Intel's an HP house, right?
Anyway, both work the same way. You do (on hp)
ied dc_shell -tcl_mode
and you instantly get ksh-ish inline editing. I don't know if ied can be
tcsh-ish. ile (for sun) can ONLY be tcsh-ish, which is one reason why I
prefer using our HP machines! Both ied & ile will work on any stdin/stdout
program, so you can use it on ftp for example. I have used ied for a dozen
or more years and ile for about 4 years. Both work well.
- Paul Zimmer
Cisco Systems
---- ---- ---- ---- ---- ---- ----
From: Milan Bhatt <milan.c.bhatt@intel.com>
To: Paul Zimmer <pzimmer@cisco.com>
Hello Paul,
Yup Intel's a big HP house as far as I know, though I just tried that
command out and for some reason it didn't work. I read the man page on
"ied" and supposedly you should be able to do all those nice history and
tab completions, but none of those worked for me on 2002.05 of DC.
Actually the only reason I want this feature to be TCL specific is because
I think it would be a cleaner implementation to have all this code self-
contained within the tool. I found a TCL readline module on the web, but
I can't load the TCL libraries into the DC-shell since Synopsys has disabled
the "load" function.
So... as a totally new question, would you happen to know anyway to get the
"load" functionality going in the Synopsys shells? :)
By the way if you're interested in the TCL readline module, go here:
http://tclreadline.sourceforge.net/
This basically gives you the ability to do all shell like features including
custom command completion, command help (using Ctl-D), history, etc.
- Milan Bhatt
Intel
---- ---- ---- ---- ---- ---- ----
From: Paul Zimmer <pzimmer@cisco.com>
To: Milan Bhatt <milan.c.bhatt@intel.com>
Milan,
I use ied with DC 2002.05 all the time. I have these lines in my .profile,
maybe you need them:
export IEDHISTSIZE=2000
export IEDHISTFILE=~/iedhist
I have used ied with DC for at least 10 years.
Concerning your tclreadline info, I'll stick with ied/ile since they are
tool-independent - and don't require "load" to work. :-)
- Paul Zimmer
Cisco Systems
---- ---- ---- ---- ---- ---- ----
From: Milan Bhatt <milan.c.bhatt@intel.com>
To: Paul Zimmer <pzimmer@cisco.com>
One difference could be that I'm using tcsh, and not ksh/bash. Or perhaps
maybe I'm missing some key bindings?
I did try going into ksh/bash and then tried running "ied dc_shell-t", but
it didn't work even after exporting those variables. So it makes me think
its one of the above problems.
By the way, I'm sure this works just trying to figure out what I need to do.
I've only been doing stuff in DC for 2 years. If I went back 10 years, I
think I'd be in middle school wondering who Synopsys is. :)
- Milan Bhatt
Intel
---- ---- ---- ---- ---- ---- ----
From: Paul Zimmer <pzimmer@cisco.com>
To: Milan Bhatt <milan.c.bhatt@intel.com>
Milan,
I went into tcsh (in a workspace in screen that's running in a VNC session
on my w2k PC), and ied worked fine. Are you sure it really isn't working?
Just type in "echo hello <rt>", then hit esc-k to see if the line comes
back. This assumes vi mode.
Speaking of which, did you notice this on the man page:
The editing capabilities of ied are essentially those found in ksh.
Only those that differ from ksh are described below. As in ksh, the
style of editing is determined from the environment variable VISUAL,
or from EDITOR if VISUAL is not specified. The value examined should
end in vi, emacs, or gmacs to specify an editor type. If it does not,
ied does no editing, and history is not accessible.
Do you have "EDITOR" or "VISUAL" set correctly?
- Paul Zimmer
Cisco Systems
---- ---- ---- ---- ---- ---- ----
From: Milan Bhatt <milan.c.bhatt@intel.com>
To: Paul Zimmer <pzimmer@cisco.com>
Hi, Paul,
Alright, I finally got it. I wasn't expecting it to use editor keys for
doing history and completions! I was trying to use up arrow/down-arrow
for history and that didn't seem to work. So yeah hitting escape and
running the 'j' and 'k' keys seem to bring up the history. I'll have to
playaround with the rest.
Thanks for taking the effort to debug this with me.
- Milan Bhatt
Intel
( ESNUG 402 Item 7 ) --------------------------------------------- [10/23/02]
From: Pallab Chatterjee <pallabc@siliconmap.net>
Subject: A Report On What Went On At Last Month's Magma User Group Meeting
Hi, John,
Here is what I saw at last month's Magma users group meeting. First, the
numbers:
Overall attendance 80 people
Total # Magma Technical Papers 7
Total # Magma Tutorials 6
The conference was a pretty good show - much more technical than I
expected. The papers were similarly themed as "the Magma software did not
work as well as we planned - BUT their apps people and R&D people worked
with us and we not only SOLVED the problem, but developed a repeatable
solution for future projects". This is actually what you want for a user
group. I was just surprised at the level of detail and positive attitude
of the audience. (I am used to the typical Avanti Aurora audience which
was either passive or ticked off).
The two big Magma sessions were the Magma tutorials:
"Beyond timing constraints - tools for timing correctness" by Tim Burks
and
"Maximizing Blast Fusion for Runtime/Capacity/QOR" by Kam Kittrell.
Tim's tutorial went in depth on how to properly import a library (best and
worst case info) into the Magma environment and the new GUI based debug on
timing analysis including false and multicycle paths and full net
details. This was one of many discussion on the concept of "usefull
slack" that ran through the conference. Several customers indicated that
Magma was the only one really doing useful slack properly although there
was heated debate about the term properly.
This tutorial also went through two important areas - how to describe the
clocks for both flat and hierarchical mode for skew calculation and the
layout trace commands. The clock discussion was primarily verbal against
some schematic examples - there was no TCL code or command line examples
given to accompany it but lots of user notes were taken.
The highlight of this talk were the new command descriptions for the layout
trace commands which is the GUI for matching timing information to the
layout nets and placement. The new commands reviewed were:
ui layout trace create <conn>
ui layout trace add <conn> <trace> <from> <to>
ui layout trace path <conn> <trace> <pin 1> <pin 2> ... <pin n>
ui layout trace display <conn> <trace>
( -flyline, -wire_all, -wire_arc, -wire_bbox options )
ui layout trace visible <conn> <trace> -on/-off
ui layout trace delete <conn> <trace>
ui layout trace clear <conn> <trace>
These commands have existed in the code for a while but most users did not
know they were added.
This tutorial followed keynote comments, a user paper and several highlights
in other user papers about the importance of the library validation (.lib vs
SPICE) for the IP blocks in order to have Magma return a "real" timing
closed answer. Due to the fully integrated nature of the tool, the BlastXXX
flow has a major garbage in - garbage out problem. All the Magma tools are
predicated on the assumption that the library description data is CORRECT
and everything is self consistent from that point. If you have bad or out
of synch characterization of IP blocks and standard cell libraries the Magma
tools will NOT give you an answer that correlates to post layout extracted
SPICE rather is correlates ONLY to the input timing data given.
Kam's tutorial on maximizing runtime focused a lot on the changes between
the current Magma releases and V 3.2 that is released in October. The main
feature of the new Magma release is the increase in capacity to about 2 M
placeable instances per level of hierarchy under the standard 32-bit Linux
kernel. The previous versions were stuck at about 500 K placeable objects
due to Red Hat's limit of 3 Gb max address space (or 3.5 Gb with some OS
patches) and the old addressing scheme on 32 bit. The 3.5Gb problem still
remains, but Magma tweaked their mapping scheme so they can get the larger
design sized through.
The tutorial reviewed a number of memory management tricks and utilities
that are applicable for the current version 3.1 release. Two best return
memory management tricks that were reviewed were:
1. Pruning the unused memory components this is done with the command:
data prune library $l <pad, pad_filler, pad_corner, macro>
2. Blast Fusion allocates memory dynamically, the dynamic memory
allocation can produce memory fragmentation of >20%, in order to
increase the memory available the following procedure should be
followed:
* save volcano after major steps
* exit, restart tool
* reload volcano and continue
The other Magma non-GUI related hint provided was with respect to the clock
router. In order to get a reduced insertion delay - the clock should be
routed with 2x width and 2x space. This is done by the following sequence:
- rule net nondefault <2x spacing and width per layer>
- force net nondefault <clock root net>
- run route clock" within fix clock will propagate the non-default
rule to children
The other tutorials were (A) Hierarchical design using Blast Plan and Blast
Fusion and (B) using Blast Noise for Noise Avoidance.
There was a minor snafu on the R&D Chat sessions. Since it was a first
year conference and the participation level of the audience was not known,
the R&D people were told to present some questions to kick off the
discussion. This prepared material was a bit much in length the two chat
sessions became additional tutorials. These were on Virtual Prototyping
and Sign-off Verification.
The user papers were pretty good for a first year conference. The only
fast one that slipped in was from Forte Designs. They presented a 90%
marketing content piece on their products and they presenter was the
VP of Mktg. The attendees were cordial to them, but it is generally NOT
an acceptable practice to do a sales piece in a technical conference.
There are so few "technical engineering" venues out there vs sales and/or
marketing venues it really shows the desperate and amateurish nature
of the vendor to try and force the engineers to listen. This generally
results in a negative impression of the vendor rather than any positive
information or spin that could theoretically happen. Other tech
conferences should be on alert to watch for this sort of activity.
There were three user papers that were noteworthy from this conference. Two
of them can be posted on DeepChip for people to review, we are waiting for
the OK before the ST paper gets posted. The three papers were: ST
Microelectronics - SOC Hierarchical flow with BlastChip, GDA Technology -
Methodology for Reducing the Signal Integrity Effect and Optimizing the
Time to Tapeout, and SiliconMap - An Optimal Timing Closure Methodology for
Blast Chip based on Automated Library Characterization. ST Micro is a
customer of Magma. GDA Technology and SiliconMap are both design centers
certified to run Magma tools for customer projects - however, neither group
receives compensation or referrals from Magma.
The ST paper went through a lot of details on their flow conversion using a
traditional LEF/DEF interface and module separation. The most interesting
portion of their talk and paper was the way they handled multiple power
supplies in the Magma tool. The other tools on the market follow the
convention of the power router handles the digital core as a power global
and other supplies are best dealt with as localized "signals" rather than
power supplies. This does not work for the Magma flow as the Power signals
are routed with a different width/spacing than regular signals and the IR
drop avoidance feature only works on power nets.
The ST solution involves several TCL scripts to identify and order power
pads, place the new pads, and verify that the new multi-power rings are
setup properly with avoidance in the Magma environment rather than waiting
for verification n Calibre.
This is an interesting solution as the SilconMap recommended work around
for the multi-power problem is to localize the segmented power rails in
stand alone modules. These isolated power rails are then hierarchically
route the power pads WITH the logic for the module. At the next level of
the hierarchy these pads are no-longer propagated.
The GDA Technology paper dealt with Signal Integrity issues in the design.
It focused on shielding of nets and the effect of the Victim/Aggressor net
analysis in the Magma tools to resolve the problems in the deisgn. The
features used in this analysis are all in the current release from Magma
and other than being easier to support (integrated launch and result
analysis) and as complete as standalone analysis with Simplex or Synopsys
products. This paper will be available on the DeepChip downloads site.
SiliconMap presented a paper about library modeling and an automated
routine for dowloading, running and analyzing revised device level library
data and then creating the necessary timing, power, and SI view for these
libraries and importing them into the Magma flow. The highly integrated
architecture of the tool can lead long loops for timing closure if the STA
results, based on the .lib information, and the results of device level
simulation from post layout extraction are not based on the same revision
of modeling information. When this data is out of sync, then the Magma
tools tend to return results that are oversized and over powered based on
silicon correlation. With this new synchronized data, then the results are
typically smaller and lower power than you would get from traditional post
layout analysis APR flows. This paper and powerpoint will also be available
on the DeepChip downloads site.
As a summary. For a first year conference it was a good show. There was a
surprisingly active dialogue between the presenters and audience which
seemed out of character with the historically quiet nature of the Magma
client base. If there are any Magma Users who missed the conference and
would like a complete copy of the proceedings and Keynotes, please contact
your Magma Sales person to get a copy on CD.
- Pallab Chatterjee
SiliconMap, LLC. Livermore, CA
[ Editor's Note: I'll have the 3 papers Pallab mentioned up on the
DeepChip downloads section by the end of the week. - John ]
( ESNUG 402 Item 8 ) --------------------------------------------- [10/23/02]
Subject: ( ESNUG 400 #15 ) Formality vs. Chrysalis & What About FormalPro?
> We started out using Chrysalis Design VERIFYer, which was subsequently
> acquired by Avanti and recently by Synopsys. I was able to use Synopsys'
> Formality to re-run some of this work. What follows is a summary of my
> experience with the two tools.
>
> - Steve Golson
> Trilobyte Systems Carlisle, MA
From: Mahesh Siddappa <msiddapp@atmel.com>
Hi John,
Thanks for publishing the comparison of Formality and Chrysalis in
ESNUG 400 #15. I wonder if any user of both Mentor's FormalPro and
Formality has published such a report? I would be interested in
looking at it.
- Mahesh Siddappa
Atmel
---- ---- ---- ---- ---- ---- ----
From: Maremanda Rao <mrao@amplecomm.com>
Hi John,
Here's my experience going from Design-Verifyer to Formality. Actually
there isn't much to write about in terms of training, ramp-up curve, etc.
because Formality itself was very easy to use, and rarely we had to rely
on the advanced commands like inv_push, etc. We just tried Formality
RTL-to-post-layout flat on our 300K instance design. It took 37 mins
on Linux machines. Design-Verifyer couldn't do this, even RTL-to-
pre-scan-gates (hier) due to capcity issues. Our traditional flow with
Chrysalis used to be bottom-up RTL-to-gates (same hierarchy that we
used for Synthesis), excising the instances as we go up. This was was
painful, because we had to add module/scripts and modify 'make' files,
etc. Overall, our runtimes have come down from a full day to 9 hours
plus no need to do that excising business anymore.
Thanks for the support from both the Synopsys & Chrysalis teams, especially
from the field specialist who was there for us on site resolving some
critical issues (turned out to be bugs) with painless work-arounds.
Also the shared key (for Formality and Design-Verifyer) helped us debug
the failures fairly easily, and report the bugs to the Formality team.
To make the story short, this was the easiest transition I haver ever had.
- Rao Maremanda
Ample Communication, Inc.
---- ---- ---- ---- ---- ---- ----
> The way Formality used to work and the way I think Design VERIFYer works
> today, if you need to give the tool some help once you matched again the
> tool would start the entire matching process from scratch. A waste of
> CPU cycles
>
> - Steve Golson
> Trilobyte Systems Carlisle, MA
From: Howard Landman <howard@riverrock.org>
Not exactly. You do need to rerun Design VERIFYer, but you can read in an
output file from the previous run to re-establish all the matchings and
equivalences already proved. This doesn't take very long compared to
the overall runtime.
> 15. Formality allows you to quickly and easily check just one output, and
> ignore all the rest. Design VERIFYer can do this, but it's painful.
Steve, go into the debugger ("chrys_explore -gui"), select the matched
output, and verify it there. Not too painful unless it takes a long
time. (Yeah I know, you'd rather script it ... which does require
setting an ignore on every ouput EXCEPT the one you want ...)
As you discovered, DV is starting to show capacity and speed limits for
big designs in RTL mode. From your number it looks like Formality may
be better in those domains. From my experience (I haven't used
Formality much), Verplex's LEC is also much better at handling large
designs than DV. I'm a long time DV user and have taped out multiple
chips using it, and I like many aspects of the tool, but if I was doing
something large today I would be more likely to go with Verplex because
of capacity and speed concerns. LEC also does a somewhat better job of
pruning the logic cone feeding into a difference when it reports the
difference back to you, which can make debugging a little easier.
I'd like to also mention that library model verification should be taken
very seriously. Many people think that library cells are so simple that
nothing can go wrong, or that if something was wrong, it would be so
obvious that it would be caught by simulation. Think again. I've seen
at least two tapeouts (at different companies) fail because of library
bugs that would have been caught by any reasonable verification process.
Setting it all up may be slightly painful, but the runtimes (except for
Spice on 32-bit registers :-) are trivial. On one project I worked on,
we had up to 5 Verilog models of each cell. Formally verifying all 5
libraries against each other took less than one CPU-minute, once it was
set up, and we ran it routinely on every library release, and we
occasionally found problems and fixed them. Using formal verification
tools designed for million gate chips to verify a standard cell library
may seem like using a sledgehammer to kill a mosquito, but it does the
job, and it's better than simulation (although you want to do that too,
if only to verify that the models work with each simulator).
- Howard A. Landman
Riverrock Consulting Fort Collins, CO
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,488 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
