Editor's Note: Because the street storm drain was clogged, last spring
a torrential rainstorm here caused my friend, Phil's basement to flood.
He ended up with 6 inches of water. It was a finished basement, so the
water messed up the lower 6 inches of his sheetrock drywall. Later, his
homeowner's insurance company wouldn't cover the repairs because he
didn't specifically have a flood provision in his coverage. "No use
fighting what you can't win," said Phil. He gets no money for the flood
damages. Then last week Phil gets a notice from his insurance company
that his rates are going up and that he'll have to sign a "Mold Damage
Waiver" or lose his coverage! His house is now considered a "mold risk"
and there's nothing he can do to fight this. It's not an assessment
against him, it's an assessment against his house. So even though he
collected no money from the flood, he's going to be paying for it for
many years to come. Whoa. Watch what you tell your insurance company or
it just might come back to bite you in ways you can't possibly imagine.
- John Cooley
the ESNUG guy
( ESNUG 405 Subjects ) ------------------------------------------- [01/29/03]
Item 1: Broadcom & Marvell Gave Us A Real Runaround Just For Data Sheets
Item 2: ( ESNUG 404 #7 ) Rectilinear Blocks In PhysOpt/Apollo/Astro Flows
Item 3: Wall St. Wonders "Did Synopsys Actually Save Numerical Or Not?"
Item 4: ( ESNUG 404 #5 ) David Simmons' DC Scan Chain Fix Hold Tcl Scripts
Item 5: ( ESNUG 404 #6 ) Both DC & PrimeTime Runs Differ On HPUX & Solaris
Item 6: Averant Solidify vs Real Intent vs 0-in vs Verplex vs Tempus Fugit
Item 7: ( ESNUG 404 #3 ) TetraMAX Path Delay Patterns With Don't Cares
Item 8: Designer Seeks A Small, Simple, Cheap Graphical State Diagram Tool
Item 9: ( ESNUG 404 #2 ) Well, Formality Discovered Our Hand ECO Mistakes
Item 10: I'm Having Trouble Using Mentor Fastscan Along With DC-Expert-Plus
Item 11: Steve Golson Cites Verplex' Anti-Formality Disinformation Campaign
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 405 Item 1 ) --------------------------------------------- [01/29/03]
From: Chris Zimman <user=chris domain=cryptoapps spot mom>
Subject: Broadcom & Marvell Gave Us A Real Runaround Just For Data Sheets
Hi, John,
We're a small company that does embedded design for other companies
(usually specifically with high design security requirements), as well
as designing stuff ourselves sometimes.
For the design we're currently working on, we evaluated a wide variety
of SoCs and stand alone processors for a wide variety of reasons. Two
companies that make products that looked interesting for our design
needs were Broadcom and Marvell. I'll detail my experiences with each.
Broadcom has a relatively new processor family, the SiByte series, that
they produce. They're dual MIPS64 SoCs with DDR, 2 or 3 gig MACs, 32/66
PCI, a HyperTransport host bridge, blah blah. I simply wanted a data
sheet on these so we could better understand the features of the device
and see what'd it take to get one of these up and running. We deal with
Insight Technologies (Memec) for our relationship with Broadcom. We've
had a great experience with them, and they've been generally very helpful.
When I went to our rep to get these data sheets, she told me that in
order for her to get access to the data sheets, she'd have to fill out a
"market opportunity form" or something to that effect for Broadcom.
Some of the stuff they request is completely understandable -- "How many
units do you anticipate using in a year?" "In what time frame do you
estimate going into prototype?" -- but then, some of the stuff they ask
is completely unbelievable -- "Who is the end customer? (like
specifically who, not generally)" "Describe in detail the application
for the SiByte" "How will the SiByte be used in the design?" Since we
operate under NDA with our customers, I usually can't say much about who
we do things for or what we do for them. To me, that's none of Broadcom's
business anyway. From my end, our relationship is that they sell chips and
we buy them -- end of story. I was told that without filling this out,
there was no chance of getting access to the data sheets. Taking the path
of least resistance, I went along with it and gave them what I could. After
sending that request in, she gets *another 5 pages* of marketing info
related forms as a response from her inside sales. More of the same -- lots
of detailed information about what we're going to be doing with these
devices, etc. For a company that's so concerned with the secrecy of
their products, they ask way too much about their customers proprietary
info.
I was pretty frustrated at this point, so I called the Insight regional
sales manager for Broadcom and basically told him that this interface was
total horsehockey. He said that while he was sympathetic to my feelings,
I needed to understand that Broadcom is trying to protect their interests
and has very limited support for these products, and *that's* the reason
that they behave in this fashion. Of course we all know what that boils
down to, which is that the silicon is likely very buggy and requires a
lot of hand holding and that they want to damage control.
Now with Marvell, the story is roughly the same, but there are some
intersting differences. Marvell has two lines PowerPC bridges that they
sell, the 64260 and 64360 series (Discovery & Discovery II respectively).
The 64360 is an update design with PCI-X and DDR support as well as 3 gig
MACs. On paper, it looks like a really nice design and could be well
suited to our application. In standard form, we contacted their sales
reps, Trinity Technology, and were given a bilateral NDA to sign and
return, which we did. Marvell maintains all of their documentation in
an web based access facility called CIRP. I was told that from returning
the NDA, it would take 2 weeks to be given CIRP access. That's a hell
of a long time to add a login to a website. Our rep told me he could
expedite it to a 2 day process, which was a lot more along the lines
that I had in mind. In the interim, he agreed to send me the data sheets
for the 64260 and 64360, which he did. That was immensely helpful,
because in the time I was supposed to be waiting for full access, I
could get a good handle on the chips and build up the part libraries. What
I still needed though were any reference schematics and data sheets on
their Alaska line of gig PHYs. Almost a week later, I still didn't have
CIRP access, so I began calling around. A few calls to Marvell (you
have to hound them, because no one ever returns calls) got me in touch
with a gentleman inside of Marvell who told me that the NDA had been
approved by Marvell and that CIRP access would be coming shortly -- but
only for the 64260. "We want to wait a little while on the 64360 because
it's a new product." Well a crap lot of good that does me, because the
64360 is the series we're interested in using in our design. I told him,
"Look, I already HAVE the 64360 docs, so I don't see what the holdup is."
I couldn't get any further with him though and so started looking for
another avenue. I spoke with the Marvell regional sales manager for
Trinity and he said he'd go in and try to retrieve the data sheets
for me himself. As of this writing, I'm still waiting for them. I was
told, as is the case with Broadcom, that Marvell likes to really
think about who they "partner" with, because support is limited and
because they're worried about design theft. I can't believe these clowns.
It's no big secret that the earler revs of the 64260-B-0 were buggy as
hell and almost unusable in some respects, so I wonder if this is the same
case with the 64360. And as for design theft, give me a break. It's
commodity IP for the most part -- two PCI-X interfaces, 3 gig MACs, a 32
bit peripheral bus, and a 6xx PPC interface. Granted it has a nice
fabric to tie it all together, but beyond that, who cares??? It's just an
integrated host bridge and a means to an end for us.
The point in all of this is that these two companies have been unique in
my experience. Broadcom has some really excellent engineers inside of
it that I've been able to deal with when you can find your way to them.
I wouldn't know with Marvell, because I haven't gotten that far with
them. Both companies are pretty much asses when it comes to dealing with
their marketing interfaces though, which unfortunately, for first
contact, is what you get. I guess unless you're Cisco or someone like
that, you don't matter to them. If that's the case, I can't understand
why they even bother announcing their higher end products.
No other large (come to think of it, large or small) company that we've
ever dealt with has been so difficult. I'm hoping that this is not
becoming industry standard practice. Is anyone else seeing similar
runarounds from Broadcom and Marvell?
- Chris Zimman
Cryptographic Appliances, Inc. Roseville, CA
( ESNUG 405 Item 2 ) --------------------------------------------- [01/29/03]
Subject: ( ESNUG 404 #7 ) Rectilinear Blocks In PhysOpt/Apollo/Astro Flows
> For our upcoming hierarchical design chip, I see that our blocks will be
> well utilized based on the connectivity and functionality -- if our blocks
> are allowed to be rectilinear (non rectangular) in shape -- rather than
> the conventional rectangular shapes. Even though the EDA tools out there
> claim that they can handle rectilinear shapes, I am very positive that I
> will run into a lot of implementation and integration issues in doing so.
> So I am wondering if your readers have experience in handling rectilinear
> blocks, especially with Synopsys (PhysOpt)/ Avanti (Jupiter/Apollo) tools.
>
> Some stuff that I am curious about are
>
> 1. How difficult is it in getting the pins assigned when the number of
> edges exceeds 4?
> 2. Is power routing capable of dropping straps of different lengths
> because of different dimensions in one direction or do I have to
> manually alter the lengths?
> 3. Will writing out the GDSII have any problems?
> 4. Can the parasitic extractor handle arbitrary shaped blocks?
>
> Plus is there anything else that would make my life miserable here?
>
> - Jay Pragasam
> Brecis Communications San Jose, CA
From: Jon Stahl <the.one=jstahl the.many=avici pot domme>
Hi John,
We taped out a design last April using Jupiter/Physopt/Apollo and one "U"
shaped rectilinear block. The block had pins on 6 of the 8 sides. We taped
out with Avanti version 2000.2.3.4.0.8.4_64.
Surprisingly we found only one problem with the entire rectilinear flow. At
the time, the Jupiter function to align the pins of adjacent blocks didn't
work on our "U" block. I don't know if this has been fixed or not in later
rev.'s.
- Jon Stahl
Avici
---- ---- ---- ---- ---- ---- ----
From: Joerg Landmann <user=lama domain=oaktech.de cowcowcow>
John,
Here's some info about the rectilinear topic. In one of our latest designs,
we had done a U-shape core in a PhysOpt/Apollo flow.
- Pin assignment was semi-automatic using Jupiter and hand-placements.
Jupiter is hard to use, so we had to do a lot of manual tweaking.
- I can not remember any power routing problems. But since this can vary
so dramatically, this is not representative.
- GDSII: no problems.
- StarRC-XT: no problems.
But generating the keepout regions for PhysOpt (especially wiring) can be
a bit tricky.
- Joerg Landmann
Oak Technology Germany
---- ---- ---- ---- ---- ---- ----
From: Neel Das <mongol=neel.das horde=corrent squat qualm>
Hi John,
I wanted to send in my 2 cents in response to this query on rectilinear
clusters.
We at Corrent have the dubious distinction of having to deal with numerous
such clusters, using Cadence First Encounter (for tapeouts) and Synopsys
FloorPlan Compiler (currently in eval). We use a PhysOpt/Apollo flow to
implementation our clusters themselves.
My advice is to avoid them altogether and simplify your life. If you can't
do that,
a. don't trust marketing slides from your EDA vendor: make sure you
review pin assignments thoroughly on these.
b. make sure whatever floorplanner you're using has manual editing
capabilities(pin locations/geometries/layer etc).
c. if you have 'over-the-cluster' routing channels, make sure they're
getting built properly and are getting pushed down properly for
cluster implementation.
d. neither of the two design planning tools (Cadence nor Synopsys) I
mentioned above could deal well with multiply instantiated blocks
initially. We've had to spin mega hours with lots of people from
both companies concerning on this issue; fortunately the tools do
a pretty decent job for most cases.
e. if you have pins that are unconnected (or reserved for future logic,
eg. scan pins), prepare to place these by hand.
f. PhysOpt has trouble handling repeater-insertion type problems in
some cases, for long, thin floorplans. I've posted on this issue
in ESNUG 385 #11. What we do is place a max_cap constraint on the
design: PhysOpt seems to work better with a DRC constraint rather
than a timing constraint in such cases.
g. a general comment: watch out for congestion! Post-route optimization
doesn't work well (particularly for DRCs) if there is congestion.
This will continue to be the case until the routing algo's within and
outside PhysOpt converge.
h. we didn't run into specific issues wrt extraction/ phys verification
on these. Our issues were in the areas of design planning and
implementation (PhysOpt).
Hope this helps: good luck!
- Neel Das
Corrent Corp. Tempe, AZ
---- ---- ---- ---- ---- ---- ----
From: Andy Tan <wolf=atan pack=synopsys yacht palm>
Hi John,
PhysOpt supports rectilinear macros that is described as combination of
multiple rectangles. Each rectangle must be modeled as overlap layers
in the physical library. A rectilinear outline around the multi-rectangle
shape is created and areas around the shape can be used to place cells.
You specify keepout margins for the resulting rectilinear shape as well.
The rectilinear outline and keepout margins are used for placement and
legalization of leaf cells around the macros.
The variable that supports rectilinear shapes is
set physopt_rectilinear_macros true
By default, this variable is FALSE in version 2001.08. This variable will
be set to TRUE in version 2002.05, and onwards.
To handle these macros, a special library syntax is needed. We need to use
LEF OVERLAP syntax to model the strange shapes. This defines a "placement
blockage layer" in addition to the standard routing layers that are
normally declared.
A MACRO OBS statement can contain an obstruction with a LAYER type of
"OVERLAP". If a MACRO has a OBStruction of a layer with type OVERLAP, this
forms the placement obstructions for the MACRO and the MACRO bounding box
is no longer applicable for placement obstructions. This is usually already
described in your Physical Library (LEF) that you get from your ASIC vendor.
The number of RECT statements in the OBS construct can be 1 or more. Using
more than 1 RECT statement forms a rectilinear shape that defines the
placement region for the macro. LEF syntax (and PLIB syntax) also allows
for the use of POLYGON statements to describe the OVERLAP outline.
1) Layer declaration LEF:
------------------------
Declare a layer of type OVERLAP along with the other layer declarations
in the LEF. Here a layer BLOCK_OVLP is declared, which is of type OVERLAP.
LAYER BLOCK_OVLP
TYPE OVERLAP ;
END BLOCK_OVLP
2) Placement Obstruction
------------------------
Inside the MACRO definition, along with the obstruction declaration for
all the metal layers, also put the obstruction for the above declared
layer. This layer obstruction is treated as a placement obstruction.
MACRO BLOCK
:
:
:all pin location declarations
:
:
OBS
LAYER MET5;
:
: all metal layer obstructions in layer 5
:
:
:
:other Layer obstructions
:
:
LAYER BLOCK_OVLP
RECT 0.0 0.0 440.0 4386.0 ;
RECT 440.0 559.875 2443.0 4386.0 ;
RECT 2443.0 312.0 4546.0 4386.0 ;
RECT 4546.0 2186.0 5292.0 4386.0 ;
END
END BLOCK
When the LEF is converted to PLIB format, the OVERLAP statements also are
translated. Then, when PhysOpt uses the cell, it recognizes the placement
obstruction being rectilinear and correctly handles the cell's rectilinear
outline. You can see this by looking at the leaf cell(s) using psyn_gui.
- Andy Tan
Synopsys
---- ---- ---- ---- ---- ---- ----
From: Yung Wuu <teacher=yung school=synopsys ought bomb>
Hi, John,
Here's the Astro/JupiterXT flow on the blocks with rectilinear floorplans:
. Readnetlist/expand/bind
. Create rectilinear floorplan: axgRectiPlanner
. Automatic shape generation for L shape, T shape, U shape and
Cross shape
. User can draw (or using Scheme) for other rectilinear shapes
manually.
. Specify pin location in TDF file
rPin "urcs" 28 0.28 0.28 1 1 4.9
rPin "addr[10]" 28 0.28 0.28 1 2 6.02
rPin "addr[7]" 28 0.28 0.28 1 3 7.14
rPin "addr[5]" 28 0.28 0.28 1 4 234.5
rPin "addr[4]" 28 0.28 0.28 1 5 238.98
rPin "addr[3]" 28 0.28 0.28 1 6 240.1
rPin "addr[2]" 28 0.28 0.28 1 7 244.58
. Place pins on rectilinear boundary in scheme command
(axRectiPinPlacement (geGetEditCell))
. The down stream commands support the rectilinear floorplan
. Power/Ground Routing (axgCreateCustomWires)
. placement
. optimization
. routing
. PARA view
. gdsII out
. netlist out
In JupiterXT:
. customer can generate the above shapes during the hierarchical
floorplanning.
. do pin assignment/opt for chanel-based or abut-based for the
rectilinear shapes
. cut PG down for the rectilinear shapes
Hope this helps.
- Yung Wuu
Synopsys
( ESNUG 405 Item 3 ) --------------------------------------------- [01/29/03]
From: Cliff Conwell <cconwell inside e*n*t*r*u*s*t*c*a*p*i*t*a*l pot alm>
Subject: Wall St. Wonders "Did Synopsys Actually Save Numerical Or Not?"
Hi, John,
I read Mark LaPedus' article: Did Synopsys save Numerical? -- which was
fairly critical of Numerical's products.
http://www.eedesign.com/news/OEG20030113S0053
I was wondering if your readers agreed with him or had a differing
viewpoint?
BTW: I saw Aart de Geus at the Morgan Stanley technology conference last
week... kinda interesting that he seemed to step back from his belief that
Semiconductor R&D spend was tightly coupled w/ EDA spend. He said that
relationship was "overstated" by many in the industry. Also, their CFO was
hired by Intuit. I saw him at the Intuit presentation. Seemed to be happy
to have moved on from the EDA industry.
- Cliff Conwell
EnTrust Capital New York, NY
---- ---- ---- ---- ---- ---- ----
From: Galen Hoskin <soldier=galen_hoskin army=capgroup fraught lawn>
Hi John,
Galen Hoskin here. I cover the EDA industry for the American Funds/Capital
Group. What do you think about this Cadence acquisition of Celestry? Good
for customers? Does it hurt any other vendors in a meaningful way - Nassda?
And the Synopsys acquisition of Numerical, supports the Avanti RET business,
so I assume a negative for Mentor. Any material impact on Cadence?
Appreciate your advice.
- Galen Hoskin
Capital Research Company San Francisco, CA
( ESNUG 405 Item 4 ) --------------------------------------------- [01/29/03]
Subject: ( ESNUG 404 #5 ) David Simmons' DC Scan Chain Fix Hold Tcl Scripts
> This set of scripts will fix hold times on scan chain inputs using Design
> Compiler, by inserting delays...
>
> - David Simmons
> Toshiba
From: Lars Bo Graversen <larsg/larsg from c=h=i=p=g=u=r=u=s.d=k>
Hi John,
Nice set of scripts for hold time fixing on the scan chain from Dave. Just
thought that I would throw in a couple of comments and suggestions for
alternative approaches.
In the 'add_delay_cell' and 'sub_delay_cell' procedures, Dave has the
library name and the scan input pin name hardcoded. One suggestion for
improvement would be to have these in variables. This would make it
easier to reuse the scripts for other technologies.
The 'get_scan_hold_violators' uses 'get_timing_paths ... -nworst 1
-max_paths 10000' combined with a subsequent 'if $slack < 0.0' to find
the violators. By using the '-slack_lesser_than 0.0' option to
'get_timing_paths', only paths that are actually violating (having a
slack lesser than 0.0) would be returned. Then you wouldn't need the 'if
$slack < 0.0' and you would only go through the 'foreach_in_collection'
loop for paths that are violating. As a side benefit here, you could use
the size of the returned colletion to compare with the '-max_paths'
number (10000) to ensure that you have found all the violators (the size
of the collection should be smaller than 10000 in this case).
Disclaimer: I'm not 100% sure that the '-slack_lesser_than' option to
'get_timing_paths' is implemented in DC (it works in PrimeTime). If not,
the above is void.
I really like the 'exec_and_log' procedure. I have been wanting something
like that and never gotten around to figuring out how to do it. Next time
I setup a flow, I may shamelessly borrow this procedure. :-)
In my previous job (I was hit by the latest round of layoffs, so I am
currently unemployed), I did the hold time fixing on the scan chain as
part of a post-route IPO run in PhysicalCompiler (a similar approach
could probably be used in DC with backannotation). The IPO run was a
two-step run.
In the first step, set_case_analysis was used to set the design in 'normal'
mode. Min and max libraries were loaded and operating conditions set to
min_max. Doing this enables PhysOpt (and DC, I guess) to see min timing
using the fast library and max timing using the slow library. In this case,
it is generally possible for the tool to fix hold times (as seen with fast
timing) without violating setup (as seen with slow timing). The
optimization command was something like:
physopt -incremental -post_route
with 'set_fix_hold' on all relevant clocks and 'set_clock_uncertainty
-hold' used to add additional margin to the hold time calculations.
In the second step, the design was switched to scan mode using
set_case_analysis and the constraints changed as relevant for scan. All
this in the same run as above, using the same library setup. In this
run, we want to only fix hold times. This is achieved by using an
optimization command something like
physopt -incremental -post_route -only_hold
It is still possible to get the nice instance naming of the inserted
delay cells implemented in your scripts with the 'compile_instance_prefix'
variable (at least that's what I think the variable is, with my current
lack of employment, I don't have access to Synopsys manuals).
Anyway, just my $.02.
- Lars Bo Graversen
ex-MIPS and looking Denmark
---- ---- ---- ---- ---- ---- ----
From: [ Intel Inside ]
Hi, John,
Keep me anonymous please (Intel Inside).
The last two chips I worked on we fix all hold violations with a simple
three-step flow.
1.) First we generate a min delay report from PrimeTime using
"-path end".
2.) Next we parse the report and create a condensed two column report,
the first column is the amount the path violates and the second
column is the endpoint.
3.) The third step in performed in Apollo, whereby a Scheme script reads
the new report and inserts as many delay cells or buffers as
necessary to fix the violation.
No need to bring the netlist back into DC for modification and interate
between layout. One additional input to the Scheme script is a small table
that lists potential hold fixing cells and their corresponding delay, at
the same corner as the min delay report was generated. It's very simple
and very effective, as long as you have setup margin on the violating
paths such that adding delay won't cause setup violations.
I should also mention that our last two chips were small enough (<300K
instances plus XScale core) and slow enough (133MHz) that we haven't had
the need to use PhysOpt yet. Apollo can place and route our designs
pretty well.
- [ Intel Inside ]
---- ---- ---- ---- ---- ---- ----
From: Jeremy Birch <ceo=jeremy_birch company=pulsic ought psalm>
Hi, John,
With regard to fixing hold times in scan chains, David said in passing:
"Reordering the scan chain in order of clock delays is another
(and possibly better overall) solution to fixing scan shift hold
time problems, but is somewhat more complicated to automate."
Although this might be logically possible it would be a very bad idea.
Generally flops are placed with no regard to scan chain order (as the scan
chain is not speed critical), and often in fact the scan chain is not in any
way stitched during placement as this could badly distort the result.
Instead the scan chain order is determined by finding the minimum path
through the scan flops AFTER placement (ie like a travelling salesman
problem), only restricting the system to keep flops in the right chains
(i.e. right clock, limiting chain length etc).
There is no general correlation to where a flop is and the clock delay it
receives, so sorting by clock skew would potentially produce a real rats
nest ordering of the scan chain, which could burn a very significant
fraction of the available routing resource.
The best way to cope with scan issues is probably to ensure that the scan
input of the flops is designed to have small and sensible setup and hold
requirements so that the clock network can be easily designed to avoid
shoot-through and setup issues at the scan shift frequency. Any remaining
issues will probably only happen at the ends of the chains. You don't really
want to have to stick delaying buffers after every scan-flop just to avoid
shoot through which in turn will be exagerrated by minimising the routing
between the flops in the chain!
- Jeremy Birch, CTO
Pulsic Limited Bristol, UK
---- ---- ---- ---- ---- ---- ----
From: Alexandre Gnusin <stripper=alexandre.gnusin club=tundra cot prom>
Hi, John,
The following 3 DC-Tcl procedures perform the same task as David's scripts.
#================================================
# Converts DC collection to TCL string (case collection has 1 element)
#================================================
proc c2s {collection} {
return [lindex [get_object_name $collection] 0]
}
#===============================================
# Add delay cell before specified endpoint pin
#===============================================
proc add_delay_cell {delay_cell endpoint} {
echo "Adding delay cell for endpoint $endpoint"
set ipin [get_pins $delay_cell/* -filter "@pin_direction == in"]
set opin [get_pins $delay_cell/* -filter "@pin_direction == out"]
if {[sizeof_collection $ipin] > 1}
{echo "Warning: delay cell has multiple inputs!"}
set conn_net [all_connected $endpoint]
disconnect_net $conn_net $endpoint
create_cell [c2s $conn_net]_c $delay_cell
create_net [c2s $conn_net]_n
connect_net $conn_net [c2s $conn_net]_c/[c2s $ipin]
connect_net [c2s $conn_net]_n [c2s $conn_net]_c/[c2s $opin]
connect_net [c2s $conn_net]_n $endpoint
# set_load <empical load> [get_nets [c2s $conn_net]_n]
# If required, set empirical load
}
#==============================================
# Buffer all violating paths of the scan chains
# Arguments:
# 1. Path to library cell to insert (with 1 input pin)
# 2. Name of register's scanin pin
# Example: fix_scan_hold nlc13_slow108V125C/snl_1nsdel SD
#==============================================
proc fix_scan_hold {delay_cell reg_pin} {
set endpoints_list 1
while {$endpoints_list != ""} {
set enpoints_list ""
foreach_in_collection path
[get_timing_paths -to
[get_pins -hier */$reg_pin] -d min -nw 1 -max 10000] {
if {[get_attribute $path slack] < 0}
{lappend endpoints_list [c2s [get_attribute $path endpoint]]}
}
foreach endpoint $endpoints_list {add_delay $delay_cell $endpoint}
}
}
I wrote them about two years ago, but doubted to put them into my web site
http://www.TCLforEDA.net because I didn't find them really important. I
still believe, that at this moment they are more competitive and reusable
than Dave's scripts.
- Alexander Gnusin
Tundra Semiconductors
( ESNUG 405 Item 5 ) --------------------------------------------- [01/29/03]
Subject: ( ESNUG 404 #6 ) Both DC & PrimeTime Runs Differ On HPUX & Solaris
>> Our team is trying to close on timing analysis (using PrimeTime) with our
>> ASIC vendor on our post-route netlist. We are using PrimeTime
>> 2001.08-SP1. Our vendor is running Linux and Solaris and gettings the
>> same results on either platform. Here running on HPUX we get different
>> violators from the vendor using the same constraints and scripts. We
>> also checked the violators using the following commands:
>>
>> 1. report_analysis_coverage ......
>> 2. report_timing -delay_type min ......
>> 3. report_constraints -all_violators -verbose ....
>>
>> All commands show that we have 34 hold violations and they are all the
>> same. But our ASIC vendor running the same scripts reports zero hold
>> time violations running under Linux and Solaris. Does anyone know of
>> any reason why there would be discreprencies across platforms?
>>
>> - Craig Taniguchi
>> TRW
>
> From: Pierre Ragon <bullbullbull pprraaggoonn from lucent cot balm>
>
> Hi, John,
>
> I had a similar experience using Design Compiler 2002.05 on a Sun-Solaris
> workstation. What is even more puzzling is that running on same OS and
> workstation the same optimization of the same design gave different
> results. I start noticing it when we ran optimization of quite large
> partitions (20 to 25 k flops) of the design. Then the final area would
> differ. A test case for this has been submitted.
>
> - Pierre Ragon
> Lucent
From: Paul Zimmer <preacher=pzimmer church=cisco sought yawn>
Wait a minute. The original question was about PrimeTime, not DC. DC's
optimization algorithms are pretty complex, and seem to include a "wall
clock" element. Running the same scripts on the same machine with the same
loading will usually produce the same results. But change the machine to a
faster or slower model, even with the same OS, and you may well get
different results. I have seen this. Switch architectures and all bets
are off.
PrimeTime is a different animal. It's just a big spreadsheet (sorry, PT
developers - you know what I mean). You should get the same results no
matter what machine you run it on. Take one of the failing traces from
one of the runs, and report that exact path on the other machine with
-input_pins, etc. turned on. If you're running with SDF, you can easily
track down the culprit because all the numbers should have "*" and you can
go look the numbers up in the SDF file to see who's right! If you're
running with parasitics, first verify that the LIBRARY models are the same
(the .db files). If so, you may have to call up Synopsys.
- Paul Zimmer
Cisco
---- ---- ---- ---- ---- ---- ----
From: Gzim Derti <derti|itred shouting from agere/agere wrought con>
To: Pierre Ragon <pprraaggoonn of lluucceenntt clot von>
Morning John and Pierre...
John, you mention the "white space bug" that's been around forever with DC,
but I'd like to find out from Pierre what OTHER jobs were possibly running
at the same time on the system that he compiled his design on??
Back a couple of jobs ago, I was running into an issue where the same code
was running overnight and giving me one result, but when I'd run it during
the day (while I was working and doing things on the same box) I'd get
a different area. The only thing I could attribute the differences to were
the amount of "wall clock" time elapsed during the compile.
As we all know, DC uses a diminishing returns concept to tell it how long
to "churn" on a section of gates. According to everyone at Synopsys that
I talked to at the time they told me that their "clock" was the number of
"cpu clocks" spent on the design. My contention was that it was actually
using "wall clock" time and if the system were loaded with other things
"wall clock" time would pass while less actual "cpu clock" time was applied
to the synthesis run... and as such, DC would stop "churning" with fewer
optimization trys.
I've been called crazy concerning this (not to mention other things that
aren't relevent to the current discussion) by more than one person over
the years, but since the topic has come up angain, I figured I'd put it
out there and see what happens.
Anyway, thanks for listening.
- Gzim Derti
Agere Systems
---- ---- ---- ---- ---- ---- ----
From: Pierre Ragon <pragon|nogarp near l*u*c*e*n*t fiat yon>
To: Gzim Derti <ddeerrttii by agere|erega scott guam>
Hi Gzim, John
In my case it was not a matter of the white space bug. I read ESNUG 135 and
I believe that it covers a different issue. Everything was identical from
one run to the other. Machine, OS, source code, script etc. Now regarding
what else could have been running. Difficult to say. It is likely that
some light foreground activity was taking place like writing mails or
editing files. No other jobs were running in the background except for of
course some system activity. One thing that I can mention is that I have
logged a test case to Synopsys support. According to their support people a
job must produce always the same result when it is run in the same
environment. No one argued about the results could depend on the load of
the computer. This is why I am also very keen on understanding what could
cause that. Thanks for your interest,
- Pierre Ragon
Lucent
( ESNUG 405 Item 6 ) --------------------------------------------- [01/29/03]
From: [ Curious George ]
Subject: Averant Solidify vs Real Intent vs 0-in vs Verplex vs Tempus Fugit
Hi, John,
We used Averant's Solidfy briefly a year ago. Their property language was
very powerful, but the tool failed to deliver results. It is very easy to
write complex properties for easier checks with the language. This made
the tool spend days without any results. Finally the design engineers gave
up on using Solidify.
The reason I want to be anon is because, I am evaluating Real Intent and
0-In automatic checks. I am afraid that my opinions might be not based on
all facts. But at the same time, I would like to know what others are
thinking.
Verplex BlackTie automatic checks, Real Intent's Verix Implied Intent and
0-In's CheckList are the products competing in this space. I find all of
them almost the same except that whether they support mixed language or not.
My questions:
- what's the market share of Verplex, Real Intent, 0-In and Tempus Fugit?
- what equivalence checking tools can't find "like" semantic checks?
- right now the companies are coming up with three kinds of tools.
Automatic Checks
User Defined Checks
Pre-written properties for standard protocols like PCI, USB etc...
what's the market share of each above type of ABV?
At the same time, we also would like to verify the standard protocols
such as USB, PCI etc. using formal tools with the monitors provided by
vendors. Tempus Fugit and 0-in have products in this area.
- What are user's experiences with these tools? Are there any IP
providers working on Sugar or System Verilog based assertions?
Having used formal tools a little, it was annoying to debug thousands
of warnings. I started to like the 0-In's approach of building on
simulation results.
- [ Curious George ]
( ESNUG 405 Item 7 ) --------------------------------------------- [01/29/03]
Subject: ( ESNUG 404 #3 ) TetraMAX Path Delay Patterns With Don't Cares
> I am working on improving path delay fault coverage in a full scan design.
> For this I need test patterns which are not completely specified (i.e. for
> a given path, I need 0/1 values on the flip-flops that actually sensitize
> the path and "x" or don't-care on the flip-flops which do not effect the
> path.) How can I do this in Tetramax? If Tetramax can not do this, this
> should be possible using DC or Primetime. Does anyone have pointers to
> such a script ?
>
> - Puneet Gupta
> UCSD
From: Ken Butler <kenb/kenb/kenb yodelling from ti|it nought alm>
Hi, John,
Please tell Puneet that in recent versions of TetraMAX, he can use:
set atpg -norandom_fill
He may also want to use "set delay -mask_nontarget_paths".
- Ken Butler
Texas Instruments Dallas, TX
( ESNUG 405 Item 8 ) --------------------------------------------- [01/29/03]
From: Tomoo Taguchi <voice=tomoo choir=hp not sawn>
Subject: Designer Seeks A Small, Simple, Cheap Graphical State Diagram Tool
Hi, John,
I'm looking for a POINT tool that will allow the graphical entry of state
machines and generate HDL code. I know that a lot of ESDA tools like Summit
and others do this and more, but I'm not interested in any other
functionality. I know that probably 3-5 years ago there were a couple of
companies that produced such tools, but they all seemed to have disappeared
or got eaten. At least there hasn't been any discussion of it lately in
ESNUG. I'm looking for something small, simple, and cheap.
- Tomoo Taguchi
Hewlett-Packard San Diego, CA
( ESNUG 405 Item 9 ) --------------------------------------------- [01/29/03]
Subject: ( ESNUG 404 #2 ) Well, Formality Discovered Our Hand ECO Mistakes
> We looked briefly at Formality and found it failed some modules that
> passed Chrysalis. Since we still treat Chrysalis as the "golden model",
> we are rating Formality lower. Caveat: we don't have as much experience
> or spent as much time with Formality so we are still evaluating it.
>
> - Luis Basto
> Analog Devices Austin, TX
From: Howard Landman <tree=howard forrest=riverrock.org>
I'd be careful about that, Luis. Any tool can have bugs. Chrysalis Design
Verifyer had a subtle one I found a year or so ago where it interpreted an
unspecified corner case in Verilog differently from DC and NC-Verilog and
VCS. Basically, if you have (say) an 8-bit bus A and a 16-bit bus B (it
only matters that B is longer than A), then consider the statement:
B = ~A;
(The type of assignment doesn't matter either.) Two things need to happen.
Bus A needs to be extended from 8 to 16 bits, and all the bits need to be
inverted. The problem is that the language reference manual doesn't specify
the order of those operations, and the result is different depending on the
order. And not all commercial tools interpret this the same! So (a year
ago) if you synthesized this in DC it would simulate fine (gates = RTL) but
fail Chrysalis!
If I had two formal verification tools that disagreed, I'd want to be sure
I understood why.
- Howard A. Landman
Riverrock Consulting Fort Collins, CO
---- ---- ---- ---- ---- ---- ----
From: Juan Ponce <doctor=ponce hospital=sharpsec knot calm>
Hi John,
We recently faced the challenge of performing a "by-hand ECO" to our design.
Since we had significant effort invested in reliability analysis on our
prototypes, we wanted to implement minimal changes. Therefore, we used the
spare cells within our design and "hand-stitched" the nets required by the
ECO.
Because of synthesis optimizations and a flattened netlist, the design block
in question had little direct correlation to the RTL and it was difficult to
determine where to make the netlist changes. Our logic changes involved
adding a term or two to a complicated "load enable" path on a flip-flop. We
did our best to carefully implement the logic change, but Formality flagged
two registers as failing compare points during our VHDL RTL-to-gate check.
I found that Formality's pattern viewer was extremely useful in isolating
the problem. It graphically displays all of the input vectors that reveal
the failure. By looking across these vectors, we could instantly see that
there were only a few failing patterns that revealed the problem. A visual
inspection showed that a few inputs had the same value placed on them for
every failing vector. Inspection of these inputs very quickly led us to
an ECO'd net. Bingo. Due to the timing characteristics of the "hold" terms
for the registers in question, our initial fix had missed a couple of the
compare terms. We were then able to graphically pare down the logic cones
into a manageable size, and the vector annotation allowed us to visualize
the correct fix in a reasonable time.
Without the debug facilities in Formality, we would have gone thought a lot
more Tylenol trying to isolate the problem and determine a proper fix.
- Juan Ponce
Sharp Microelectronics Camas, WA
( ESNUG 405 Item 10 ) -------------------------------------------- [01/29/03]
From: Richard Conlin <convict=rich.conlin jail=paradigm-works squat psalm>
Subject: I'm Having Trouble Using Mentor Fastscan Along With DC-Expert-Plus
Hi John,
My current client uses DC-Expert-Plus for scan insertion at the block level
and Mentor Fastscan for top level ATPG vector generation. Our main issue
right now is how to verify that block level scan insertion went well BEFORE
actually assembling the entire chip and running through Fastscan. We've
tried using the
create_test_patterns -dft
command to generate patterns, but the resulting coverage numbers don't
correlate well with Fastscan due to differences in the libraries which the
two tools use. Since Fastscan is our "golden" ATPG tool, we'd ideally like
to use it to do our checking.
Our Mentor AE has informed me that Mentor provides a utility which will
convert a DCxP generated STIL file into Fastscan dofiles and testprocs. My
first question is whether or not anybody out there has experience either
directly with this flow, or with a similar one involving using DCxP in
conjunction with Fastscan, or other "foreign" ATPG tool? My second question
is how do people feel about DCxP's STIL file generation capabilities? Any
"tricks" one should know about before basing a design flow on it?
- Rich Conlin
Paradigm Works, Inc. Andover, MA
( ESNUG 405 Item 11 ) -------------------------------------------- [01/29/03]
Subject: Steve Golson Cites Verplex' Anti-Formality Disinformation Campaign
> "One of the main reasons customers continued to use Design Verifyer
> instead of Formality is that it is independently developed technology,"
> Dino Caparossi of Verplex marketing said. "They don't have to worry that
> their formal tool is making the same mistake as their synthesis tool.
> That's also one of the primary reasons that customers are still choosing
> Conformal over Formality, aside from our continued winning of the
> benchmarks. With this decision, Synopsys has essentially killed off their
> only piece of independently developed formal technology, which should make
> our job of migrating the remaining Design Verifyer customers even easier."
>
> - from EE Times 01/17/03 http://www.eedesign.com/news/OEG20030117S0027
From: Steve Golson <termite=sgolson house=trilobyte shot pawn>
Oh please, John.
Dino's comments makes me want to repeat Ronald Reagan's famous comment of
"There you go again!" I've heard this sort of FUD (Fear, Uncertainty,
Doubt) about Formality for almost 5 years now. (See ESNUG 282 #10) Back
then it was Chrysalis who said it, trying to boost support for their
pioneering tool Design VERIFYer.
Even less than a year ago (ESNUG 394 #4) users were *still* worried about
the same thing: "Formality and Design Compiler have the same engine! You
can't trust it! Aaaaah!" Well, actually, there was a kernel of truth to
this, but it's old news, and no longer relevant.
Come 'round my children, and I'll tell you a story...
Originally, Formality and Design Compiler *did* use the same front end: HDL
Compiler. Thus if there was a bug in HDL Compiler then it was possible that
during the initial parsing of the Verilog code, both Design Compiler and
Formality would get the same *wrong* answer. And your verification tool
would be useless. I don't know if this ever actually happened, but it was
possible.
Users pointed this out (ESNUG 283 #1), and Synopsys rapidly moved to fix the
problem. They bought a front-end RTL compiler called "Concorde" which was
developed independently by Interra Systems (http://www.InterraSystems.com);
so ever since 1999 or so for Verilog (and fall 2002 for VHDL) the Formality
front-end has been independent of Design Compiler.
Note the back end has always been different. It had to be. Formality uses
a four-state synthesis engine (1,0,X,Z) while Design Compiler collapses all
the X unknowns very early in the synthesis process to ones and zeros.
However, HDL Compiler is still there! If you use the "-hdlc" switch on
read_verilog then Formality will use HDL Compiler rather than the Interra
RTL engine. So you get the best of both: if one front end has a bug, you
can switch to the other. Can Verplex do that?
Furthermore, I think that having *some* code in common is a benefit for
synthesis and formal verification tools. For example, if you have a
schematic display capability, isn't it useful for *both* tools to have the
same GUI? This consistency makes it easier to learn the tool. Also it's
nice that Formality can use the same command line arguments as VCS. And I
think it's great that Formality can read .db library files. (Yes, I verify
the .db against the simulation files first!)
A large company like Synopsys has many opportunities to intelligently share
code across a diverse product line. For example, the Verilog library reader
in Formality is the same one used by TetraMAX. If there is a problem, you
have a wider user base who can catch it. Test cases are important, and
nasty snippets of Verilog code can be used to wring out many different
tools. (Actually I think this is one of the biggest benefits that Synopsys
got when it acquired Design VERIFYer -- all those test cases that Chrysalis
/Avanti had developed over the years.)
If Verplex wins in my customer benchmarks, that's great! I'll buy the tool!
But I don't think that being "independent of Synopsys" is a legitimate
reason to buy Verplex over Formality.
To the Verplex marketing folks out there: Give up the FUD. That dog won't
hunt any more. And don't belittle your competitor's products. Let us users
do that for you!
- Steve Golson
Trilobyte Systems Carlisle, MA
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 15,673 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
|
|
