From: Brian Kane <briank@torrentnet.com>
Subject: Federal Taxes Move Boston SNUG CFP Deadline To April 20th
Hi, John,
We're having a number of authors request extensions for their proposed
Boston SNUG abstracts because they're working last minute to get
their Federal taxes filed by April 15th. So, to be fair to everyone
interested in presenting at the Boston SNUG, we've decided to move the
Call-For-Papers deadline to Friday, April 20th, next week. Could you
please tell this news to your readers?
Tell them abstracts are to be submitted to snug_tech@synopsys.com,
more info is at http://www.snug-universal.org/boston/boston.htm and
last year's Boston SNUG'00 Trip Report is (for those who don't know)
at http://www.DeepChip.com/posts/bsnug00.html
- Brian Kane
Ericsson IP Infrastructure, Inc. Rockville, MD
( ESNUG 368 Subjects ) ------------------------------------------- [04/12/01]
Item 1 : ( ESNUG 367 ) Hey! Avanti Wants To Hold Us Customers Hostage!
Item 2 : ( ESNUG 367 #1 ) Fixes To The PhysOpt/Avanti PDEF 3.0/2.0 Scripts
Item 3 : What About Mixing Avanti PDEF 2.0 With Synopsys reoptimize_design?
Item 4 : Avanti Placement Works, But Apollo Routing Dies On Easy Designs?!
Item 5 : The New "high_fanout_net_threshold" in DC 2000.11 Cost Us A Week
Item 6 : ( SNUG'01 #26 ) SystemC Is A Lot Of Work For What Little It Does
Item 7 : ( ESNUG 364 #3 ) ACS 2000.5 Mem Leak Sort Of Fixed In 2000.11-SP1
Item 8 : The VCD Viewer In VSS Doesn't Show Correct Intermediate Bus Values
Item 9 : It's Frustrating How PrimeTime Partially Ignores Its Commands...
Item 10 : Finding The Geometric Center Of A Clock Tree In Cadence CTGEN
Item 11 : ( SNUG'01 #15 ) Howard On Avanti's Chrysalis "Design Verifier"
Item 12 : What's The Real Dirt On PhysOpt With Power Compiler & CTS Tools?
Item 13 : Sean's Trip Report from 2nd Annual Verisity Users Group Conference
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 368 Item 1 ) --------------------------------------------- [04/12/01]
Subject: ( ESNUG 367 ) Hey! Avanti Wants To Hold Us Customers Hostage!
> I was very excited to get this email on PhysOpt PDEF 3.0 to/from Avanti
> Scheme scripts for two reasons:
>
> 1.) Instead of this being a user *complaint* about interoperabilty
> (where we're all equally frustrated about what to do), this is
> someone actively *solving* the interoperabilty problem. I want
> to encourage getting more e-mail like this.
>
> 2.) Avanti is a goldmine of EDA tools and technology. ...
>
> So if you find errors (or if you find anything useful) in these Scheme
> scripts, write me. ... ESNUG is *user* driven. And if 50 percent of
> my backend users are using Avanti tools, Avanti tools should damn well
> be discussed in detail here, too!
>
> - John Cooley
> the ESNUG guy
From: Dale Lomelino <dale.lomelino@philips.com>
Hi John,
I appreciate the recent expansion of ESNUG's focus to include physical
design tools (my own area of interest). Just don't heap too much praise
upon Avanti until you get to know them. If anything, they have more warts
and blemishes than Synopsys and Cadence combined.
Thanks for sending these scripts, though. They appear to be updates of
similar scripts that I have from working a PhysOpt test case.
However, you are giving credit where it is not due. My understanding is
that Synopsys wrote these Scheme scripts, because Avanti does not want to
play nice with other EDA vendors. The best supporting evidence is:
% more dumpPDEF3.scm
(define vendor "SYNOPSYS")
(define program "PHYSICAL SYNTHESIS")
etc...
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.
It was Synopsys that opened the door to work with Avanti, dragging them
kicking and screaming into the real world of multi-vendor tool flows.
Avanti would rather you play only in their sandbox. Perhaps Avanti feels
threatened by Synopsys entering the place-and-route market?
- Dale Lomelino
Philips Semiconductors Cary, NC
---- ---- ---- ---- ---- ---- ----
From: Dan Moritz <dmoritz@lsil.com>
Hi John,
In my experience, Avanti actively works to keep you locked in via their
proprietary interfaces. They are the only company to be stuck in this old
EDA model. They are banking on a very small part of their toolset that is
best in class. If another vendor catches up, they may find their customer
base gone.
Here's the specific project I was involved with that shows why I have
this opinion.
We were asking Avanti to complete the implementation of IEEE 1481 by
including support for DCL/OLA (Ch1-8). They already support most of
Ch 9-10, SPEF and PDEF. They were willing to look at it with us. They
hooked me up with some excellent development engineers that looked at
our source code and how it would be done. The consensus was that it
wouldn't be too costly to implement in their 99.X tools and they would get
back to us with some schedules. After waiting for a while on these
schedules, I continued my engineering discussions and shipped them source
code that showed the basic interface and how it would hook up with their
infrastructure. After a while, they came to the table with a proposal
at an executive review.
They said they weren't able to implement these sections until a date after
our kit release. As is common with EDA vendors, we went back and forth.
Put tersely, it went like this:
LSI: What will it take to move this date up?
Avanti: We've no resources with all your requests. Is OLA important?
LSI: Yes.
Avanti: If you could provide us someone to work on it, we'll do it.
LSI: OK, how do we set that up?
Avanti: Well, to be effective they should sit at our site.
LSI: Let us check... OK, we found someone that will work on site.
Avanti: Oh, sorry! We weren't serious. Perhaps we can leave the hooks
in Astro for some future development. [insert their marketing
handshake and a wink here.]
I am thinking about all the resources they have wasted as a result. We
have them working on tons of correlation issues, like every other EDA
vendor that buys their tools. The reason we and several other major
silicon suppliers want EDA vendors to incorporate the rest of 1481 is to
eliminate this useless effort. A refusal of charity indicates not only
a penny foolish, but a pound foolish business strategy.
Mr. Hsu talks about Avanti customers saving $10 K on license negotiations
by waiting until the last minute. I wonder if he doesn't see the huge
hole he makes in customer's pocket forcing us to waste time turning knobs
on their proprietary delay predictor and managing all the various text file
parsers you need to drive Avanti tools?
I also wanted to mention that LSI is now a little bit smarter as a result.
We list OLA support in our new EDA contracts to eliminate this kind of
unreasonable behavior. Not just to protect us, but the EDA vendors
themselves. It is not worth the effort to tune EDA software knobs when the
same thing can be accomplished with *one* standard for delay prediction.
Between that and all the other file and shell gymnastics I need to setup
on any EDA timing engine to run, we are moving on. We implemented our own
infrastructure around MilkyWay that allows us to get OLA signoff quality
timing without using Avanti's timing engine or SDF.
- Dan Moritz
LSI Logic Minneapolis, MN
( ESNUG 368 Item 2 ) --------------------------------------------- [04/12/01]
Subject: ( ESNUG 367 #1 ) Fixes To The PhysOpt/Avanti PDEF 3.0/2.0 Scripts
> Here are some Scheme scripts that enable data to move between Avanti and
> PhysOpt. I think they will work for Chip Architect and Flexroute as well.
> These scripts seem to work for my company, but I would guess that other
> folks may have to modify them to make them work at their site.
>
> - ASIC Designer #8
From: "Andy Pagones" <Andy_Pagones-ACIC22@email.mot.com>
John,
I'd like to make some corrections to the script help file you posted on
the Downloads section of DeepChip. It is missing some double quotes and
carriage returns.
Instead of:
load dumpPLIB.scm define plibSiteName "tsm3site" dumpPLIB
/home/tsmc18/avanti/tsmc18 tsmc18.plib
it should be:
load "dumpPLIB.scm" ; {to load the Scheme code}
; {now define runtime options}
dumpPLIB "/home/tsmc18/avanti/tsmc18 tsmc18.plib" ; {to execute the
function}
and rather than specify any number of "define" commands, direct the users to
the subsequent text that shows the runtime options embedded within the
Scheme code. This script header contains 6 options:
(define plibDumpMode 2) ; 0 - technology; 1 - cell; 2 - technology + cell
(define plibBusNameRule "[%d]")
(define plibSiteName "core")
(define nameCaseSensitivity "ON")
(define maxFatWireWidth 2500)
(define debugFlag #f)
Any of these may (and some MUST) be modified by the user AFTER loading the
Scheme code. But the syntax should be corrected on your web page:
define plibDumpMode 1
define plibDumpBusNameRule "[%d]"
; ... etc....
; {and only THEN run the function:}
dumpPLIB "physLibName" "plibOutputFile"
Likewise replace:
load dumpPDEF3.scm dumpPDEF3 "tsm3site" output_pdef_file.pdef
with:
load "dumpPDEF3.scm" ; {load the Scheme code}
(define vendor "SYNOPSYS") ; {define up to 7 runtime options below}
(define program "PHYSICAL SYNTHESIS")
(define version "")
(define preRouteFormat 2) ; 0 - place obs, 1 - routing obs, 2 - pnet
; AJP set designLevel=0 for initial fp (PC deletes cell placement anyway)
(define designLevel 0) ; 0 - floorplan, 1 - floorplan + placement
; 2 - floorplan + placement + complete routing
(define debugFlag #f)
(define pdefBusNameRule "[%d]")
dumpPDEF3 "siteName" "output_pdef_file.pdef" ; {execute the function
The first Known Issue for this script is a non-issue; simply don't output
routing: define designLevel 0 or define designLevel 1 will do the trick.
Instead of:
load readPDEF3.scm.scm readPDEF3.scm input_pdef_file.pdef
use:
load "readPDEF3.scm"
readPDEF3 "input_pdef_file.pdef"
there are no runtime options for readPDEF3.scm .
Once we did all this, we found the scripts worked slicker than slick in
getting PhysOpt PDEF 3.0 in and out of Avanti PDEF 2.0. Slick!
- Andy Pagones
Motorola Labs
( ESNUG 368 Item 3 ) --------------------------------------------- [04/12/01]
From: Kaushik Kuila <kuila@acorn-networks.com>
Subject: What About Mixing Avanti PDEF 2.0 With Synopsys reoptimize_design?
Can Avanti take a PDEF file as input, that is generated by Synopsys
reoptimize_design command, and place the cells close to the locations as
suggested by Synopsys, or does Avanti completely ignore any input PDEF
file? Also in case a PDEF file is hand-modified to place some cell on the
same co-ordinate as another cell, will Avanti place the cells close to
each other?
- Kaushik Kuila
Acorn Networks Reston, VA
( ESNUG 368 Item 4 ) --------------------------------------------- [04/12/01]
From: Joseph Gebis <gebis@cs.berkeley.edu>
Subject: Avanti Placement Works, But Apollo Routing Dies On Easy Designs?!
Hi, John,
We're using (or trying to, at least) Apollo to route our latest chip, and
running into some serious problems.
We've tried to contact our Avanti AE, but to no avail. I'm wondering if
anyone on ESNUG has any ideas of what might be the problem, or any
suggestions of where we could look for help. Thanks.
I'm having a problem when I attempt to route in Apollo. This problem shows
up for even extremely simple examples; one test case I've done has simply
32 flipflops and nothing else. In that example, I set the core utilization
to 0.3 and the row/core ration to 0.7, so it seems that it should have
more than enough space to route.
Placement seems to work fine, as does Global Route (I can turn on groute
visibility, and it looks as though all the appropriate connections
are there). The problem first seems to appear during Track Assign.
It completes without complaints, but I can see there are a number of
connections that have not been made, and if I do a Route->Check Opens,
it complains about a large number of nets with errors (in my simple
example, it reports: "Check 67 nets, 33 have Errors").
If I try and to a Detail Route at this point, it won't even complete
for anything but the simplest examples (it doesn't even get to the
"Route SBox" stage; it dies with "**** ERROR:Too many broken nets.
Cannot continue!"). For the simplest examples, it seems to complete
the Detail Route with no violations, but if I again do a Route->Check
Opens, I find I still have a large number of nets with errors.
I can improve the situation slightly by either doing Route->Search &
Repair, or by doing a Global Route, Track Assign, doing another
Global Route, another Track Assign, and keep iterating over those
two; still, both of those only give marginal improvement, and even in
my extremely simple example, I can never end up with a good route.
I'm using a standard cell library that we got from our fab partner,
but we were just given GDS files (not an Avanti library). I thought
that perhaps I had messed up in my importing the cell library, but
my simple example uses only one cell, and if I do a Wire Tracks -> Check
Pin On Tracks in Milkyway for that cell, it reports:
** # Pins with no good access point on Grid (V&H) = 0 ( 0%)
which makes it seem to me like it should be able to reach its pins.
For the nets that do get routed properly, it seems as though Apollo
is doing a good job (that is, it doesn't seem like there's something
majorly wrong with the techfile I'm using, or something like that).
I'm not sure what else I can try.
- Joseph Gebis
UC Berkeley
( ESNUG 368 Item 5 ) --------------------------------------------- [04/12/01]
From: Tom Ayers <tomayers@believe.com>
Subject: The New "high_fanout_net_threshold" in DC 2000.11 Cost Us A Week
Hi, John,
Perhaps some of your readers have already stumbled onto this one. In any
case, here's hoping this saves someone some pain.
We have encountered a poorly documented new variable in DC 2000.11 which is
poised to cause you some pain. It's called high_fanout_net_threshold and
is a new, potentially useful feature whereby nets over a certain fanout
limit are considered to be clock trees which will be taken care of via
clock tree synthesis. This provides a second strategy for the classic
set_drive 0 approach to clock trees during synthesis. No attempt will be
made to buffer these nets. It looks like this was thrown in last minute
without the usual Synopsys QA process. Here are the problems:
1) No attempt to buffer the nets will be made, but timing arc involving
these nets still are in the timing driven synthesis path groups, so
DC will try for days to optimize nets which can't be buffered.
2) Variable does not exist in the distributed .synopsys_dc.setup file,
therefore it is un-initialized.
3) Printvar thinks this variable does not exist.
4) Setting this variable to 0 causes the old operation, but it is not
initialized and you can't check what its value is due to #3.
5) pipeline_design no longer tries to buffer stall signals even when this
variable is set to zero. This may be a tangential issue, but is
probably related to the implementation of this new feature.
We now set high_fanout_net_threshold to 0. Personally, I think this was
the wrong idea altogether. Implementing a feature that allows you to
identify nets that will later be CTS is a good idea, but this does not take
those nets out of the timing arcs which would be needed if thats what you
want (could be done with set_drive 0 if you knew what nets were involved).
Since it is implemented as an arbitrary bar, the user does not know what
nets are affected and the assumption that there is some bar over which CTS
is used and under which it is not is a bad one. For instance, test_se is
often one of the highest fanout nets, but is rarely CTS. A much better
implementation would be to have a port constraint that identifies ports
which are CTS, does not buffer them, and puts a set_drive 0 on that net.
Looking at their man page, it looks like this was an attempt to improve
compile time. Cost us a week of schedule in total.
- Thomas Ayers
Believe, Inc.
( ESNUG 368 Item 6 ) --------------------------------------------- [04/12/01]
Subject: ( SNUG'01 #26 ) SystemC Is A Lot Of Work For What Little It Does
> When our SW guys need what we're working on for their simulations, we
> tranlate it over to C, bottom up. SystemC works, but it's ugly. It's
> a solution in search of a problem we don't have. We'd rather do our
> hardware design in Verilog and then translate it to C at the last minute
> when it's needed by the SW guys. Verilog is much more graceful for
> hardware design. Translating it to C is easy.
>
> - Martin Gravenstein
> TDK Semiconductor Corp.
From: Ken Merryman <Kenneth.Merryman@unisys.com>
John,
I see no use of the C based languages here for at least two years (if ever.)
We have been simulating large systems for years with the our proprietary
languages, then VHDL and now Verilog. Our high level architectural system
simulation uses a queuing language and does not need to actually perform the
logical functions as required for design verification. For what we design
it's hard to see the connection between architecture modeling and design
implementation.
- Ken Merryman
Unisys Roseville, MN
( ESNUG 368 Item 7 ) --------------------------------------------- [04/12/01]
Subject: ( ESNUG 364 #3 ) ACS 2000.5 Mem Leak Sort Of Fixed In 2000.11-SP1
> A few months ago we tried ACS on a real design. The ACS process ran out
> of memory while generating the constraints for the second phase (pass 1)
> compile. The Design Budgeter has a memory leak bug. Synopsys identified
> a workaround, but that only works in 2000.5. There's no fix for 2000.11.
> We're trying to get Synopsys to commit to a fix but it's hard going.
>
> - Tom Fairbairn
> 3Com Europe Ltd. Hemel Hempstead, UK.
From: Tom Fairbairn <tomf@pdd.3com.com>
Hi John,
After a few customers and Synopsys employees following up on my problem, I
thought I'd keep you up-to-date with my ACS troubles. I have a workaround
that seems to work (fixes the memory leak I had in acs_refine_design) with
version 2000.11-SP1. This is good as it gives us some confidence that it
will work in future versions. Synopsys is promising that I shouldn't need
the workaround and to expect great things from the next version after
2000.11 - but then EDA vendors always do that.
There is a slight problem, though. The workaround is to use a custom budget
script (/scripts/pass/budget.scr), that must say:
allocate_budgets -levels 2 -create_context
What this does is tells the budgeter to only create budgets 2 levels of
hierarchy down from the top. This solves the memory problem, but it
obviously means that you can't create a partition at any greater than 2
levels down in your hierarchy. Not a great problem for me (yet) but it is
a worrying little restriction.
Thanks for all your help, and keep on truckin'
- Tom Fairbairn
3Com Europe Ltd. Hemel Hempstead, UK.
( ESNUG 368 Item 8 ) --------------------------------------------- [04/12/01]
From: Farhan Shahid <fshahid@vt.edu>
Subject: The VCD Viewer In VSS Doesn't Show Correct Intermediate Bus Values
Hi, John,
I am trying to dump VCD files through the VSS VHDL simulator. By using the
command vcdaddobjects 0 TEST_BENCH/*'sig, and then "vcddumpall". I am able
to dump all the signals except individual signals for buses which are
dumped as HEX values. The VCD viewer howvever does not show the correct
intermediate value for buses.
For example if one signal in the bus is delayed for 2 seconds, and the
second for 3 seconds, the intermediate value between 2 and 3 sec (the
hazard) is not shown correctly. A sample virsim view would be like this
Time (sec) 14 15 16 17 18 19 20
C[1:0] |0.. |1... |1.. |2...
-------------------
C1 (correct) _____________________|
--------------
C1 (expanded) __________________________|
----------------------
C0 (correct) _____| |_____________
----------------------
C0 (expanded) _____| |_____________
The actual value shown between 18 and 19 should be 3 here, rather than 1.
Note that the individual signals are also not displayed properly when
expanded through virsim. If I use the -split_bus option,the individual
signals are though displayed correctly but I am unable to combine them
into a bus again, specially when using other viewers.
Can any one guide me about the source of the problem & how to correct it?
- Farhan Shahid
Virginia Tech.
( ESNUG 368 Item 9 ) --------------------------------------------- [04/12/01]
From: Dyson Wilkes <Dyson.Wilkes@swindon.ericsson.se>
Subject: It's Frustrating How PrimeTime Partially Ignores Its Commands...
Hi, John
Here is a quote from an engineer working with me:
"The worst problem that I've come across so far is PrimeTime's inability
to correctly implement false paths. For example, setting false paths
between all asynchronous clock domains (as suggested by Synopsys) does
not always work."
And another:
"Also use extreme caution with the 'reset_design' command, you can easily
be resetting far more than you bargained for!"
I observed this "ignoring false paths" problem in the early days with
PrimeTime. The realy frustrating thing is that you do not get to find out
the tool has (partially) ignored your command until you get the results
from the next report. Why, oh why, does it not tell you it has ignored
you? There seems to be no way to find out why either!
I just wondered if other users have had similar problems or have some
suggestions on how to solve this problem?
- Dyson Wilkes
Ericsson Microelectronics Europe
( ESNUG 368 Item 10 ) -------------------------------------------- [04/12/01]
Subject: Finding The Geometric Center Of A Clock Tree In Cadence CTGEN
> Has anyone noticed if CTGEN has difficulty finding the geometric center in
> a segment of logic? This might be influenced by the placement of the root
> pin for the clock. Dealing with a segment of logic (FIR FILTER), but the
> entry point of the root pin is in lower right corner. (internal clock).
>
> From the 'human' view it seems like the tool should have any easy time
> with this, but I am seeing over 0.9 ns of skew. What is even more
> puzzling is that I have given CTGEN a large max delay (according to manual
> this gives CTGEN plenty of margin to play with...) But, no solution.
> There is a larger TAP and the tool seems to do fine with getting good
> skew. But the larger TAP is spread out and the entry point for the root
> pin is near the center of the rectangular topology of that logic....
>
> There is something quirky about this algorithm which makes the tool take a
> dive and it is not clear what the paramters might be which cause the bug
> to get cornered. Any folks who might have some insights on the
> personality of the CTGEN tool, (5.2 or 5.3), please introduce me....
>
> - Jim O'Keefe
From: Ralf Leisner <leisner@cadence.com>
Usually there is a reason why CTGen could not fulfill your requirements. In
CTGen's working directory you would find a sub-dir 'rpt' and there is a file
'final.analysis' containing the slowest and fastest path for every clocktree
generated (min path, max path). You would find there detailed informations
about cell delays, interconnect delays, loads and transition times at every
stage of every clocktree. Look for significant differences between the min
path and max path of the concerning clock. In conjunction with the
graphical view of your design's floorplan/clocktree it is possible to
find out the reason for the irregularity in most of cases.
- Ralf Leisner
Cadence Design Systems GmbH Haar, Germany
( ESNUG 368 Item 11 ) -------------------------------------------- [04/12/01]
Subject: ( SNUG'01 #15 ) Howard On Avanti's Chrysalis "Design Verifier"
> EXIT WOUNDS: Out of the 27 e-mails I received on Formality, Verplex or
> Chrysalis: 22 were pro-Verplex; 5 were pro-Formality; and none were pro-
> Chrysalis. Years ago, Chrysalis owned the Equivalence Checking market.
From: Howard Landman <howard.landman@vitesse.com>
Hi, John,
I haven't had time to re-evaluate all the other guys. I'm too busy taping
chips out with "Chrysalis" (should be Avanti Formal now) Design Verifier.
I'd like to see the ability for it to handle retiming (pushing logic through
registers), but nobody really does it yet. Synopsys *claimed* Formality
would do it, but when I pushed I found out that they could only do it when
there's no feedback between pipe stages. (This was a while back and they
may have improved by now.) This covers 0% of the interesting cases.
(Ever heard of a 7 stage CPU pipeline with no feedback between the
pipe stages? Sheesh. Get real. Stall signals are a fact of life.)
I haven't *completely* automated our DV flow yet - I'd guess only 50-60% of
the modules go through with no manual intervention at all. The other ones
either need tweaks to the paths (use submodules in non-standard locations),
or need extra attributes to deal with things like one-hot state machines or
tristate busses. Working on submodules of the main modules also takes a
bit of hands-on to map pins before-and-after Clock Tree Synthesis and
scan insertion. It would be nice if this was a bit more automatic (for
example, if Apollo CTS automatically wrote out commands to map over the
changes it makes - I mean, these *ARE* both Avanti tools now, right?), but
it's not a major pain.
Anyway we routinely run Chrysalis RTL-to-gates and gates-to-layout formal
verification on all the modules (except PLLs, memories, etc.), and
gates-to-layout on the chip top level (the RTL and gates are the same at
that level so I can verify with "cmp" :-).
It catches simple errors much more quickly than regression simulation. It's
been especially useful when making ECOs for metal mask spins, where both the
RTL and gates have been hand edited. A couple of modules don't get to 100%
complete (1 or a few nets time out); I hope to overcome that soon.
The 3.0.1 release of DV seems a bit shaky though. They claim you don't need
to specify algorithm anymore, but I got excessive runtime on some modules
when I unspecified Aggressive Algorithm 4. I'm still using 2.5 (with AA4)
as our workhorse until I understand this better.
- Howard Landman
Vitesse Semiconductor Longmont, CO
( ESNUG 368 Item 12 ) -------------------------------------------- [04/12/01]
From Neel Das <neel.das@corrent.com>
Subject: What's The Real Dirt On PhysOpt With Power Compiler & CTS Tools?
Hi, John,
I applaud your continuing efforts with ESNUG.
I would be very interested to get feedback on how good the hooks are between
Power Compiler and Physical Compiler in the following two instances
(particularly for designs well over 100MHz):
1. With integrated clock gating cells being available
2. Without integrated clock gating cells being available. In this case,
Synopsys claims localized grouping within PhysOpt will ensure the
clock gating elements would stay together in layout. Has anyone had
any experience with this in a *real* tapeout flow? Has the CTS tools
you used with PhysOpt / Power Compiler handled skew management well?
Additionally, how's the interaction if the clock gating cells have
observability/controllability ports?
- Neel Das
Corrent Corporation
( ESNUG 368 Item 13 ) -------------------------------------------- [04/12/01]
From: "Sean W. Smith" <sesmith@cisco.com>
Subject: Sean's Trip Report from 2nd Annual Verisity Users Group Conference
Hi, John,
I thought I would share my impressions of the recent 2nd annual Verisity
users group conference. Overall there were a quite a few more attendees than
last year. Surprisingly still not a large turnout from the specman
veterans. Overall the conference was a significant improvement over the
first year. The steering committee did an excellent job of taking the
feedback from the first event and tailoring the event more toward what
people wanted. One thing that I wanted as well as most other attendees was
more technical user presentations as well presentations by Verisity R&D and
field staff on application of specman. Those who attended were rewarded
with a number of highly technical presentations by users, Verisity, and
Verisity partners such as Qualis design. The event ran on time with a
friendly atmosphere and the food was very good. This conference is
certainly not DAC for extravagance but if you're a verification engineer and
work with specman at all you would be well served to attend. There was
enough variety in the presentations to please novices and specman guru's.
Below is a brief synopsis of the presentations I attended.
Tutorial: Advanced Random Data Generation - Pete James, Qualis Design.
~3 Hours. Pete went through three sections from 1 of Qualis' specman
training classes. 1st section was a verification strategy overview covering
strategy, test plan, metrics, coverage, etc. The other 2 sections covered
generation techniques used in an ATM environment including transaction and
scenario verification. Presentation was excellent the code examples were
complete and well thought out.
Tutorial: Writing eVC's - Sholmi Uziel ~ 90 minutes.
This was a great overview on some coding style guidelines and methodologies
for writing an e verification component (aka re-usable model). This
presentation was a great addition to the presentation Janick Bergeron made
last year. I found it a good reference to Verisity's current preferred
methodology. Presenter did a great job and was able to easily address
questions.
Tutorial: Writing efficient 'e' code - Verisity R&D ~ 120 minutes.
This presentation was a favorite of myself and other specman power users.
One user comment that this presentation made the whole trip worthwhile.
I agree. Verisity dives in detail into profiling 'e' code. Verisity now
has profiling tools for runtime, memory and temporal expressions. Some
very interesting examples were shown and the actual implementation was
discussed to give advanced specman users a better chance of writing
efficient code. I hope this topic is covered again next year and in an
advanced training option. A+
The Evolution of Verification methodology: From Directed Tests to Specman
Elite: Mark Strickland, Verisity.
A basic introduction into the evolution of verification and where specman
fits in. This presentation was primarily targeted and novice or non-
specman users.
Randomized Testing with a Reference Model Based Testbench: Greg Mokler, TI
A very good presentation on dealing with real world problems and how Greg
and team were able to use a c reference model in conjunction with specman
to solve a verification problem. Also provided a nice example of closing
the verification feedback loop by writing coverage metrics against a FSM
and then using the specman coverage API to steer random generation into
the uncovered areas. An example of this type of technique can be found
in the Verification Advisor included with specman elite.
Coverage Metrics, Understanding Functional and Code Coverage: Mark Savoldi
and Sean Smith, Cisco Systems
A practical overview of code coverage, functional coverage, pros and
cons of each technique and suggestions for a hybrid approach to give
users objective feedback on verification completeness. I think Mark
did an excellent job of presenting this very misunderstood topic.
Keynote Address: Knowledge Transfer: Yoav Hollander, Verisity.
Yoav's ramblings are always one of my favorite topics. Despite running
on empty after a long and delayed international journey, he still managed
to give a thought provoking, entertaining but concise speech on where he
thinks knowledge transfer is headed and why it is so important. Yoav's
slides would not translate well without his presentation and humor. Those
who have not attended previously or ever met Yoav are missing out. A 5-10
minute of discussion with the father 'e' can be very enlightening. The man
is a walking encyclopedia of verification knowledge and so willing to
share what he knows...
An Eight Step Approach to Experience Random Verification - Chirs Macionski,
Qualis Design.
Great overview for beginning specman users on how to define a good directed
random test methodology. The steps and presentation were clear but
personally I found the code examples were poor and definitely needed
improvement. This appeared to be a very popular presentation amongst the
attendees for teaching some basic techniques that can be used in specman.
Aspect Oriented Programming - Amos Noy, Verisity.
A theoretical and abstract discussion of OO lanuages and there limitations
in the hardware verification spec. Introduces the concept of aspect
oriented programming and talks about some unique features 'e' possesses
relative to other OO languages and how this benefits verification
engineers. Some talk about the future of 'e'. This was one of my favorite
presentations but this presentation was the most abstract of all and
certainly seemed to confuse or have little value to many attendees. I hope
they continue to offer topics such as this in the future.
Implementing a temporal coverage model - Craig Deaton, TI
This presentation was another real world problem/solution scenario. Craig
basically went through a methodology for testing a complex arbiter. The
presentation may have been confusing for those not familiar with temporal
expressions but I enjoyed it and it triggered some good ideas that I want
to apply to my current effort. Not necessarily, a beginners presentation
but worthwhile and certainly the type I enjoy.
Verifying a CPU Core - Jon Rijk, ARM - Two part presentation.
First part was about transaction scoreboarding and gave a reasonable
introduction to the concept. The 2nd part of the presentation talked
about random CPU instruction and program generation. Well Presented...
Verification Vault - Ric Chope, Verisity
Ric presented a brief overview on Verisity's new online support site
and user community. This new offering will be of great value to specman
users. I'm looking forward to the public launch.
Emulating an RTOS - Eric Owens, Verisity
Eric presented some interesting concepts for emulating an RTOS in 'e'.
This presentation seemed to have mixed reaction. I personally enjoyed it
and thought it documented some techniques I had been unknowingly
using and gave me some good enhancement ideas for my application. Some
others I spoke with seemed perplexed as to why you would even want to
do this? The code examples I thought were very good and I plan on using
this technique when applicable.
e to Verilog: Brian Van Essen, Cisco Systems
Brian presented an overview of the 'e' 2 verilog research project. Cisco
has been partnering with the University of Tubingen, Germany to develop
a "proof of concept" 'e' synthesis tool to explore the possibilities of
using 'e' as a hardware/system design language. For more information see
"A framework for Object Oriented Hardware specification, Verification
and Synthesis" in the proceedings of DAC 2001.
R&D Panel: Various folks from Verisity fielding questions from the audience.
Pros with this format was that everyone got hear the questions & answers.
Cons: This Structure (versus the R&D Round table last year) limited the
conversational nature of the some of the questions, and verity marketing
answered too many questions. I hope in the future Verisity marketing
takes a less active role in censoring content at the conference.
I apologized as I missed the STARC presentation, knowledge transfer panel,
and the Verisity update stuck in traffic trying to drive to Lake Tahoe as
half of the bay area appeared to be doing that Friday afternoon.
In Summary a very good experience for specman users: Pros: Free, good food,
good mix of technical material from beginning to advanced, good networking
opportunities, opportunities to have one on one conversations with Verisity
developers. Cons: My brain hurt from information overload by the end, a
little too much marketing, need even more user presenters. I conclude with
a couple of quotes from the conference, comments and feedback are welcome.
I apologize if I omitted anyone or their presentation....
QUOTES:
"There is a group of hunter gathers traveling up & down the east cost
spreading the knowledge of fire, stone tools and socket based
verification" - Yoav Hollander
QUESTION to one of the presenters: "Why did your company switch from
Vera to Specman?" ANSWER: Long Pause "because Vera sucks!" longer
explanation then followed. - Anonymous Engineer
BEST ANALOGY: Peet James and Chris Macionski - quoted from their paper
Shotgun E
"An analogy to this approach is to fire a shotgun at a target -- a large
percent of the verification space is covered with a few strategic shots
(or testbases). After looking at the target (or coverage reports), you
would target specific uncovered areas with a high powered sniper rifle
(directed testcases). The old-school, directed verification strategy
using HDL is like a using a pea shooter to individually target the gnats
(bugs) within the verification target area. The new-school way, if done
correctly, will need only a few sniper shots near the end of the
verification project"
Happy Bug Hunting,
- Sean W. Smith
Cisco Systems RTP, NC
( ESNUG 368 Networking Section ) --------------------------------- [04/12/01]
Concord, MA -- AVAYA Networking seeks ASIC architect, design and
verification talent. No headhunters, please. "shopkinson@avayactc.com"
============================================================================
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
|
|
