Editor's Note: Hypothetical question time. Let's say you have a friend
who was asked by the people running the upcoming HDLcon'02 to put
together a *really* interesting EDA panel discussion for the conference.
Who would *you* tell him to invite and what should he make the focus of
the debate? (This being purely a hypothetical question and all... :)
- John Cooley
the ESNUG guy
( ESNUG 386 Subjects ) ------------------------------------------- [01/16/02]
Item 1: Buffer/Inverter PhysOpt 2001.08 & 2001.08-SP1 Bug Creates Bad Logic
Item 2: ( ESNUG 385 #2 ) Aart Claims Openness; Verisity Says It's Not True
Item 3: ( ESNUG 385 #4 ) You Can't Mix Avanti's Star-RC & Mentor's Calibre
Item 4: ( ESNUG 377 #9 ) Sun's Gridware Runs On HP, IBM, SGI, Compaq, Too!
Item 5: Is Himanshu's Recent "Advanced Chip Synthesis" Book Worth Reading?
Item 6: ( ESNUG 383 #15 ) Two Customer Evals Favor Formality Over Verplex
Item 7: Are You Finding The Recent Version Of Formality Core Dumping A Lot?
Item 8: How Useful Are Cell Power Estimation EDA Tools Vs. Actual Silicon?
Item 9: ( ESNUG 385 #13 ) Mixed Voltage Libs Mess Up DC/Apollo/PrimeTime
Item 10: User Hopes That Synopsys Doesn't Kill C-Level's EDA C Technologies
Item 11: ASC's Vhdl2v Doesn't Convert VHDL Functions/Procedures To Verilog
Item 12: Exactly How Does An Engineer Document Synopsys Multi-Cycle Paths?
Item 13: Where Can One Find Synopsys DesignTime & PrimeTime User's Manuals?
Item 14: ( ESNUG 383 #14 ) PhysOpt 'Fixed Placement' Routing Obstructions
Item 15: ( ESNUG 385 #6 ) Waaaay Too Many Hierarchy Tracing Tools/Techniques
Item 16: BSD Compiler Has Had Problems, But It Seems To Be Getting Better
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 386 Item 1 ) --------------------------------------------- [01/16/02]
From: "Mike Montana" <montana@synopsys.com>
Subject: Buffer/Inverter PhysOpt 2001.08 & 2001.08-SP1 Bug Creates Bad Logic
Hello John,
One of the ACs in San Diego told me about a situation where PhysOpt can put
"extra inversions" in your netlist and create bad logic. This problem can
occur if your library has certain cell that can act as *both* a buffer and
an inverter. Below is an example of this type of cell followed by an
example of a simple buffer cell.
_________________
| CELL A |
| +---------| out_bar (pin 1)
| |\ | |\ |
in |--| >o-+---| >o--| out (pin 2)
| |/ |/ |
|_________________|
_________________
| CELL B |
| |\ |\ |
in |--| >o-----| >o--| out (pin 1)
| |/ |/ |
|_________________|
PhysOpt can swap between single output cells and the multi-output cells to
attempt buffering and/or sizing. If the two sets of cells have the pins
declared in a different order, then PhysOpt can get confused as to the
proper output pin connections. Consider the example above. CELL A pin 1 is
the inverted output while CELL B pin 1 is the non-inverted output. During
buffering and/or sizing, the swap between the two cells is done such that
net connected to pin 1 of CELL A is reconnected to pin 1 of CELL B. This
is incorrect and results in extra inversions and bad logic.
Please note the following regarding this bug:
1) It only exists in versions 2001.08 and 2001.08-SP1
2) It only occurs in Physical Compiler, not Design Compiler
3) It only occurs for those libs that have the cell pins declared in a
*different* order, (i.e. pin 1 is the non-inverting output on simple
buffers/inverters but is the inverting output on the multi-output
buffers/inverters. This problem will NOT occur if the pins are
defined in the same order on these cells.
There are two temporary workarounds to this problem.
1) use version 2000.11-SP1
2) use version 2001.08 and place a dont_use attribute on all of the
multi-output library cells which can act as both a buffer and an
inverter before running physopt. It is OK if the pre-physopt
netlist contains some of these cells.
For example:
set_dont_use vendor_lib/inv_buf*
physopt
This bug will be fixed in a patch release scheduled for EST availability the
first part of February 2002. This bug was documented in Solv-It article
Physical_Synthesis-325 but I also wanted to alert your readers to it, too.
- Mike Montana
Synopsys, Inc. Dallas, TX
( ESNUG 386 Item 2 ) --------------------------------------------- [01/16/02]
Subject: ( ESNUG 385 #2 ) Aart Claims Openness; Verisity Says It's Not True
> We have found that customers want...
>
> b.) Interoperability: There were a number of references to interoperability
> issues in ESNUG 384 #6. Many of you use a Synopsys-Cadence flow and
> have also produced impressive results. Whatever your choice of tools,
> we will actively continue to support flows with competitors via
> standard interfaces. We have always believed that providing strong
> open interfaces is a must. (Note that we have been open with several
> interfaces, including .lib, SystemC, SDC, and OpenVera.)
>
> c.) Competition: No one wants any supplier to become too powerful. As of
> today, there is one strong complete supplier of front-to-back
> solutions and two smaller suppliers. When Synopsys and Avanti merge,
> there will be two strong suppliers. Competition from both large and
> small companies brings out the best in everyone: best design flows,
> best support, best solutions, best pricing, and best ROI for customers.
> (ESNUG 384 #8)
>
> - Aart de Geus
> Chairman & CEO of Synopsys
From: Francine Ferguson <francine@verisity.com>
Hi John,
I found Aart's post to be very interesting. If promoting competition and
interoperability are truly important for Synopsys (and customers) as Aart
claims, then I am truly baffled by a recent turn of events.
Verisity has been a member of Synopsys' in-Sync program for several years
and Synopsys is a member of our interoperability program, VIP. This year,
for the first time, we were informed that we (Verisity) would not be
allowed to participate (as we always have) in the vendor fair that is
always held during SNUG. This was a shock. It has always been open to all
in-Sync partners before. But apparently, not this year. This year there's
a "tiered" system and surprise, surprise Verisity did not make the first
tier. It is confusing to me since verification is a big issue for Synopsys
customers. We are not a small player - our Specman tool has quite a large
user overlap with Synopsys' VCS simulator and our booth has always been
quite busy at SNUG (perhaps indicating customer interest...) So I'm
curious as to 2 things: which other vendors were excluded and also what was
the criteria? Was it perhaps that we are competitors? Is favoritism being
given to those companies that are helping to push Synopsys standards? Is
this what the customers want? Is this truly in Aart's stated spirit of
interoperability and competition? Or is it in fact Synopsys trying to
choose for the customer rather than listening to the customers?
Perhaps interoperability and competition are only important when it is
Synopsys that is trying to compete against Cadence.
- Francine Ferguson
Verisity Design, Inc. Mt. View, CA
( ESNUG 386 Item 3 ) --------------------------------------------- [01/16/02]
Subject: ( ESNUG 385 #4 ) You Can't Mix Avanti's Star-RC & Mentor's Calibre
> I need to generate a BACK-ANNOTATED RC extracted Spice netlist of a
> transistor-level design from a GDSII and a Spice netlist using Mentor's
> Calibre (for LVS) and Avanti's Star-RC. I would like to know if somebody
> has a methodology or script that accomplished this with these two
> different tools.
>
> - S. H. Park
> Api Networks
From: "John Lee" <john_lee@avanticorp.com>
Hi, John,
There is no known flow for this. Avanti and Mentor have been discussing the
possibility of this flow. I'm curious if other readers would be interested
in it; we are very willing to do this if customers request it. Star-RC (and
Star-RCXT) right now only reads LVS data from Hercules. To the best of my
knowledge, this, along with Calibre->xCalibre, are the 2 "real" commercial
solutions that do:
1.) Hierarchical LVS
2.) Have grey-box extraction capability from the LVS data-base
(hence are useful for full-chip).
I previously discussed in ESNUG 382 #6 some integration issues of fast-SPICE
simulators with RC extraction tools. Specifically, here are issues that I
think are most important:
a. Cost of extracting full-chips or full-blocks. This cost is usually
higher than need be, and here's why. During fast-SPICE simulation, it
is typical (for mixed-signal or digital blocks) that not all nets will
switch. That is, there is latency. In this case, not all nets need
to be extracted. This can save tremendously on runtime, disk usage,
and memory usage.
A good example of this is when designers want to verify the timing
performance of compiled SRAM's. The post-layout parasitics are *very*
important, and to acquire timing (setup/hold) of this from a fast-SPICE
tool (like any of the XXXX-Sim tools) involves simulating a very SMALL
portion of the nets in the SRAM.
How to do this safely, easily, automatically is an issue.
b. All new fast-SPICE simulators purport to be hierarchical. But how to
handle flat post-layout parasitics introduces problems with:
- capacity
- runtime
- back-annotation
Each tool on the market slows down w/ post-layout parasitics; how much
they slow down is dependent on the exact architecture.
c. How to easily call RC+fast-SPICE from a cell-based design flow (e.g.
for clock net verification, or critical timing path). It's a tough job,
and most companies, especially COT's end up not doing it.
Each fast-SPICE tool has strategies to do RC reduction, but the accuracy of
each approach varies...
- John Lee
Avanti Fremont, CA
( ESNUG 386 Item 4 ) --------------------------------------------- [01/16/02]
Subject: ( ESNUG 377 #9 ) Sun's Gridware Runs On HP, IBM, SGI, Compaq, Too!
> I can understand where Platform's coming from. They're trying to protect
> a $46 million business. Getting word out about Sun's free Gridware tool
> doesn't help. But Gridware's weakness is that it runs only on Solaris and
> Linux machines. I can't wait to see what Platform tries once I mention
> that PBS by Veridian is also free. And PBS supports Suns, HPs, IBM,
> Linux, SGI, and even Cray supercomputers. http://www.OpenPBS.org
>
> - from "The Price Is Right"
From: Chuck Kuczaj <kuczaj@chameleonsystems.com>
Hi John,
FYI, the Sun Grid Engine, the open source project, is maintained for Solaris
SPARC and Linux x86, but executables for other platforms are available via
binary license as well. Binaries are available for Compaq Tru64 Unix, HP
HP-UX, IBM AIX, Linux Alpha, SGI IRIX, and Sun Solaris x86. The Grid Engine
5.3 supported platforms list may be found at:
http://gridengine.sunsource.net/project/gridengine/download.html
I'm reading the manuals now, and plan on deploying a 40-CPU-sized farm during
the next few weeks running on Sun Solaris SPARC.
- Chuck Kuczaj
Chameleon Systems
---- ---- ---- ---- ---- ---- ----
From: Wolfgang Gentzsch <Wolfgang.Gentzsch@sun.com>
Hi, John,
The Sun Grid Engine is not only free on Solaris and Linux, but it is also
available in open source at http://gridengine.sunsource.net through the Sun
Industry Standards Source License. This is less rigid than the General
Public License [GPL] and allows users to create and write their own
proprietary distributions without having to give that code back to the
development community. Thus, you can port it to every platform. From this
same website, you can also download courtesy binaries for Compaq, HP, IBM,
and SGI platforms, for free. Professional support for the non-Solaris
platforms is available through Sun's partner network.
- Wolfgang Gentzsch
Sun Microsystems, Inc. Palo Alto, CA
( ESNUG 386 Item 5 ) --------------------------------------------- [01/16/02]
From: Jay Pragasam <jlk@brecis.com>
Subject: Is Himanshu's Recent "Advanced Chip Synthesis" Book Worth Reading?
Hello, John,
Someone suggested to me a book named "Advanced Chip Synthesis" by Himanshu
Bhatnagar from Connexant. It's summary says that the book explains about
the advanced chip synthesis techniques using the Synopsys tools from DC to
PhysOpt to Primetime to Formality. Has anyone read this book? Is it any
for knowing about different synthesis methodologies? We have Synopsys
manuals and documents; is this book any different from what we can learn
from them? I would appreciate comments on ESNUG on this.
- Jay Pragasam
Brecis Communications
( ESNUG 386 Item 6 ) --------------------------------------------- [01/16/02]
Subject: ( ESNUG 383 #15 ) Two Customer Evals Favor Formality Over Verplex
> We're interested in feedback on Design VERIFYer's competitive performance,
> but were surprised to see that the comparisons were done on a version
> that's more than a year old and 3 revs distant -- and with numbers that
> are way off that rev's usual performance. Maybe this customer would agree
> to a benchmark using the current rev?
>
> - Gerard Memmi
> Avanti/Chrysalis Fremont, CA
From: [ "Yay! No Layoffs Today!" ]
Please keep my name and company anonymous.
We have been using equivalency checking for almost 5 years. Our initial use
of EC was with Chrysalis, but made the transition to Formality about 3 years
ago. It is true, about two years ago, Formality R&D did take their eye of
the ball, and the tool had lost its competitive edge. The Formality R&D team
has responded to the Verplex "wake-up" call, and has made major improvements
to the tool, both in the usability of the tool, and in the complexity of the
designs it can compare. (It was the responsiveness of the local Synopsys
Formality consultant and R&D which kept us from considering a switch to
Verplex when Formality wasn't as competitive.)
Formality continues to be our primary equivalency checking tool, and we are
able to compare well over 95% of our designs. The 5% of our designs which
don't compare have been those which required a 64 bit version of the tool.
For those designs, we do use Verplex Tuxedo, which has been able to compare
most of those designs. We do also however encounter some designs which
won't compare in Verplex, but will compare in Formality.
Our experience overall has been that Formality does a better job comparing
netlist vs netlist, especially when there are hierarchical changes between
the two representations. Verplex, on the other hand, does a better job
comparing RTL vs gate. Since we do more gate vs gate compares, we are
sticking with Formality, while keeping our eye on Verplex.
- [ "Yay! No Layoffs Today!" ]
---- ---- ---- ---- ---- ---- ----
From: [ From The Land Of Pokemon ]
Please keep me anonymous on this one. I'm the engineer here responsible for
performing formal verification on the P&R netlists that we create. I have
access to both Formality and Verplex and decided to eval both tools before
we bought one.
I was successful in running both tools and they both gave me the correct
results. However, Formality was easier to use. It had better debugging
capabilities, and I liked the fact that it has a TCL interface. The
performance results also clearly favored Formality. In verifying a 700K
design, approximately 40% RAM (using Magma P&R), Formality was 25% faster
and 4X better in capacity over Verplex on the same design.
Our team did decided to buy Formality because of our eval results.
- [ From The Land Of Pokemon ]
( ESNUG 386 Item 7 ) --------------------------------------------- [01/16/02]
From: John Cooley <jcooley@TheWorld.com>
Subject: Are You Finding The Recent Version Of Formality Core Dumping A Lot?
Last month, I had two unrelated consulting customers independently ask me if
I was seeing the recent version of Formality core dumping a lot. (I was
consulting with them on non-EC issues, so I didn't have the time to pursue
this further.) Now that I have some free time, I'd like to ask the ESNUG
readers if they're seeing a lot of Formality crashes lately, or was that
just a fluke that I was being asked that?
- John Cooley
the ESNUG guy
( ESNUG 386 Item 8 ) --------------------------------------------- [01/16/02]
From: "Ken Wagner" <ken_wagner@pmc-sierra.com>
Subject: How Useful Are Cell Power Estimation EDA Tools Vs. Actual Silicon?
John,
Thanks for ESNUG. Most helpful is the opinionated user commentary.
I have been reviewing reader comments on your http://DeepChip.com looking
for information on the correlation between calculations of total power by
cell level power analysis tools and actual silicon. Not a word to be
found... hmmm... So then how good are these 4 significant digit power
model library characterizations that many are using? Are they useful only
for relative power comparison or can they be used more reliably?
Even the marketing folks are not reporting much -- other than correlating
to transistor level tools.
- Ken Wagner
PMC-Sierra, Inc.
( ESNUG 386 Item 9 ) --------------------------------------------- [01/16/02]
Subject: ( ESNUG 385 #13 ) Mixed Voltage Libs Mess Up DC/Apollo/PrimeTime
> I just received word from a Synopsys AC that if I have a PAD and a CORE
> library that have two different operating voltages, then I end up with
> significant problems in Apollo, Design Compiler and PrimeTime. ...
>
> Design Compiler (presently, I know the new library format is coming) can
> only handle ONE operating condition. Not one per library. Can someone
> shed some light on this problem?
>
> - Wayne Miller
> Standard Microsystems Corporation
From: "Keith Buckingham" <keith@nvidia.com>
Hi, John,
It has been my experience that we have to specify the intended *core*
operating conditions in our pad libraries, although we recognize that this
is not strictly speaking the conditions that the pad transistors are seeing.
eg.
/* These are the conditions that the library was extracted at
* but the library will be used at the second set of conditions below
* and we do not want the library to scale, so we declare those
* conditions as being the ones for the library
nom_process : 1;
nom_temperature : 125;
nom_voltage : 0.95;
*/
nom_process : 1;
nom_temperature : 125;
nom_voltage : 1.08;
This is more of a maintenance overhead if you want to perform cross corner
timing analysis (min-voltage core + max-voltage IO), but if you only do
min-min and max-max, then it just becomes an understood difference to the
nominal operating conditions declaration.
- Keith Buckingham
NVIDIA
---- ---- ---- ---- ---- ---- ----
From: "Robert Wiegand" <RWiegand@NxtWaveComm.com>
Hi John,
Wayne might want to try the following SolvIt article: Synthesis-654.html.
It describes two solutions, one modifying the k_volt parameters in the pad
library, and the other modifying the nominal voltage in the pad library.
Another article, Synthesis-838.html, suggests changing the k_volt parameters
to zero to prevent any scaling. Both, of course, require access to the .lib
files as well as a Library Compiler license if you need to create new .db
files. So far, the few people I have talked to about this have just decided
to live with the slower pad timings that result from not doing these
modifications. I haven't tried these workarounds myself yet, so I can't
confirm if they work (I was able to live with slower pad timing).
While we're talking about scaling, what about temperature? Let's say I have
a cell library with best case defined at -40 C, but the pad library has it's
best case characterized at 0 C. If I use the core operating conditions,
will the pad library k factors scale the pads and speed them up? Is there
some other way to match the pad temperature to the core temperature?
- Bob Wiegand
NxtWave Communications Langhorne, PA
( ESNUG 386 Item 10 ) -------------------------------------------- [01/16/02]
From: "Dan Joyce" <dan.joyce@compaq.com>
Subject: User Hopes That Synopsys Doesn't Kill C-Level's EDA C Technologies
Hi, John,
It was announced Nov. 12th that C-Level Design was acquired by Synopsys.
C-Level Design had an incredible tool which allowed you to write your HDL in
ANSI-C or C++. Their programming style guide showed you how to transform
sequential C into something that could emulate the parallel operation of
hardware. The key was that you could write the C-HDL at a low level
(identical to Verilog or VHDL), but C simulation speeds were 3 orders of
magnitude faster on large simulations. This C-HDL design could then be
automatically translated to synthesizable Verilog - which synthesized to
remarkably fast logic using Synopsys Design Compiler.
In ESNUG, I keep reading "Now that the Verilog/VHDL wars are over, you
idiots are trying to start a C++/Verilog war!".
I don't view it that way. C++ is not an alternative to Verilog. It is an
*addition* to Verilog - yes with all the baggage of learning two languages.
But for people who need to simulate such large designs and run great
numbers of cycles (random testing approaches), C was worth it. With the
C-Level solution, Verilog was still an integral part of the process. A
portion of the simulation was always required at the Verilog level. When
will anyone ever sign off on an ASIC without a Verilog gate level simulation
for at least a subset of the regression suite? - Not in this decade.
The supposed downsides to this were:
1) C simulations are only cycle accurate. This isn't a big a deal because:
- Most Verilog simulations today using event driven simulators have
all clocks running at some multiple of a single clock anyway.
Asynchronous logic is verified using other means (usually code
inspection).
- Don't forget you are translating to Verilog. You can do all the
event driven simulation you want with the Verilog translation of
the logic. C or C++ just gives the opportunity to run the majority
of the logic verification at much higher speeds when all you need
is cycle accuracy.
2) Lack of C tools. Good waveform debugging, code coverage, linting,
assertion, and test-language tools are still missing from the C/C++
space.
- These were being created and would not have taken long to complete.
- Actually C++ is a much better test language than Verilog to start
with. Vera was created to give C++ capabilities to Verilog users.
3) Verilog code as legacy or cores. Simulation speeds of 3 orders of
magnitude faster could not be achieved if ANY Verilog or VHDL was running
in the simulation. The slower code, could easily be tied into the
simulation with PLI, but no matter how small the code was, it would grind
the simulation speed back to nearly Verilog speeds. Workarounds:
- C-Level was working on Verilog uplifting to create a faster cycle
accurate C model of most Verilog code.
- Include only C++ for the C++ simulation environment. Different
simulation environments to verify the parts that cannot be in C++.
According to the aquisition Press Release, Synopsys plans to integrate this
technology into their VCS tool. It will be interesting to see how they
manage to do this. Here are their options:
1) Market C-Level's tool mostly as-is. This would include the programming
style guide, uplifter from legacy Verilog to cycle accurate C++, and C++
to synthesizable Verilog translator.
- They have already said they will not do this, instead leveraging the
technology into their existing tools.
2) Create a new cycle accurate Verilog simulator. This would come no where
close to the simulation speeds of C-Level's ANSI-C solution but could be
faster than present VCS.
- They are already doing this and nothing from C-Level will help in
this effort.
3) Create a second simulation kernel for SystemC which runs cycle accurate
and much faster than the present one.
- This would still have to have a kernel and would not achieve the
simulation speeds that C-Level was able to achieve, but could be
much faster than the present event driven SystemC or even a cycle
accurate VCS.
- C-Level allowed users to program in Open source ANSI-C++. This gave
quite a high level of flexibility. Synopsys will probably not
change SystemC to run as Open Source C++.
4) Swallow C-Level just to keep it from competing w/ their existing tools.
If Synopsys takes this C technology and creates the next generation HDL that
is capable of simulating at these remarkable speeds, I will be very happy.
Despite the pain of this new technology and the lack of tools and expertise,
the advantages were more than worthwhile for certain projects. As chip
sizes increase faster than Verilog simulators speed up, the need for this
type of C-HDL solution will only become more pressing.
If Synopsys does not use this C technology, or takes an approach that loses
most of the speed advantage, someone else eventually will. There are enough
customers who need to simulate very large designs and will be willing
finance this type of tool. It has already been done and technically proven.
- Dan Joyce
Compaq Austin, TX
( ESNUG 386 Item 11 ) -------------------------------------------- [01/16/02]
From: "Rakesh Mehta" <rmehta2@nortelnetworks.com>
Subject: ASC's Vhdl2v Doesn't Convert VHDL Functions/Procedures To Verilog
Hello John,
I'm scrambling my head over this...
I am using VHDL-2-Verilog translator by ASC. I could not translate my
functions from VHDL to Verilog -- they are simply skipped!
My VHDL source code has a package which has some function declarations
(eg. calculate_lrc(data)) and definitions in it. The problem is when I try
to convert the package or code from VHDL to Verilog, the functions are
skipped. So the verilog file just has constants and no "function", as if
there was no function declaration in the original file.
I tried using -Function_Map option but it would only allow me to keep the
original function call but the parameters are skipped. Also no function
conversions.
So does ASC's vhdl2v not support function and procedure conversions from
VHDL to Verilog?
- Rakesh Mehta
Nortel Networks
( ESNUG 386 Item 12 ) -------------------------------------------- [01/16/02]
From: Prasad Omprakash <a0756692@india.ti.com>
Subject: Exactly How Does An Engineer Document Synopsys Multi-Cycle Paths?
Hi John,
I am trying to find ways of documenting the multicycle paths in a Synopsys
flow used in a given design. Basically I want to document all of the
multicycle paths in a design. Have you done any documentation of such? If
yes, can you send me a format of the documentation .
- Prasad Omprakash
Texas Instruments India
( ESNUG 386 Item 13 ) -------------------------------------------- [01/16/02]
From: "Zhou Shaoxiang" <zhousx@cet.st.com.sg>
Subject: Where Can One Find Synopsys DesignTime & PrimeTime User's Manuals?
Hi, John,
How can I get the documention (User's Manual) of DesignTime or Primetime?
- Zhou Shaoxiang
STMicroelectronics Singapore
( ESNUG 386 Item 14 ) -------------------------------------------- [01/16/02]
Subject: ( ESNUG 383 #14 ) PhysOpt 'Fixed Placement' Routing Obstructions
> Every now & then, I see a number of user questions regarding obstructions
> in PhysOpt. With PhysOpt, we classify obstruction objects as:
>
> (a) Power nets
> (b) Fixed placement
> (c) General
> (d) External
>
> In this letter I'd like to focus on "Power Net Objects".
From: "Cyrus Malek" <cyrusm@synopsys.com>
Hi John,
This is a follow-up to my earlier note (ESNUG 383 #14) on 'Power Net
Obstructions' in PhysOpt. This note covers 'Fixed Placement Objects'.
Again: *Please* read ESNUG 383 #14 before reading this!!!
Fixed Placement Instances
-------------------------
Your design may contain instances that are fixed in place, either with the
'set_dont_touch_placement' command or the "RESTRICTION FIXED_PLACEMENT"
attribute in your PDEF. These instances are always treated as placement
obstructions, and the layer obstructions and pin geometries that are part
of the physical cell description are used during congestion estimation and
delay calculation. Any placement site that is occupied (even partially)
by the fixed cell is removed from the list of available locations for cell
placement.
Note: Currently physical-only cells (filler cells, end caps, wellcaps, etc.)
MUST be fixed in place. As usual, these cells are treated as placement
obstructions.
To determine what your cell obstructions look like in the psyn_gui (when the
Physical View is opened) a cell's internal obstructions can be made visible
by checking the check box next to 'Obstruction'. Likewise, the cell's port
shapes can be made visible by checking the check box for 'Port Shape'. In
the standard display mode for cells, all cells that are fixed in place will
show up in a different color. The color setting can be modified in the Cell
Preferences menu.
Any cell that is fixed in place may have an additional constraint
attached to it called a 'keepout_margin'.
Fixed Placement Keepout Margins
-------------------------------
Typically, keepout margins are specified around hard macros such as RAMs and
ROMs to avoid routing congestion around the corners of these objects. The
keepout margin defines an extended 'no-placement-zone' around the specified
cell. PhysOpt goes one step farther and allows the user to define keepout
margins around any cell that has been fixed in place.
Prior to version 2001.08, a variable was used to define global keepout
margins. As of version 2001.08, commands relating to keepout margins have
been added to enhance the usability of keepout regions. Now users can
specify margins on a per-instance basis, as well as define keepouts on a
per-edge basis (each edge can have a different keepout margin).
set_keepout_margin -type hard | soft \
-outer {lx by rx ty} object_list
report_keepout_margin [-type hard | soft ] object_list
remove_keepout_margin [-type hard | soft ] object_list
Keepout areas can be of two types:
Hard: An area you can automatically create, within which the
rough placer AND the legalization engine avoid placing cells.
Soft: An area you can automatically create, within which the
rough placer avoids placing cells. During the legalizing
process, cells can slide into the area, but the distance they
travel is minimal.
Part of the hidden beauty of these commands is that the user can
experiment with 'soft modifications' to their floorplan without having
to re-floorplan their design.
- Cyrus Malek
Synopsys, Inc. Austin, Texas
( ESNUG 386 Item 15 ) -------------------------------------------- [01/16/02]
Subject: ( ESNUG 385 #6 ) Waaaay Too Many Hierarchy Tracing Tools/Techniques
> I am looking for a tool or script which will trace a specified reg or wire
> through the RTL hierarchy with possibly many name changes. When studying
> an RTL design which was writtem by somebody else, it helps to make drawings
> of one functional section of the design at a time. I find it very tedious
> to track nets through the entire RTL design. This process is especially
> difficult when there is a deep hierarchy with many name changes. Do you
> know of a tool which could solve this problem?
>
> - Chet Juall
> Dialogic
From: "Richard Hein" <richard_hein@agilent.com>
Hi John,
I've used a package called Renoir (now called HDL Designer I believe) from
Mentor Graphics. It has the ability to work out the hierarchy and draw the
block diagrams from the source files. Not sure if it now can display signals
through the hierarchy though. The primary use of the tool however is for
graphical HDL entry. I'm from the pre-HDL days when we entered designs using
schematic capture. When I moved to HDL I still had to draw block diagrams to
visualize the design. I've found the tool useful to visualize, design,
enter, manage and document a design so the next person won't have to trace
signals through the design and draw diagrams to figure out how it works in
the first place. I've only used it for FPGA design so I can't comment on how
suited it is to chip designs.
- Richard Hein
Agilent Technologies Ottawa, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: Jeffrey Ebert <ebert@sonicsinc.com>
John,
I highly recommend Novas Debussy to Chet. We have been using it for about 1
year now, I believe. Debussy supports tracing connectivity in the source
code window. It also will create a "pruned" schematic that only shows the
signals that you have selected. We use this feature RTL and gate-level.
- Jeff Ebert
Sonics, Inc.
---- ---- ---- ---- ---- ---- ----
From: Howard Landman <howard.landman@vitesse.com>
Hi, John,
Avanti Formal (formerly Chrysalis, soon to be Synopsys) Design Verifier does
this automatically during the build process. You don't by default get a
report of every net, but when there's a difference found during verification
you'll see something like:
Different #1 - The two groups are different
+1 111134 A.pom1.bc_wdat[47]
-> NSB +1 64969 A.pom1.bc.$104641[7]
+1 111134 A.pom1.bc.bc_wdat[47]
+1 111134 A.pom1.fram.din[47]
PO +1 6928 A.pom1.fram.ram.DA[47]
+1 114461 B.pom1.'bc_wdat'[47]
-> NSB +1 78540 B.pom1.bc.bc_wdat[47]
+1 114496 B.pom1.fram.din[47]
+1 78540 B.pom1.bc.U5645.Z
+1 78540 B.pom1.bc.U6526.D1
PO +1 9154 B.pom1.fram.ram.DA[47]
In this case (an RTL-to-gates comparison) A is the RTL and B is the gates.
The cluster of names for A is all the different hierarchical names for that
logic signal in the RTL. Even inversions are included (with polarity -1
instead of +1) as variants of the same logic node.
In the gate level, notice that the library cell pin names on synthesized
gates are also included.
In both, the pins of excised submodules (in this case a data input "DA[47]"
to a RAM named "ram") will show up, but obviously the tool can't trace
through a module that it's been asked to cut out and throw away.
I think the necessary information to extract these clusters might exist in
the .hmap file produced by chrys_build, so it could just be a short Perl
script to get them from that. But I don't actually have such a script to
offer you. It is a text file:
% grep 111134 rtl_113001AB.hmap
S 111134 1 bc_wdat[47]
A 111134 1 0 bc_wdat[47]
A 111134 1 1 din[47]
but I'm not sure how to tell which node numbers are equivalent, and you'd
have to parse it all to get the hierarchy info surrounding those lines.
- Howard Landman
Vitesse Semiconductor Longmont, CO
---- ---- ---- ---- ---- ---- ----
From: "Ray Salemi" <ray_salemi@mentorg.com>
Hi, John,
The Mentor tool HDL Detective will do this. Chet would be able to import his
design and view it graphically including tracking signals through block
diagrams. He can download it at http://www.hdldesigner.com
- Ray Salemi
Mentor Graphics
---- ---- ---- ---- ---- ---- ----
From: Edward Arthur <eda@ultranet.com>
John,
This is what Debussy ( http://www.novassoft.com ) was invented to do. I'm
not affiliated with them, just a happy user.
- Ed Arthur
---- ---- ---- ---- ---- ---- ----
From: "Adam Levinthal" <adam@gdsdomain.com>
Hi, John,
Novas Debussy is exactly what Chet is looking for. For textually oriented
users, it creates lists of module port connections for signals, and allow
the user to jump around the code looking at signal references. For visually
oriented users, it will create a schematic from the RTL and allow the user
to re-construct a logic fan-in or fan-out cone by clicking on ports in the
derived schematics.
I don't want this to sound like a sales pitch, but I would give up a lot of
other tools before giving up Debussy...
- Adam Levinthal
GeoLogic Design
---- ---- ---- ---- ---- ---- ----
From: Richard Knight <rich@knighteda.com>
Hi John,
I have a tool called SUE that lets you travel up and down the hierarchy of a
design. Each time you step down/up, the port you came from is highlighted,
so it is very easy to know where you are in a design, and where you're
going. If you go to http://www.knighteda.com you will find a link to Micro
Magic tools. There's a description of SUE there.
- Richard Knight
Knight EDA Distribution
---- ---- ---- ---- ---- ---- ----
From: Jeff Riley <jeff.riley@mindspeed.com>
Just thought I'd drop you a line and let you know that there is a GREAT tool
that does everything you ask and ALOT more. It's called Debussy and it's
from a company called Novas. http://www.novas.com Ever since I first used
this tool 2 years ago I have been completely addicted to it. Check it out.
- Jeff Riley
Mindspeed Technologies Boulder, CO
---- ---- ---- ---- ---- ---- ----
From: Prab Varma <prab@veritable.com>
My company, Veritable Inc., has a design checking tool, Verity-Check, that
can perform hierarchical net tracing. http://www.veritable.com
- Prab Varma
Veritable, Inc.
---- ---- ---- ---- ---- ---- ----
From: [ The Cat In The Hat ]
Keep me anon.
The Verilog to html converter, v2html, is a free Perl script that converts
Verilog designs into webpages. Once converted the webpages can be opened
directly in a browser. For more details, see:
http://www.burbleland.com/v2html/v2html.html
I haven't tried it yet, but a friend recommended it to me after some success
with it.
- [ The Cat In The Hat ]
---- ---- ---- ---- ---- ---- ----
From: Duncan Crowther <duncanc@euro-eda.com>
Hi John,
I saw Chet's posting in ESNUG and thought I'd give you a pointer to a tool
that may help. Take a look at Expressive-III from Expressive Systems.
http://www.expressivesystems.com It's not exactly what you describe but
it does provide visibility of hierarchical signals throughout a complex
design. You would of course have to create your design hierarchy within
the tool first, but it's pretty fast to use. Anyway, I hope this helps.
- Duncan Crowther
EuroEDA Limited
---- ---- ---- ---- ---- ---- ----
From: Gene Sullivan <gene.sullivan@analog.com>
My company has been using Debussy from Novas ( http://www.novas.com ) for a
couple of years now. The tool can trace through both RTL and gate netlists
(we use Verilog, by the way). For gates, the tool can draw schematics which
can be probed; nets can be expanded to show fan-in and/or fan-out cones.
For RTL, the tool draws reasonably good schematics and finite state machine
diagrams. The tool also has nice hooks into its waveform viewer. (This is
not a paid advertisement, I swear!)
I have heard that Undertow by Veritools offers similar capabilities, and it
may be cheaper. ( http://www.veritools-web.com/products.htm )
- Gene Sullivan
Analog Devices, Inc.
---- ---- ---- ---- ---- ---- ----
From: Lee Bradshaw <bradshaw@ti.com>
Hi John,
The v2html tool may help Chet with navigating unfamiliar code:
http://www.burbleland.com/v2html
It seems to be more useful for finding the source of a signal than for
tracing fanout (especially across name changes.)
Your waveform viewer may have a logic browsing option to easily trace nets
through the hierarchy regardless of name changes.
- Lee Bradshaw
Texas Instruments
( ESNUG 386 Item 16 ) -------------------------------------------- [01/16/02]
From: Shin Yuan Wu <sywu@atmel.com>
Subject: BSD Compiler Has Had Problems, But It Seems To Be Getting Better
Hi, John,
We chose BSD Compiler as our boundary scan solution because Atmel had been
using Test Compiler for internal & boundry scan insertion. BSD Compiler
seemed like an obvious choice. Then came the challenge of fitting BSD
Compiler into our test design flow. We faced numerous problems.
1.) BSD Compiler was not able to insert Boundry Scan with the design core
in the netlist, contrary to BSD Compiler User Guide's claims. We
overcome this by removing the core before inserting Boundry Scan.
2.) There was the problem of not being able to pass the simulations with
the vectors generated by BSD Compiler to verify synthesized 1149.1
components. We overcome this by breaking up vectors to verify
individual components, such as TAP, BSR, TDR and reset mechanism.
Somehow vectors generated this way did not have any problems in
simulations.
3.) BSD Compiler had problems with our Synopsys Atmel libraries as well.
It could not synthesize functional 1149.1 components when input
buffers supported both true and complementary outputs going into the
array. It could not implement the HIGHZ instruction with bidi buffers
formed by combining seperate input and output IO buffer pieces.
(Atmel adopted designing seperate input, output, pullup/pulldown/keeper
terminators for IO libraries with ATL35/0.35micron technology. When a
bidi was needed for a certain sepc an input and output section was put
together to form the bidi. Obviously this gives more flexibility and
ease of maintaining less IO pieces.) We developed a workaround for
this with the help of Synopsys.
4.) We still have an outstanding issue with our pullup/pulldown terminators
which we are trying to get resolved soon. (A workaround for this
problem is in place until we get a permanent solution from Synopsys.)
I guess you must be wondering why I am writing all this without just lashing
out at Synopsys for all the problems we had to go through. My point is not
everything we had to do; the kind of business we are in isn't turn-key.
Sometimes you have to be a little persistant to get what you want. We're
glad we were and now we have a working flow for our boundary scan needs, of
course thanks partly to Synopsys. (Because we kept pushing, all of our major
problems were resolved by version 2001.08.)
I wouldn't call it perfect as of yet, but BSD Compiler works and it is now
automated enough that a even co-op student can use it in our design flow.
- Shin Wu, ASIC Division
Atmel Corporation Columbia, MD
============================================================================
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
|
|
