> To make things worse, I noticed how Clark would flail his arms and legs
> about like a perpetual motion machine. It got me thinking even more.
> After estimating the mass of his arms and legs, carefully measuring the
> distance of motion, and timing his movements, I calculated how much
> kinetic energy he expended within a 24 hour period. I then added up
> the caloric content he was getting from his formula -- and I then
> discovered that babies also violate that other silly old "energy can be
> neither created nor destroyed" belief. For every kilojoule a baby
> consumes, it easily expends at least 4 to 5 kilojoules of energy.
> Easily. (And if you add acoustic energy, that ratio readily grows to
> 8 to 10 times energy consumed.)
>
> - from "A Troubling Conspiracy"
From: Adam Sherer <asherer@cadence.com>
John,
As the father of two, I can absolutely vouch for the validity of your
discovery. I'd like to add two more observations, though. Children in
motion tend to stay in motion. Children at rest are not my children.
- Adam Sherer
Cadence Design Systems
( ESNUG 365 Subjects ) ------------------------------------------- [02/15/01]
Item 1 : ( ESNUG 346 #5 ) Need Avanti Scheme Scripts For PhysOpt PDEF 3.0
Item 2 : Run-Time Issues w/ Cadence PKS; Area Issues w/ Synopsys PhysOpt
Item 3 : Customer Pissed About Synopsys Hotline & "New" Maintenance Costs
Item 4 : ( ESNUG 364 #1 ) Chip Architect Is Over-priced For What It Does
Item 5 : ( ESNUG 364 #11 ) 2 Users Share Synchronicity DesignSync Troubles
Item 6 : ( ESNUG 363 #4 ) Newbies Trying To Control VCS from the PLI
Item 7 : ( ESNUG 362 #5 ) Other UNIX Tips & Tricks For Those Long EDA Runs
Item 8 : ( ESNUG 363 #8 ) No, Janick Was Right; Verilog & Superlog Do Suck
Item 9 : Our Chip Express Clock Buffer Insertion Nightmares With DC 00.05
Item 10 : ( ESNUG 364 #3 ) 4 Users Discuss A Boatload Of Synopsys ACS Bugs
Item 11 : ( ESNUG 363 #9 ) PrimeTime 2000 SPF Timing Models Too Optimistic
Item 12 : ( ESNUG 364 #14 ) Why Not Use PKS Instead Of Cadence PBOPT ?
Item 13 : ( ESNUG 364 #9 ) Now I Fight PCB Designers For My DW Licenses!
Item 14 : ( ESNUG 362 #3 ) Non-Error "Errors", DC/PT Tcl Nasties & ACS
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 365 Item 1 ) --------------------------------------------- [02/15/01]
Subject: ( ESNUG 346 #5 ) Need Avanti Scheme Scripts For PhysOpt PDEF 3.0
> ... We had to write Scheme scripts to be able to dump out a version 3.0
> PDEF file for PhysOpt to read in, since the Avanti PDEF files were dumped
> out in version 2.0. An apps engineer from Synopsys helped set this Scheme
> script up for us.
>
> - Bob Prevett
> NVIDIA Santa Clara, CA
From: Andrew Pagones <Andy_Pagones-ACIC22@email.mot.com>
Hi John,
We are running into the same PDEF 3.0 for PhysOpt problem Bob reported back
in March 2000 (11 months ago!) Wouldn't you think Avanti would have fixed
this by now?! Could anyone who has them please send us the Scheme scripts
used to process the Avanti PDEF 2.0 files for PhysOpt?
- Andy Pagones
Motorola Labs/CSTL Illinois
( ESNUG 365 Item 2 ) --------------------------------------------- [02/15/01]
From: Jay McDougal <jay_mcdougal@agilent.com>
Subject: Run-Time Issues w/ Cadence PKS; Area Issues w/ Synopsys PhysOpt
John,
Our dual PhysOpt/PKS tape-out was done because we ran into some run-time
issues with PKS on that core. It was taking 6 days to compile and we
couldn't get any debug/improvement cycles in. The PhysOpt run took about
1 day but had about 10% larger area. So, I used Ambit to get an initial
netlist with the area savings and PhysOpt to get a placement. I then
returned to PKS after our internal scan insertion tool and clock tree
generation to do the final timing tweaks. This allowed me to use the SE
compatible global router in PKS, do incremental optimization based on that
global route, and get less than 2% difference in pre- and post- final route
timing in SE. With a PhysOpt placement, we see 5-10% difference in pre-
and post- route timing.
- Jay McDougal
Agilent Corvallis, OR
( ESNUG 365 Item 3 ) --------------------------------------------- [02/15/01]
From: [ I Am Sparticus ]
Subject: Customer Pissed About Synopsys Hotline & "New" Maintenance Costs
Hello John,
Please do not reveal my identity.
Synopsys used to have a maintenance option that allowed customers to pay
for software updates & Solvit access. This was significantly cheaper than
paying for full support. Synopsys no longer offers that option and with
the increase in tool prices my maintenance bill is up almost 60%. I don't
understand why I should pay for services I don't use. Calling the Synposys
hotline is useless. All they do is ask for a test case and file a STAR.
And the FAEs who are any good work for the consulting group and Synopsys
charges $$$$ for their services. I haven't heard many complaints on this.
Is everyone else OK with this?
- [ I Am Sparticus ]
( ESNUG 365 Item 4 ) --------------------------------------------- [02/15/01]
Subject: ( ESNUG 364 #1 ) Chip Architect Is Over-priced For What It Does
> We have a copy of the Chip Architect tool and have attended the training
> sessions. While they loudly tout that it supports hierarchical placement,
> what is really true and mentioned offhand by John Stahl is that it can
> ONLY do separate placement on each and every hierarchical block.
>
> That means that even DesignWare inserted levels of hierarchy must be
> physically regioned on the die if left in the netlist. This is absurd
> for large designs with hundreds of hierarchical instances!
>
> - Thomas Ayers
> Believe, Inc.
From: Lars Bo Graversen <larsg@mips.com>
Hi John,
At MIPS, we have been evaluating Chip Architect as a front end to Physical
Compiler and have been happy with the results.
We have used Chip Arch to do floor planning before taking the design into
PhysOpt. This has worked well for us, once we got the 3.0 release of Chip
Arch, because the previous version of Chip Arch could not interface
directly with PhysOpt using a .db file. We have used the ChipArch/PhysOpt
flow with several different configurations of a 64 bit processor core
(different technologies, cache RAM sizes, etc.) Not multi-million gate
designs, but designs where timing (speed) is the most important parameter.
We plan to continue to use ChipArch/PhysOpt in our flow in such a way that
a design project will be responsible for iterating on the floor plan using
Chip Arch and PhysOpt before handing off the design to our Avanti backend.
In other words, I think that Chip Arch works well as a front end to PhysOpt,
but we don't use it to do placement. Hopefully, Chip Architect will be
priced according to this new (more limited, I guess) role. :-)
- Lars Bo Graversen
MIPS Technologies Copenhagen, Denmark
( ESNUG 365 Item 5 ) --------------------------------------------- [02/15/01]
Subject: ( ESNUG 364 #11 ) 2 Users Share Synchronicity DesignSync Troubles
> Your readers are being a little tough on Synchronicity's DesignSync. It
> is a part of the very fabric of life here at Cypress, and we're successful
> in using this tool to allow us to distribute design work among Cypress
> design centers worldwide. Sure, we have a few problems, and sure, it
> takes longer than we'd like to copy data from India or the UK. We have
> to devote CAD resources to its maintenance. But it is working for us,
> and we have made dozens of chips successfully with it.
>
> - Grant Erwin
> Cypress Washington State
From: Bill Corr <bcorr@micron.com>
Hi John,
I noticed on the DeepChip site that you were asking for feedback from users
of the Synchronicity tools. Well here it is...
I would like to comment on my experiences implementing a Synchronicity
design management framework in a community of around 30 engineers. I had no
say in the purchase of this product nor was I involved in the Sys Admin side
of it's roll out. I have taken the "out of the box" product and fitted it
to the needs of the local design community.
So what is it like? Once you have got to grips with the concept of vaults
and local workspaces it is all very simple. You populate your local
directory with the design files you want to use and off you go. You can
check files in and out with the GUI or from the command line. The Project
Sync side is also quite simple and easy to use (it runs on your browser).
It really is nothing special, but it works. The Project Sync framework is
very customisable and Synchronicity use it for their own customer bug
tracking system which users can access via the web for support.
Design Sync also manages Cadence DFII objects, known as collection objects.
So you can say 'check in the layout for cellx' and DesSync checks in the
layout.cdb, master.tag, pc.db and prop.xx file together. This is great in
principle, but if you want to have a cell-centric data space containing more
views than just Cadence ones i.e. cellx/layout, cellx/documents and
cellx/synopsys then Synchronicity won't help you at all. Basically you
can't do this. Cadence is quite happy with this data structure in DFII, but
Design Sync can't cope with this. You can either recognise Cadence objects
or not. If you choose to recognise Cadence objects DesSync will ignore the
contents of your Synopsys directory. If you choose to disable recognition
of Cadence objects (to see your Synopsys objects), DesignSync will make a
mess of your Cadence views. It will check-in each of the Cadence files
individually and thus make it impossible to access them from DFII. Not very
clever. It does say you shouldn't do this in the manual, but then engineers
don't always agree with manuals.
However the DFII integration does work well. In my experience circuit
designers aren't interested in revision control, anything that can help them
manage their data without getting in the way is good news. From within the
DFII framework it is quite simple to use Synchronicity. You just open a view
for editing and it is automatically checked out for you. There are two ways
of getting to Synchronicity from within DFII, the Synchronicity drop-down
menu and via the Cadence library manager. Both ways work, though going
through the Synchronicity menu is slicker and is the recommended route.
As to files getting lost I can definitely say that I have never seen this
happening. What can happen is that a user changes their mind about where in
their workspace or server vaultspace they want DesSync to put their files.
If they are not careful about how this change is performed the server will
not place the data where it is expected, leading to confused users claiming
that the data has been lost. In all cases I have experienced of this the
server vault has been correct and no data actually lost. Checking in the
first design database can be a bit hit and miss. There is a wizard that is
genuinely useful, but for some reason if you say you want to put directory A
in the vault, the contents of directory A get put in there and not directory
A itself. This is quite confusing, but you get used to it. Once the first
database has been done it becomes a lot simpler as you then have a framework
to work around.
Things I don't like about the Synchronicty tools - the GUI is a port from a
Windows implementation and you can't copy/paste from text fields. This is
very poor indeed. The speed of access to vault data could be better, ver 3
(the latest release) is much faster than the previous version, but still
not really fast enough.
The command line mode has two 'cd' commands 'cd' and 'scd'. They do
different things, the problem is I am forever typing 'cd' when I should
really be typing 'scd' (the 'scd' command used to be called 'cd' until the
latest release), each time I get it wrong I get an extremely misleading
message saying the directory I want doesn't exist - prompting more 'cd'
commands until I remember what I am doing wrong. This is extremely
annoying.
Things I do like about the Synchronicity tools - the system may not be
perfect, but it works well and the integration between DesignSync and
ProjectSync is good. The ability to customise Project Sync is very good and
the batch mode commands available for DesignSync are very good. The DFII
integration works well, it's a shame that the DFII object handling by Design
Sync seems to be an afterthought. The triggers that can be set to 'fire'
when events happen to vault objects are excellent and easy to set up. They
are a great idea, probably the best part of the system.
The online help system is good and the technical support (via the SCINC
online help desk) is good too. Most problems get a reply within the working
day. This is infinitely better than other EDA vendors I can think of.
So on the whole I am quite happy with the system. I wasn't involved in it's
selection, so I didn't compare it with other tools and I don't know how much
better or worse it is than it's competitors, but it works and it is being
used by most of the engineers on my site. The libraries generated are being
shared with colleagues around the world with a remote mirror which took me
about ten minutes to set up.
A final note - the spell checker's recommended replacement for DesSync is
'dissent', which is exactly what you get when you tell a group of circuit
designers they are going to use a revision control system!
- Bill Corr
Micron
---- ---- ---- ---- ---- ---- ----
From: [ Elvis of Graceland ]
John, PLEASE KEEP ME ANONYMOUS !
We used Synchronicity up until version v212p1. I can't speak for ver 3+.
My first day at work, 2 years ago, they told me "you're not going to like
this thing called Synchronicity". Being fresh in the industry, I
didn't know what they were talking about, but a little while later I
understood. After everything started breaking months later, I was named
synchronicity czar at my company and began filing a steady stream of bug
reports. Eventually, we got things running again, but this was after
learning what commands not to rely on and what commands fail often.
A lot of the problems we had have been addressed in the latest release
(3.0). However, seeing how things were done in version 2 didn't give us
assurance that the company knows how to write software. Example: the null
operation of just pinging the server from a client would fail about 90% of
the time if it was the first thing you did in the morning. That's like
having 'ls' fail! It's not acceptable! We had cases where two people could
edit the same file. A hierarchical copy operation, copying many files,
might take 3 tries before everything got copied. It made the tool
impossible to script. On top of that, it was so slow that you never knew
if it was working or not. Labelling was so slow (over an hour to "label"
the project!?), that I wrote a Perl script that did the same thing 20x
faster. (By comparison, perl4 can label in 10's of seconds)
The ONLY thing that the company has to its advantage is that it is the
only company offering an interface between cadence tools and its version
control software. Synchronicity now owns the GDM interface of Cadence, so
it might retain its monopoly.
One telling thing: The company did not use its own version control
software during development of version 1 and 2 -- they used CVS. It wasn't
until management forced the company to use its own tool did they start
fixing things in version 3.
After much toil and turmoil with the tool, we decided to scrap the whole
thing and write our own interface for Cadence based on Perforce. We also
considered using CVS or even just UNIX tar/cp nightly.
Our project database contains about 35,000 files, used by about 50 users.
- [ Elvis of Graceland ]
( ESNUG 365 Item 6 ) --------------------------------------------- [02/15/01]
Subject: ( ESNUG 363 #4 ) Newbies Trying To Control VCS from the PLI
> I am attempting to drive VCS directly from another application using the
> PLI but I am having trouble actually getting the simulator to run for a
> specified length of time, e.g. a clock cycle. I am fairly new to the PLI
> but I can talk to and read stuff from VCS. Is there a PLI routine which
> will allow the simulator to be run for a specified time?
>
> - Richard Wilkinson
> Cambridge Silicon Radio UK
From: [ A Synopsys VCS CAE ]
Hi John,
I am a VCS CAE and I noticed in ESNUG 363 someone trying to control VCS from
the PLI interface. There are two ways to achieve that:
1) VCS running in Slave mode:
One can run VCS's simv in slave mode and then use commands like
VcsSimUntil(some_time) to run the simv for a given period of time. In
slave mode the "simv" execution is in complete control of PLI and one
can do some cool stuff like "run until a given expression is true", etc.
2) VCS running in Master (Normal) mode:
One can write a PLI, which has a Misctf application that gets initially
activated by reason "reason_endofcompile", then it adds
tf_setdelay(delay) to schedule itself after "current simulation time
+ delay", with reason "reason_reactivate". Every time the Misctf
application is executed it can call the III party application, and
reschedule itself by using tf_setdelay(delay), and so on.
Please contact vcs_support@synopsys.com and they can help you in getting
started in either of the above mentioned modes.
- [ A Synopsys VCS CAE ]
( ESNUG 365 Item 7 ) --------------------------------------------- [02/15/01]
Subject: ( ESNUG 362 #5 ) Other UNIX Tips & Tricks For Those Long EDA Runs
> I got hit by a little gotcha recently that I thought I should share. ...
>
> "dc_shell | tee -i logfile"
>
> This allows the use of control-C for dc_shell.
>
> - Bob Wiegand
> NxtWave Communications Langhorne, PA
From: Bob Alverson <bob@tera.com>
Try the script subshell:
csh_prompt> script
Script started, file is typescript
csh_prompt>
all stuff here goes in the file
csh_prompt> exit
Script done, file is typescript
Inside script, all the usual job control stuff should work.
- Bob Alverson
Tera
( ESNUG 365 Item 8 ) --------------------------------------------- [02/15/01]
Subject: ( ESNUG 363 #8 ) No, Janick Was Right; Verilog & Superlog Do Suck
> I enjoyed reading Janick Bergeron's piece in ESNUG, "Janick Pisses On
> Superlog". Janick writes superbly and his pieces are really
> entertaining. Still, I believe this time he went over the edge.
>
> Hardware verification languages are evolutionary not revolutionary as
> he stated.
>
> - Lauro Rizzatti
> Get2Chip
From: "Martin d'Anjou" <mdanjou@nortelnetworks.com>
John,
I must admit that I agree with Janick's point of view regarding Superlog.
Superlog provides nice features like re-entrant tasks, which opens the door
to powerful constructs like recursion and concurent calls, but fails to take
the verification effort beyond the current dead-end path of verilog: lack of
OO, lack of proper random generators, lack of temporal checking and
lack of functional coverage specification description to name a few. The
problem with Verilog is its simplistic linear procedural nature. Easy to
understand: yes. Easy to solve verification challenges: no. Is Superlog
helping: not enough because it completely misses the boat on the OO
technology. Superlog proponents bet that we will not need OO to verify
chips.
In Verilog, we wrote 4500 lines of code to describe our packet generators.
In Verisity E-lite I have written 500 lines of code (comments included) and
I support two more packet types than the Verilog solution. That's 9X less
code. Thanks to OO and built-in directed random generators. Superlog does
not embrace OO and does not have the powerful built-in generator E-lite has.
It would not have helped me much here.
With OO, we describe our packet generators and "augment" them with new
fields and new properties later. Using typical Verilog include
statements does not work because includes have to be in the older code
already, and includes blindly add code to existing modules. If Verilog
or Superlog were OO they would let you "re-open" an already defined
module in another file subsequently loaded in the compile process
without even touching the original one, and either append, pre-pend,
add new i/os or new tasks, or replace tasks, or just anything you
want. Superlog does not even bring C++ OO features to verilog.
High level constructs like lists are poorly supported by most languages
and rely on external libraries, except in E-lite. You can have a list
of almost any type in E-lite, not just unsigned integers or bytes. Lists
have been around for decades and people still think they have to build
their own libraries for them. I disagree with that. Come up with a
language that has lists built right into it, not the other way around.
Checking functional timing requirement always involves writing complex
procedure in Verilog. Superlog does not help me as much as E-lite on
this matter. In E-lite I need one line of code for most checks:
// Using the english to temporal expression dictionary
// in the Verification Advisor:
expect @X => {[N1-1..N2-1]; @Y} @clock
else dut_error("Check failed: Y did not occur within", N1, " to ",
N2," cycles after X");
Where are the powerful random generators in Superlog? In E-lite, I just:
// Apply a range to ethernet packets, will not affect other packet types
extend ethernet packet {
keep address in [FFFF_0000_0000..FFFF_FFFF_FFFF];
keep soft address == select {
5 : [FFFF_FFFF_F000..FFFF_FFFF_FF00];
2 : others; // "pass", "edges" are "other" are keywords that can
// be used here depending on what you need
};
};
Voila! The address field is self generating and restricted to an
interesting range for my test case but it can still take, 2/7 of the
time, another address in a wider range. You need complete procedures in
Superlog to do what you can do in a few lines of Elite code.
On the functional coverage side, we've traditionnaly been relying on a
mix of verification plan reviews, code coverage tools and code reviews
to decide whether we had covered all the features, and exercized them
to our satisfaction.
E-lite lets you *measure* functional coverage. You can actually measure
coverage items, like the input stimulus distribution. I do not see
that built-in into Superlog. You can attempt to do it though. You
will spend a tremendous amount of time creating routines to define,
count and classify coverage items. That's what Janick means when he
talks about statistics collection. Routines that run in the background
and collect the data you ask for in bins, and cross-correlate the
collected data together.
Simulation speed? The problem is to write testbenches, not the time it
takes to run them. We've built an LSF cluster of about 100 CPUs, and
we intentionnaly keep each testbench small enough to run overnight.
Testbench too long? Split it and add CPUs. The goal is to run
regression overnight, and we are far from using all our CPUs.
Some clever people have solved many problems in ASIC verification. Of
course this requries new thinking, new approach, new language. The
problem is we are so used to model our world using procedural languages
that we can't imagine any other way to model it. Yet we know the
limitations imposed by current HDLs, and it is not a question of learning
a new syntax, it is a question of spending time to learn a different way of
modeling a verification environment. You know a new language has become a
necessity when you can't easily model and structure your code the way you
picture it in your mind, easily and concisely, with the language you
already know.
Get more done, write less code. It's the only way to keep up with
Moore's law.
- Martin d'Anjou
Nortel Networks
( ESNUG 365 Item 9 ) --------------------------------------------- [02/15/01]
From: Matt Gavin <mtgavin@collins.rockwell.com>
Subject: Our Chip Express Clock Buffer Insertion Nightmares With DC 00.05
John,
We are having problems here at Rockwell with getting Design Compiler to
insert clock buffers in our designs. I was hoping some of your readers
could help. (Also, a big THANKS to those of you who have helped me with
questions in the past.) This is a somewhat long email; thanks in advance
to those who can follow it. FYI, we are currently using Synopsys 2000.05.
Our ASIC vendor (Chip Express) requires us to insert specific clock buffers
(as well as reset buffers) on our global clock and reset lines. We send the
vendor a pre-layout netlist; the vendor does place and route for us, so they
also do clock buffer tree synthesis. The buffer we insert is just a
placeholder for this buffer tree which Chip Express will insert.
Chip Express claims that Synopsys should be able to automatically insert the
(correctly sized) buffer for us. (Larger buffer sizes are used for larger
clock domains). However this has never worked for us. This is SUPPOSED to
work through two mechanisms: the 'max_capacitance' attribute, and the
'connection_class' attribute. Their library puts a connection_class
of CLOCK_NETWORK on all its flop clock inputs (and NO connection class on
its combinatorial cell inputs). The clock buffer output also has the
CLOCK_NETWORK connection class. So Design Compiler should (in theory) use
one of these clock buffers to fix connection_class violations on clock nets,
and the correct size will be chosen via the max_capacitance attributes on
the buffer output.
However, until recently, we had VERY little luck with getting this to work
on ANY clock. Recently we discovered that Synopsys 1999.05 and later
introduces the concept of "ideal nets" for all clocks by default (thus
exempting them from design rule fixing, which would keep the clock buffer
from being inserted.) The "set_auto_ideal_nets -none" compile command
overrides this ideal net inferrence. Using this command, we now get the
correct clock buffers on most clock nets, except clock nets which drive
non-flop clock inputs. As far as I can tell, Synopsys won't fix the
connection_class violation on clock nets that drive combinational
logic. (We don't get any clock buffer on these nets.) This is somewhat
understandable since inserting a clock buffer on such a net could itself
cause a violation (a pin of class CLOCK_NETWORK would be driving a pin
with no connection class at all). Still, it is disappointing to have a
clock net which drives 1000 flops and one "AND" gate, not get buffered
because it drives that one "AND" gate.
Does anyone have a remedy for this? We are at our wits' end here, and
we get VERY little support from Chip Express. I tried to override the
connection_class of the buffer outputs, to "CLOCK_NETWORK default", so the
buffers could be allowed to drive combinational logic, but that did
not work (did not get the buffers). Also, I could see Synopsys using these
buffers for non-clock purposes, if the above override actually worked.
Can I get Synopsys to insert a clock buffer on a net, if the *majority*
(but not all) of loads on that net, have that same connection_class
(CLOCK_NETWORK)?
Until we get this working, we have to hand-manipulate the netlist, either
in the source code, or in Synopsys. It would be much more preferable
to get Synopsys to do this automatically, especially since our designs
change frequently, and thus the buffer sizes do as well.
- Matt Gavin
Rockwell Collins
( ESNUG 365 Item 10 ) -------------------------------------------- [02/15/01]
Subject: ( ESNUG 364 #3 ) 4 Users Discuss A Boatload Of Synopsys ACS Bugs
> A question I asked Synopsys when we first found the problem was "has
> anyone else used ACS?". They've been unable to come up with anything, so
> I was wondering if anyone in the ESNUG community would like to share their
> experiences? How they found its compile times, how well constraints were
> met, impact on layout, gotchas and successful techniques etc.
>
> - Tom Fairbairn
> 3Com Europe Ltd. Hemel Hempstead, UK.
From: Mario De Weerd <Mario.DeWeerd@mie.alcatel.be>
Hi, John,
I have tried out this ACS system from Synopsys in Q2 of 2000 to see if it
would obtain better results than what I was doing manually. I was using
V99.10(-4) of Synopsys ACS.
At the time I ran into 4 or 5 major problems with their system. I succeeded
in bypassing most of the bugs by modifying the ACS generated scripts or not
using certain combinations of options. The final staw for us was ACS had a
consistent crash of its budget_shell tool for which a STAR was issued
(105427). Since that date (16 Jun 2000), I have not been informed about the
status of this problem.
Prior to that, there was a problem with a gated clock that remained unmapped
after synthesis with ACS. This stems from the set_dont_touch_network
constraint adds set_dont_touch constraints on every combinational part of
the clock. This became STAR 105055. I have no feedback on that either.
Furthermore the 'set_critical_range' constraint is propagated for pass
"pass 0" (acs_compile_design) and not for the acs_refine_design or
acs_recompile_design passes. This was filed under STAR 104882.
So, despite my efforts, I was not able to obtain an acceptable results
with ACS mainly due to the fact that budget_shell was crashing. ACS is
surely no miracle system, and for optimum results, Design Compiler must
still be guided with the appropriate options that you can set by using
ACS attributes.
Maybe somebody else has more positive feedback.
- Mario De Weerd
Alcatel Microelectronics Colombes, France
---- ---- ---- ---- ---- ---- ----
From: Tom Fairbairn <tomf@pdd.3com.com>
John,
Many thanks for putting Mario in touch with me. Interesting stuff indeed.
It's taken us 2 months to get Synopsys to tell us of ANY other customers
using ACS at all!
Mario, thanks for your experiences. We've been struggling to get Synopsys
to refer us to some customers using ACS. It looks like it might be more
than just unwillingness to change methodologies causing the lack of
adoption. Bugs are a pain but bearable if they're fixed. Synopsys doesn't
seem to be committed to fixing ACS related bugs.
John, in the interests of sharing results, here's a table of ACS/Budgeting
related STARs Mario and I submitted for ACS:
STAR Num Description Fixed?
113984 budget_shell crashes on my design N
109279 timing exception on a block caused
that block to not be compiled due to
dont_touch Y
105427 budget_shell crashes on my design N
105055 set_dont_touch_network sets dont_touch
on all combinatorial fanout of that net N
104882 set_critical_range constraint not
propagated further than pass0 N
Thanks a lot guys!
- Tom Fairbairn
3Com Europe Ltd Hemel Hempstead, England
---- ---- ---- ---- ---- ---- ----
From: "Darach O'Murchu" <spud_chopper@yahoo.com>
Hi John,
I used ACS for our latest chip (comms chip, 200Mhz, 0.18 micron, 200 Kgates)
Synopsys version 2000.11.
I ran a pass1 compile (acs_refine_design) with no apparent problems, but it
did not improve on timing and it only yielded a 1.4% improvement in area
(over pass0).
I did have a few problems however with the initial compile run (pass0). ACS
did not derive some of the commands properly from the top level constraint
file when generating the constraint files for each partition of the design.
So a few hand edits were required:
- it did not propigate set_multicycle_path commands correctly
- it did not propigate set_dont_touch commands correctly
- some of the create_clock commands were screwy
- I was using a custom wire load model, so i had to re-write the
set_wire_load_model information for each sub design in each of
the partition blocks
This seams to offset some of the advantage of having ACS automatically
generate the individual partition level constraint files. But we were
satisfied with the clock speed our design achieved using ACS.
- Darach O'Murchu
---- ---- ---- ---- ---- ---- ----
From: Peter Kamphuis <peter.kamphuis@infineon.com>
Hi John,
Yes, somebody out there is using ACS. Well at least we are starting to
use it. Our current design system version offers the possibility to
use ACS as "kernel". Things like analysis, elaboration, scan insertion
and generation of data for backend are done with scripts similar to
those we have been using for a longer time.
We decided to implement ACS to be able to process larger designs more
easily. But, also to be prepared for future extensions by Synopsys.
Our synthesis environment now entirely sets up on Design Compiler's
Tcl-mode. Instead of ACS we can, for example, "plug in" Physical
Compiler. We are currently using release 2000.05-2. Unfortunetaly
we haven't had the time to take a closer look at 2000.11. We hope to
do that soon.
At Infineon in Munich there are two bigger projects that were the first
candidates for using this new, ACS based environment. No tape-out has
been done yet. I don't expect that to be different from other projects
however. We discovered a number of problems in using ACS, which I'll
try to describe in the following. Nevertheless I hope that more projects
will follow. Having learned from our first experiences, I think we know
how to handle ACS for these.
First issue should have been obvious: If one wants to process a complete
chip, the whole design needs to be budgeted. RTL budgeting can run for
hours. And also pass 1 budgeting needs appropriate CPU and memory
resources. Don't underestimate this. Our recommendation is to use ACS
on a level below chip-level and to only "link" chip-level together. Of
course this means that we must write constraints for more designs again.
The compiling of the ACS partitions after budgeting, using the parallel
processing capabilities of ACS, really improves run times.
Next, what should be obvious too, the parallel processing capability
of ACS needs many licenses. One license is always needed for the main
invocation of Design Compiler. Then one or more additional licenses
are needed to compile the ACS partitions.
Then we found out that not all top-level constraints are passed down to
the ACS partitions correctly. We know about the set_ideal_net and, as
discovered recently, the set_false_path or set_multicycle_path commands.
Luckily it is possible to patch any generated partition constraint
script. This should be improved, of course, by Synopsys.
Finally we are seeing problems with the use of LSF (Load Sharing
Facility) that is supported by ACS. This could be, however, dependent
on our infrastructure. At the moment that ACS starts a larger number
of partition compiles in parallel with LSF, a larger number of machines
try to access the same (automounted) directories at the same time.
Here we have seen various crashes of the LSF processes, leading to
incomplete results. As a workaround it is possible to reduce the
number of parallel processes. This means a longer processing time of
course. Problems may also arise when the parallel processes steal away
the last available license.
Nevertheless I think the ACS methodology has the ability to process
large designs more easily and faster. Some improvements are still
needed to be made by Synopsys. We see ACS as the tool for top-level
designers. For sub-level design development simple compile scripts
(and simple constraints) can be used. On top-level ACS will squeeze
the best out of the design.
- Peter Kamphuis
Infineon Technologies AG Munich, Germany
( ESNUG 365 Item 11 ) -------------------------------------------- [02/15/01]
Subject: ( ESNUG 363 #9 ) PrimeTime 2000 SPF Timing Models Too Optimistic
> With the new 2000 versions of pt_shell, we recently moved to doing timing
> with a SPF (our designs have been too large to attempt this before).
> Doing this however has some implications. PrimeTime claims to calculate
> an effective capacitance form the distributed RC_network in the SPF. For
> this it uses some algorithm, which assumes that there's a montonically
> increasing relationship between input transition/output capacitance with
> the cell delay and this should be expressed in the cell delay table. If
> it is not so, it says it found a negative driver resistance and failed to
> compute effective cap in which case it will use the lumped capacitance.
> This is optimistic for best case conditions (that is if we care!!)
>
> This is a a pretty bad assumption (and we know it!! after doing a lot of
> spicing!!)
>
> I reported it to Synopsys AE. They first didn't believe me, then when I
> gave them the library example, they wanted a test case which we couldn't
> give them because the library is from Avanti. So we asked them to come
> on site. They have been missing since then.
>
> - Ajay Kumar Sinha
> Silicon Systems India
From: David Chiappini <David.Chiappini@matrox.com>
Hi John,
I just wanted to thank Ajay for sharing this problem. I've been fighting
with it for a little while now. It should help having some "global"
confirmation.
- Dave Chiappini
Matrox Graphics Inc. Montreal, Canada
---- ---- ---- ---- ---- ---- ----
From: "Thomas D. Tessier" <tomt@hdl-design.com>
John,
Just want to say that it is good that Ajay has dug so deeply into this
issue. I also ran into something like this by the fact that I could NOT
get PrimeTime and my foundry delay calculator to track using the same
SPEF file; see details in upcoming SNUG 2001 paper. I even found a path
that I provided my foundry vendor to SPICE up and they indicated that
the foundry delay calculator was correct. Unfortunately for us they
would not provide us with the SPICE deck for this path so I had no way
of providing this data to Synopsys. I would say yes Synopsys is aware
but I feel the user base is currently being blocked by either other EDA
tool vendors or foundry's lack of information flow.
Tom Tessier
t2design Inc. Louisville, CO
---- ---- ---- ---- ---- ---- ----
From: Shane Dowd <smd@jennic.com>
Dear John,
This is one of the first pieces of information that I have found regarding
issues and problems with Primetime and delay calculation.
We are using SPF and SPEF from xCalibre to allow post-layout delay
calculation in pt_shell (2000.11 now). Initially I had assumed that things
were going to plan, but when you look in a little more detail you discover
the problems. I can only say that the RC-004 warning that you are seeing
are the same types of warning that I am seeing within pt_shell.
My issue is that I have an I/O library with operating conditions set to
WCCOM, NCCOM, and BCCOM, and a standard cell core library with operating
conditions set to fast, typical, and slow. I have found that for chip
level delay calculation I would expect to set the operating conditions to
those of the I/O library, however when I do this I get the RC-004 issues
for the core cells.
Initially I thought this was related to a units issue within the SPF and
SPEF but have since confirmed that this is not the case. In fact if I set
the operating conditions to the core levels (even though the current_design
is the chip level I do not get the RC-004 warnings. If I allow Primetime
to use the default operating conditions (i.e. I do not set any using
pt_shell commands) I get the same issues with RC-004.)
By admission from Synopsys, Primetime cannot handle multiple operating
conditions - however I have no confidence in the SDF being generated as the
operating conditions are for the core (with incorrect voltage settings).
Only advise given by Synopsys is to check for similar problems with the
library vendor (still waiting for answers). This must be the case for
every-one using a COT flow and DSM technologies, so why is it so difficult
to get information. I would be interested to hear if Ajay have similar
issues with multiple libraries and operating conditions.
- Shane Dowd
Jennic Ltd.
---- ---- ---- ---- ---- ---- ----
From: [ One Of The Lessor Pokemon ]
Hi, John,
Anon please.
I saw Ajay's post/note in your ESNUG post. Here's what I understand:
1. You do need the cell delays to be monotonically increasing with output
capacitance. This is I belive, quite a realistic requirement. If for
some reason your library is not monotonic with increasing load, then I
think its a library problem.
I guess that for the above you will land up getting "RC-004 ... failed to
compute c-effective" or some message of that sort.
2. Now from what I know, the library tables do NOT have to be monotonic
with increasing input transition time. This has something to do with
the way library cells are characterized, for eg. you might measure your
cell delay as being from 60% if your input to 50% of of the input. In
this case if your cell trips then you can have -ve cell delays.
In this case with non-monotonic slopes, I believe that you will not get the
"failed to compute C-effective" stuff.
- [ One Of The Lessor Pokemon ]
---- ---- ---- ---- ---- ---- ----
From: [ PrimeTime Tech Support ]
Hi John,
Ajay's problem is a known issue in the 2000.05 PrimeTime release and occurs
when:
1. Detailed parasitics (SPEF, DSPF) are backannotated.
2. Hold/min analysis is being performed.
3. PrimeTime is unable to create a driver model for its RC delay
calculation because the cell library data appears inconsistent
with rules of physics.
This issue has been resolved in the 2000.11 release of PrimeTime.
Here's some background ...
A cell's library data is created by simulating the cell with a set of
different output capacitances. If this output capacitance is increased,
then it will take more time to charge up, and the delay and slew times
will both increase as well. This sensitivity to output capacitance is
used by PrimeTime to set the drive resistance in its driver models used
in RC delay calculation. Therefore, PrimeTime uses this physics rule
and requires that delay and slew in the cell's library data to both
increase as output capacitance increases. A violation of this rule
in the library data prevents PrimeTime from creating a driver model
since the drive resistance will not be positive. A failure to create
a driver model subsequently prevents any calculation of C_effective.
When PrimeTime is unable to calculate C_effective, it attempts to use
fallback data so that it can still perform a calculation (although it
will not be as accurate). In the 2000.05 PrimeTime release, C_effective
would default to C_total (or lumped capacitance) for both setup (max)
and hold (min) analysis. When doing setup analysis, this will lead
to a pessimistic analysis since C_total will lead to longer delays
than with a true C_effective. However, for hold analysis ("best case"
as Ajay calls it), this will lead to slightly optimistic results.
This is the problem Ajay describes and is found in the 2000.05 release.
This issue of slightly optimistic results for hold analysis was
resolved in the 2000.11 PrimeTime release. In 2000.11, C_effective
falls back to 0, not C_total, during hold analysis. This will lead to
shorter delays than with a true C_effective and hence more pessimistic
results for hold analysis, not optimistic results as before. In many
cases, this may be very pessimistic since the true C_effective may
have been closer to C_total than 0, so the delay used will be much
smaller than the true delay. Nevertheless, it is still pessimistic.
Our strong recommendation is to use 2000.11 PrimeTime when you backannotate
detailed parasitics. You will not get these optimistic hold time
calculations should PrimeTime be unable to create a driver model.
- [ PrimeTime Tech Support ]
---- ---- ---- ---- ---- ---- ----
From: Ajay Kumar Sinha <ajay@siliconsystems.co.in>
Hi, John,
After a lot of test cases and sessions with synopys AEs, here is what I
gathered
1. There is still no support for libraries characterized at different
trip points. Maybe in future, till then bug ur library vendors.
2. RC-004 messages will/have disappeared in Primetime2000.11 for the
following
- Negative delay numbers in the library tables
- even if they are for increasing caps only that the relationship
between increasing cap and delay should be monotonically increasing
- for non-monotonic and monotonically decreasing relationship
between input transition time and delay
( I haven't tested these - maybe in a week or so)
But RC-004 will still appear if the relationship between output cap
and delay is either constant or monotonically decreasing or
non-monotonic. This is because of the way drive resistance calculation
is done based on the fact that 1% increased change in the Ceff will
give you a increased delay, which if it can't find in the table, it
fails.
The workaround for libraries which have constant delay for a range of
cap values is either
- change the library by putting increasing digits in the LS
digit of the delay values OR
- change the table to a scalar table
There is no workaround for libraries where the delay is decreasing
(maybe a insignificant amount but neverthless decreasing) or is
non-monotonic (e.g. for a range of cap values, the delay increases,
but for a certain cap, it goes down and unfortunately your output cap
is between these.) Maybe we should contact noel.menezes@intel.com
and ask him to enlighten us. He was one the authors for this theory
which Primetime uses to calculate Ceff.
Also, there were a few other issues with Primetime which I filed with
Synopsys and now are STARS. Just wanted to share these:
1. Primetime is not writing the SDF out correctly (happens whether you
have backannotation or not). It is treating 1'b0 and 1'b1 in the
netlists as nets and then calculating a delay number for the
interconnects. These interconnects are basically a combination (as
in probabilty theory) of pins connected to 1'b0 and 1'b1. Even with
SPFs Primetime is timing these arcs. It should ignore these nets
(treat as constant). This is a STAR now.
2. Primetime seems to be not annotating nets with long names at random
from the SPF. This is critical for long single fanout nets
(unfortunetly ours happen to be CLK nets!!). This is a STAR now.
3. report_net and report_annotated_parasitics commands give different
number of annotated nets/parasitics. This is also a STAR now.
There is also an issue of Primetime writing out edges for IOPATH delays
for non-sequential cells -- for example for the select to output path of a
MUX. Can people enlighten me on this? This of course happens even after I
switch on -no_edge option in write_sdf. I am still investigatig this and
do not know if the problem is with the library or Primetime. The reason
why this is important is that the latest versions of NC-Verilog (almost
de-facto for gatesims) do not honour such constructs!!
Finally , a point which I hope people are not forgetting about: SDFs from
SPFs need to be generated with the identical constraints with which timing
is done on the SPF -- else results from gatesims (annotated with the
generated SDF) will not match Primetime results. This is because of
multiple paths and distinction made by case analysis. Of course you need
to have the precision same else paths at the edge will fail because of
rounding errors.
- Ajay Kumar Sinha
Silicon Systems India
( ESNUG 365 Item 12 ) -------------------------------------------- [02/15/01]
Subject: ( ESNUG 364 #14 ) Why Not Use PKS Instead Of Cadence PBOPT ?
> I read Chris' article on ESNUG 363 with interest as I have been working in
> the area of hierarchical physical design timing closure for a few years
> now. I have a few questions for my own clarification and some suggestions
> that may help...
>
> - Lee Keep
> 3Com UK
From: Chris Simon <Chris.H.Simon@gd-is.com>
John,
This is to thank Lee for the response and advice. Since this is the first
time through a hierarchical design we are still learning, and what he's
written will certainly help. The designs we are working on are 125 MHz
using IBM 0.25 um CMOS. Not exactly bleeding-edge but still a challenge for
our Cadence tools, it seems. As we've refined our results I discovered that
the constraints on paths between blocks did allow for my 1.2 ns per 5mm, but
the paths to the I/Os did not. I am fixing this.
We did not do top level routing before designing the blocks on the first
chip, but we are in the process of doing just that for the next chips. We
also discovered the need for buffers at the outputs of all blocks, as near
to the ports as possible. We will look into how we can force the placer to
put these near the ports in every block. To try to make this easier on
ourselves we established the rule early on that all block outputs and inputs
are from registers. There is no logic allowed (other than a buffer) between
any block input and the input register, or between an output register Q pin
and the output port.
The pin optimization on the first chip was done manually, but it was a
simpler chip (i.e., fewer blocks.) On the next chips we will attempt to
have the tools do pin optimization.
- Chris Simon
General Dynamics Information Systems
---- ---- ---- ---- ---- ---- ----
From: Thad McCracken <thad@geocast.com>
Hi John,
I've got a few comments on Chris' repeater-insertion problem that will
hopefully be of some use. We transitioned from Ambit Buildgates to PKS some
time ago, and use that to do top-level repeater insertion now. We used to
use a similar flow to Chris, though, so I'll try to comment from memory on
that first. Finally I include a short description of our experiences
with PKS in this regard mostly for the future reference of Chris and other
ESNUG readers.
1.) "Black-box" timing models for your P&R blocks. We use black-box
timing models for our P&R blocks to drive top-level repeater insertion
as well. I have found it important to include in these blocks not
only timing characteristics (setup/hold, clock-q), but also all
applicable design-rule constraints (max input transition and pin
capacitance for all inputs, worst-case transition and max-capacitance
for all outputs).
These can sometimes help drive insertion of top-level repeaters.
2.) We've had similar dissapointments with QPOPT. On the last chip
we taped out w/o PKS we ended up putting top-level repeaters in our
netlist by hand, and controlling their placement with placement
regions.
In general I've found it to be helpful to put top-level standard cell
rows everywhere possible - don't depend on QPOPT or any other tool to
find the *one* place to put a repeater. We've found PKS to work reasonably
well for top-level repeater insertion, given the following inputs:
- top-level flooplan (we use .def format) that places all the IOs,
P&R blocks, top-level standard-cell rows, power grid, etc.
- .lib black-box timing models for all P&R blocks (as well as IOs, etc.)
Using this and top-level timing constraints, we run a quick optimation to
insert and place repeaters. Different types of optimization seem to work
better for some designs -- sometimes just "do_optimize -pks" works fine.
Other times specifically targeting design rule violations is better. I've
found setting the steiner mode to 1 or 2 (set_steiner_mode 1 or 2) to
generally yield better results for designs with lots of "macros." We also
found that tweaking with the following global variables helped for
top-level repeater insertion:
smoothen_area_gap (% of placement bin space that must be left
un-utilized after placement spreading)
extra_space_for_opt (amount by which optimization may overfill a
placement bin)
In v4.x PKS these default to 1 and 0. We found that setting the former
to 0 and the latter to a very high number (80 in one case) seemed to
help placement of top-level repeaters on one chip. I don't fully
understand why this works, but suspect it has something to do with
placement bins having mostly "un-usable" area. I'd like to understand
it more in the future. There are other knobs you could try in PKS
that might help as well, but I haven't played with them enough to say.
- Thad McCracken
Geocast Networks Systems, Inc. Beaverton, OR
( ESNUG 365 Item 13 ) -------------------------------------------- [02/15/01]
Subject: ( ESNUG 364 #9 ) Now I Fight PCB Designers For My DW Licenses!
> According to Synopsys sales, licenses for Synopsys LMG "Smartmodels"
> (SIMMODEL-PREM) licenses and Synopsys DC DesignWare (DesignWare-Basic)
> will soon be interchangable.
>
> - [ Kenny, from South Park ]
From: [ Locutus of Borg ]
Hi John,
Anonymous please, as I am trying to find the truth....
I, too, have been told that LMG Models and DesignWare are together by
Synopsys Sales. In fact, I was told that:
Lsmart + Ldesignware = constant
where Lsmart is smartmodels licenses you want, Ldesignware is DesignWare
licenses you want, and constant is the total number of SmartModels plus
DesignWare you currently own. I was also told that each DesignWare is
equal to one SmartModel Premium, but I was not told how each SmartModel
would convert to DesignWare.
With that knowledge in hand, I decided to run a simulation experiment with
4 users using SmartModels on LMG's latest release. Here is what I saw:
4 users NC VHDL
4 users SmartModels
4 users Designware
0 users of FPGA Compiler or DC
Hmm, what is going on here? By this logic, I am limited to the minimum of
Smartmodels and Designware in simulation, not a sum. Yikes!!! I also
verified that SmartModels do not equate to DesignWares. I instantiated a
DesignWare UART and ran FPGA Compiler 3.5.1:
1 user FPGA Compiler
1 user DesignWare
0 user SmartModels
Hmmm, so that means my SmartModels do not convert to DesignWare using the
Synopsys license minimization technique as in simulation.
Unfortunately, this is the type of product rebundling I would expect from the
Borg, woops I meant Synopsys. Does anyone have the real deal on what is
happening to SmartModels and DesignWare?
Resistance is futile!
- [ Locutus of Borg ]
---- ---- ---- ---- ---- ---- ----
From: [ Kenny, from South Park ]
Hi, John,
As I said we were going to do, we updated our licenses using new Synopsys
"Increment" scheme, and combined our "Smartmodel" Synopsys LMG licenses
with our "DesignWare" license into one file. Easier to admin that way.
Then we hit the road block. Since these are "Increment" keys, there is no
implied order in which they are taken in the license file. Thus it is first
come, first serve. So, people requesting Smartmodel license to do board
level simulation sometimes grab DesignWare licenses instead of Smartmodel
ones.
This leaves people running older versions of Synopsys (specifically 99.10.4
which is the only one our ASIC vendor will sign off on) out in the cold
because these versions can't grab an available "Smartmodel" license and use
it as a "Designware". All you can do is get the person doing board level
simulation to get out of the simulator (if you can locate him) then hope
nobody else grabs the license before you get to the point in your Synopsys
compile where you need a DesignWare seat.
- [ Kenny, from South Park ]
( ESNUG 365 Item 14 ) -------------------------------------------- [02/15/01]
Subject: ( ESNUG 362 #3 ) Non-Error "Errors", DC/PT Tcl Nasties & ACS
> I've been beating my head against Tcl as we're transitioning to use it
> with dc_shell. I thought I would share a little snippet I developed
> through much trial & error, and ask the world if there is a better way.
>
> The problem I'm trying to solve is that we would like some general purpose
> scripts for our project that will apply constraints to any block given to
> it. So we want a conditional application of output_delay on a reset pin,
> based on whether the reset pin exists or not. You could just:
>
> set_output_delay 5 -clock clk [get_ports {Reset}]
>
> but then Synopsys says:
>
> Warning: Can't find port 'Reset' in design 'test'. (UID-95)
> Error: Nothing matched for collection (SEL-005)
>
> if that port doesn't exist. But maybe that's okay except that errors are
> bad when grepping for real errors. Through much effort we came up with:
>
> proc exists { thingy } {
> redirect /dev/null {set a [eval $thingy]}
> if {$a == {}} {
> return 0;
> } else {
> return 1;
> }
> }
>
> if {[exists {get_ports Reset}]} {
> set_output_delay 5 -clock clk [get_ports {Reset}]
> }
>
> Synopsys does it if the pin exists, it reports nothing if it doesn't.
> Note the selection of brackets and braces, they are all important! This
> seems to work for get_ports and get_designs, I don't know what else.
> This seems really useful to me. Has anyone any better methods?
>
> - Paul Gerlach
> Tektronix, Inc. Beaverton, OR
From: Paul Zimmer <pzimmer@cisco.com>
Hi, John,
I was going to suggest that many (but not all) of the get_... commands have
a -quiet switch. This is how I handle problems like the one Paul mentioned.
pt_shell> q [get_ports *]
{"clkin", "clkout", "gen_out", "in"}
pt_shell> get_ports reset
Warning: No ports matched 'reset' (SEL-004)
Error: Nothing matched for ports (SEL-005)
pt_shell> get_ports -quiet reset
pt_shell>
But DC-tcl IS NOT LIKE Primetime Tcl!!!!!!!! I guess Synopsys needs to
work on the consistent use of their options. Gerlach told me he got
this when he tried my "-quiet" suggestion:
dc_shell-t> get_ports -quiet {Reset}
Warning: -quiet ignored on 'get_ports'
Warning: Can't find port 'Reset' in design 'test'. (UID-95)
I can't test in dc_shell because I'm not set up to run dc_tcl, but this
works in Primetime:
filter_collection [get_ports *] "full_name == reset"
filter_collection doesn't complain when the filter returns and empty
collection, and get_ports * won't get an empty collection, so this should
work.
- Paul Zimmer
Cisco Systems
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <scott@sonicsinc.com>
John, an alternative would be:
if { [get_ports -quiet "Reset"] != "" } {
set_output_delay 5 -clock clk [get_ports "Reset"]
}
except that the -quiet options of get_ports isn't supported in dc_shell
(look at man get_ports). So, another, less appealing workaround is to
ignore the error in this section of your script.
set suppress_errors [concat $suppress_errors "SEL-005"]
set_output_delay 5 -clock clk [get_ports "Reset"]
Hope this helps.
- Scott Evans
Sonics, Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: Henry Berkley <asic@netcom.com>
Hi John,
I would suggest:
if [llength [get_ports Reset]] {
set_output_delay 5 -clock clk [get_ports Reset]
}
If the port exists the get_ports command returns a collection handle which
has llength of 1. If the port does not exist the get_ports command returns
an empty string which has an llength of zero.
This avoids the SEL-005 error and gets only a UID-95 warning that can be
suppressed with the suppress_message command.
- Henry George Berkley
Electronic Consulting Santa Cruz, CA
---- ---- ---- ---- ---- ---- ----
From: Peter Kamphuis <peter.kamphuis@infineon.com>
Dear John,
No answer for Paul Gerlach, but something other nasty about Tcl we've
ran into. Maybe somebody knows Tcl better and/or has a better solution
to the following. When calling external programs from dc_shell-t using
the Tcl 'exec' or Synopsys 'sh' command, you'll get an error message as
soon as the external program writes to stderr. A nice example is seen
within Synopsys' ACS where 'gmake' gets invoked:
Executing gmake -f pass0/Makefile -j > pass0/logs/gmake.log.....
Error: gmake[1]: Entering directory `abc'
Compiling design : def
...
gmake[1]: Leaving directory `abc'
Use error_info for more info. (CMD-013)
The "Error:" string gets prepended and the "CMD-013" message gets
appended to the 'gmake' output, because it writes to stderr! No errors
occurred during this run. You'll get similar behavior with any other
external tool you invoke. In some Tcl book I found the following on the
'exec', and thus also 'sh' command:
"The standard output of the program is returned as the value of the
exec command. However, if the program writes to its standard error
channel or exits with a non-zero status code, then exec raises an
error."
What you can do is using the following:
exec external_program 2>@ stdout
or, if you want to "see" the output of the external program:
puts [exec external_program 2>@ stdout]
Now the invoked program only has one output channel and the invoking
script will only be interrupted when real errors appear (non-zero exit
status). Unfortunately, if you must rely on a separate STDOUT and
STDERR of the external program (filter functionality), I don't see a
good solution. If you don't need the output, you could redirect STDERR
to /dev/null.
- Peter Kamphuis
Infineon Technologies AG Munich, Germany
============================================================================
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
|
|
