From: David Simmons <simmod@taec.toshiba.com>
Subject: I'm thinking of automating my job...
John,
I think I've found the Universal EDA User Script (tm) that best
describes my tortured existance as an EDA customer:
for (career_life) {
while (project < done) {
attempt_work(project_step);
if (hit_brick_wall_flag) {
while (evaluate_response(support_droid) != solution){
while (!response){
send_email (support_droid, *brick_wall);
wait(day);
while (patience--);
threat++;
}
}
}
project_step++
drink(rum);
}
I'm waiting for some clueless project manager to now complain that
they want this script in synthesizable RTL...
- Dave Simmons
Toshiba
( ESNUG 370 Subjects ) ------------------------------------------ [05/17/01]
Item 1 : ( ESNUG 352 #1 ) Ultima (Celestry) "ClockWise" Is Very Unstable
Item 2 : Is Cadence Trying To Break The DEF 5.2 PhysOpt/SE Interface ?
Item 3 : User Asks "Why Can't DC Instance Names Have Device Types In Them?"
Item 4 : The Free EASICs Web CRC Tool & The Easy Way To Understand CRC's
Item 5 : ( SNUG 01 #23 ) NDA "Ketchum" Found Along With DW_16550 UART Bugs
Item 6 : ( ESNUG 368 #12 ) PhysOpt, Power Compiler, & Avanti/Cadence CTS
Item 7 : PrimeTime Scripts & "mkdepend" Missing From Lahti's Tcl TOPS ?
Item 8 : ( ESNUG 368 #1 ) Synopsys Also Does Strange DCL Support, Too!
Item 9 : Module Compiler, DC-Tcl, & Presto Don't Play Nice With Each Other
Item 10 : Does The Synplicity Tech Support Staff Treat You Like Shit, Too?
Item 11 : Get Cadence Silicon Ensemble Parasitics Into Synopsys Design Power
Item 12 : Do You Know Anyone Who Has Design A Synthesizable Link List FIFO?
Item 13 : ( SNUG 01 #18 ) Synopsys Owns Up To BSD Compiler's Many Problems
Item 14 : ( ESNUG 368 #9 ) Moody PrimeTime Runs Commands On Its Own Whim...
Item 15 : ( SNUG 01 #15 ) But What About Mentor's FormalPro Or Innologic?
Item 16 : Seeking Source Code For The Defunct Cascade/Duet Memory Compiler
Item 17 : John, You Should Check Out This New Model Checking Company "@HDL"
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 370 Item 1 ) -------------------------------------------- [05/17/01]
Subject: ( ESNUG 352 #1 ) Ultima (Celestry) "ClockWise" Is Very Unstable
> I recently taped out a design on which I inserted clock trees using the
> Ultima ClockWise tool and really liked it. In the past I have used
> intentional skew in special situations to help improve timing, but it
> was difficult time consuming hand work.
>
> I have always thought that having an automated way of using skew to
> improve timing would be great, but it seemed like a difficult problem.
> In the past I have seen a few academic papers on the subject, but until
> recently I have never heard of a commercial tool. Ultima has pulled off
> a very nice implementation of a "useful" skew tool.
>
> - Jon Stahl, Principal Engineer
> Avici Systems N. Billerica, MA
From: Himanshu Bhatnagar <himanshu.bhatnagar@conexant.com>
Hi, John,
Through ESNUG 352, I heard of Ultima Tech's Clockwise tool. I evaluated it
about 8-9 months ago. Clockwise is a piece of junk. It's a clever idea,
but the interfaces to other tools are extremely unstable. While passing
data back-and-forth from Ultima to Avant, I ran into several issues. The
Ultima support staff provided 2-3 patches within 2 weeks of our eval to fix
these problems. I just don't know how they can sell this tool. Maybe now
they've improved it.
- Himanshu Bhatnagar
Conexant
( ESNUG 370 Item 2 ) -------------------------------------------- [05/17/01]
From: [ Elf Boy ]
Subject: Is Cadence Trying To Break The DEF 5.2 PhysOpt/SE Interface ?
John, anon please.
I was at my customer's site last week to debug a DEF in/out problem between
PhysOpt and Cadence SE. It appears that in the latest version of SE, there
is no longer an option to output DEF 5.2; only DEF 4.9 and DEF 5.3 were
listed as supported. The problem, of course, is that DEF 5.3 contains
numerous syntax cases not in DEF 5.2 that cause Synopsys def2pdef to fail.
Some of these are: VPIN, SUBNET, CLOCKROOT, + USE CLOCK, + ORIGINAL.
It appears to be a deliberate attempt by Cadence to break the interface
between PhysOpt and SE. I can't say I blame them for trying.
- [ Elf Boy ]
( ESNUG 370 Item 3 ) -------------------------------------------- [05/17/01]
From: Iain Clark <irc@lsil.com>
Subject: User Asks "Why Can't DC Instance Names Have Device Types In Them?"
Hi John,
How much time do you spend looking at Verilog netlists? I have been doing
quite a lot lately and have gotten quite tired of translating Synopsys
generated device instance names into device types. The netlists I look at
all have pretty unique and informative instance names right down to the
register names but not for synthesized combinational logic.
When we generate reports, or say use Mentor tools, my device type
information (AND/OR/NOR) disappears!!! Something I had the CAD department
at LSI do back when we had schematic capture was to make a device's type
part of it's instance name. I found this sped up debug considerably.
Do you think Synopsys could be convinced to do something more meaningful
with device instance names other than U1, U2 and U3? Wouldn't U_nand2_0
and U_NR4B_33 be more meaningful?
Whaddayathink?
- Iain Clark
LSI Logic
( ESNUG 370 Item 4 ) -------------------------------------------- [05/17/01]
Subject: The Free EASICs Web CRC Tool & The Easy Way To Understand CRC's
> I found a CRC generation tool at http://www.easics.com/webtools/crctool .
> The tool generated a code for 32-bit CRC calculation. The polynomial used
> was (0 1 2 4 5 7 8 10 11 12 16 22 23 26 32). I've included some equations
> here.
>
> NewCRC[0] = D[31] ^ D[30] ^ D[29] ^ D[28] ^ D[26] ^ D[25] ^ D[24]
> ^ D[16] ^ D[12] ^ D[10] ^ D[9] ^ D[6] ^ D[0] ^ C[0] ^ C[6]
> ^ C[9] ^ C[10] ^ C[12] ^ C[16] ^ C[24] ^ C[25] ^ C[26]
> ^ C[28] ^ C[29] ^ C[30] ^ C[31]; ...
>
> Can anybody tell me how these equations are derived? How can we relate
> these equations with the polynomial?
>
> - T. Sung
From: Muzaffer Kal <muzaffer@dspia.com>
Think about the CRC shift register as a state machine. There is a data
input and the current state of CRC. At every clock the current state of the
CRC gets updated by obeying the rules of the feedback taps. If you do this
"data bus width" number of times, you get the a new state in the shift
register. Now you have a state of shift register which is "data bus width"
away from the start. This involves the initial state of the shift register
and the previous "data bus width" inputs. The code you get from crctool is
the result of a symbolic manipulation which executes this algorithm. This
can be accomplished with a scripting tool, i.e. Perl.
- Muzaffer Kal
FPGA DSP Consulting http://www.dspia.com
---- ---- ---- ---- ---- ---- ----
From: "Daniel Elftmann" <dane@actel.com>
You might find the following document helpful:
http://www.actel.com/docs/datasheets/CRCds.pdf
The intent of the Datasheet was to answer questions such as yours, so please
let me know if it does.
- Daniel Elftmann
Actel Corporation
---- ---- ---- ---- ---- ---- ----
From: Utku Ozcan <ozcan@netas.com.tr>
These equations are derived by multiplication of two matrices, which are
defined in Galois theory. This calculator has been implemented in either
scripting language or anyhthing like C. In any book on Error Correction &
Detection which covers Galois Fields GF (x, y) and CRC will help you.
- Utku Ozcan
Nortel Networks
---- ---- ---- ---- ---- ---- ----
From: Mark Curry <mcurry@ti.com>
Don't let all those other responses regarding "Galois" fields and ECCs throw
you off. Although these things are very useful, they're overboard for
understanding simple CRCs.
An EXCELLANT paper on understanding CRCs is located at:
http://www.ross.net/crc/crcpaper.html
CRCs from a hardware perspective are very easy to implement and understand.
It's only when you get to trying to implemenent them in software where
things get interesting. People have come up with some very interesting
optimized algorithms for calculating CRCs. But when you have control over
all the bits - it's very simple.
So, to start just read the above paper up to the point where he starts
talking about software algorithms...
- Mark Curry
Texas Instruments
( ESNUG 370 Item 5 ) -------------------------------------------- [05/17/01]
Subject: ( SNUG 01 #23 ) NDA "Ketchum" Found Along With DW_16550 UART Bugs
> The new gossip on Ketchum is that Moto (Austin) and possibliy ST Micro
> (Agrate, Italy) are doing the 1st round of alpha testing. I'm told that
> the way Ketchum works is Ketchum thinks for about 12 hours on your design
> and then spits out a Verilog stimulus file. That Verilog file runs for
> 2 minutes in your chip's test suite and, voila!, you have 100% functional
> coverage (or not.) The actual Ketchum runtimes range from minutes to
> infinity. It's *very* alpha. Ketchum uses a Synopsys proprietary
> assertion language that's made to work with VCS, Scirroco, Vera, and
> CoverMeter. (This assertion language may be opened by Synopsys later.)
> Synopsys tells the Ketchum customers that the DW team is using Ketchum
> for its internal DW development, but I don't know if that true or not.
>
> - from the SNUG'01 Trip Report
From: Vladimir Sindalovsky <sindalovsky@agere.com>
Hi, John,
Recently I encountered the Ketchum tool you mentioned in your SNUG'01 Trip
Report. We were using DW_16550 UART in our design, and during usual
simulation process, I uncovered few functional bugs. We were close to
the tape out, so the situation was very tense, but, luckily, Synopsys's
designers came up with a quick fix. It would be better not to have bugs
in Synopsys DW IP at all, but "nobody's perfect".
Some time later I received from Synopsys some additional bug reports for
such subtle bugs that I got really interested how they were found. (An
example being the report stated that if a character is received exactly
one clock period after the status register polling, the data ready flag
won't be generated. This kind of bug is often missed during verification
and fixed later by software workarounds.) The Synopsys guys mentioned to
me their internal formal verification tool (Ketchum?) allowed them to verify
the DW design. They said they'll be broadcasting all these DW_16550 bugs
to customers next week. I still don't know how much effort the creation
of a formal description takes. Maybe somebody else had an encounter with
Ketchum (alfa testing participants?)
- Vladimir Sindalovsky
Agere Systems
( ESNUG 370 Item 6 ) -------------------------------------------- [05/17/01]
Subject: ( ESNUG 368 #12 ) PhysOpt, Power Compiler, & Avanti/Cadence CTS
> I would be very interested to get feedback on how good the hooks are
> between Power Compiler and Physical Compiler in the following two
> instances (particularly for designs well over 100 Mhz):
>
> 1. With integrated clock gating cells being available
>
> 2. Without integrated clock gating cells being available. In this case,
> Synopsys claims localized grouping within PhysOpt will ensure the
> clock gating elements would stay together in layout. Has anyone had
> any experience with this in a *real* tapeout flow? Has the CTS tools
> you used with PhysOpt / Power Compiler handled skew management well?
>
> Additionally, how's the interaction if the clock gating cells have
> observability/controllability ports?
>
> - Neel Das
> Corrent Corporation
From: [ A Dallas PhysOpt AE ]
Hello John,
I'm a PhysOpt AC in Dallas. I can't answer Neel's question about Power
Compiler, but I do know all about using PhysOpt with Cadence and Avanti CTS
tools. Actually I've used CTS tools from Avanti and Cadence as well as
other customer's proprietary CTS tools. My specific flow steps may need to
be tuned for each customer's environment, but it's a good starting point.
Loading PhysOpt Data Into Clock Tree Synthesis:
-----------------------------------------------
This step is similiar to a Design Compiler flow as you still have a Verilog
netlist and timing constraints. Whatever flow you traditionally use to pass
or convert the Synopsys timing constraints and clock descriptions for your
CTS tool will still apply for PhysOpt. The major addition to the flow is
that the netlist is already placed. Your placement data can be passed to
your CTS tool through a DEF file or PDEF file.
Running Clock Tree Synthesis:
-----------------------------
How you run your CTS tool really does not change in a PhysOpt flow. You're
simply starting from a placed netlist out of Physical Compiler. The CTS,
route, and extraction flows will be the same. After these steps are
complete you will need to generate all of the normal backannotations data,
SDF, setload, etc. After this, most customers will look at their timing
results to see if any post-CTS optimization is needed. If it is, you can
do it in PhysOpt. (Before you start optimizing the netlist in PhysOpt,
spend a little time looking at your timing results. In some cases, you will
see that there are quite a few paths which need optimization and the need
for PhysOpt will be obvious. You may find, however, that the design only
has a handful of paths which are missing timing. If you look at these paths
and see that simply sizing up a cell will fix the problem, don't bother with
PhyOpt -- instead just do the resizing inside your Cadence/Avanti P&R tool.
It's stupid to go through PhysOpt if all you have to do is hand tweak a
few cells in your P&R environment.)
Running PhysOpt After Clock Tree Synthesis:
-------------------------------------------
Here are the steps needed for PhysOpt to optimize a post-CTS netlist.
1. Create an updated netlist for PhysOpt. The updated netlist needs to
contain the actual clock elements (buffers) added during the CTS
process. Without this data, PhysOpt could chose to upsize a cell or
add a buffer and not realize that a CTS buffer was being overlapped.
Some tools "collapse" the CTS tree before handing the netlist back to
PhysOpt. I have seen this most often with customers using an Avanti
flow. If this is the flow you are using, see the section entitled
"Optimizing Designs with Collapsed Clock Trees" (below).
2. Create an updated PDEF file for PhysOpt. The updated PDEF file
contains the locations of the original cells and the newly added
clock elements.
3. Use check_legality in PhysOpt to make sure the clock elements (buffers)
added during CTS have legalized locations. If the clock elements are
not in legalized locations, resolve this problem before proceeding.
4. Fix the placement of all sequential cells (flip-flops and latches) using
the set_dont_touch_placement command. THIS IS A VERY CRITICAL STEP!
Your clock tree was generated in the CTS tool based on the existing
locations of the sequential cells in the design. By fixing the
placement of your sequential cells, you ensure they are not moved by
Physical Compiler. If you let PhysOpt move the sequential cells around,
you could INVALIDATE your CTS results.
5. Fix the placement of the clock elements to make sure that the entire
clock tree (clock buffers and sequential cells) remains unchanged in
PhysOpt. Use the set_dont_touch_placement command and the
set_dont_touch_network commands to insure the clock buffers are
unchanged.
6. Reapply your timing and DRC constraints.
7. Change your clocks from ideal clocks to propagated clocks. Use the
set_propagated_clock command.
8. Back-annotate the Post-CTS SDF delays and the set_load data. (Sometimes
this can be a major pain in the ass with data formats between tools. At
the end of this e-mail I have included a few hints and scripts to help
eliminate some issues seen in the past.)
9. Once your design is annotated and the proper dont_touch_placement
assignmemts are in place, use "physopt -incremental -post_route" to
optimize your timing.
Once the design has been optimized, you will need to cart your design
database into your (Avanti/Cadence) backend tools for completion. Each
ASIC vendor will have their own backend ECO flow. Here's a sample script
for running PhysOpt after Cadence/Avanti CTS:
psyn_shell-t> source lib_setup.tcl
psyn_shell-t> read_verilog post_cts_design.v
psyn_shell-t> current_design TOP
psyn_shell-t> read_pdef post_cts_design.pdef
psyn_shell-t> check_legality
psyn_shell-t> set_dont_touch_placement [all_registers ]
psyn_shell-t> set_dont_touch_placement [all_fanout -clock_tree -only_cells]
psyn_shell-t> set_dont_touch_network [all_clocks ]
psyn_shell-t> source design_constraints.tcl
psyn_shell-t> set_propagated_clock [all_clocks ]
psyn_shell-t> read_sdf post_route_extracted_delay.sdf
psyn_shell-t> source post_route_extracted_load.tcl
psyn_shell-t> report_timing
psyn_shell-t> physopt -incremental -post_route
Optimizing Designs with Collapsed Clock Trees:
----------------------------------------------
Here is how the flow worked for one customer. In the original netlist, our
customer would instantiate a CTS macro cell (i.e. "CTS00B") which acted
as a place holder for his CTS tree. During CTS, this macro cell would be
"expanded" and individual gate levels buffers used to implement the clock
trees. After CTS, all of the actual gate level clock tree buffers would
be "collapsed" into the CTS macro cell. His actual clock tree delay was
represented by a unique SDF delay from the CTS00B cell to each of the clock
pins in the design. The gate level clock buffers did, however, exists in
the PDEF file. When PhysOpt read the PDEF file, it would see these clock
gates as "physical-only" cells. PhysOpt would respect the placement and
size of these cells during any placement optimizations and insure there
were no overlaps.
Two additional commands are needed in the flow to handle this type of
clock tree synthesis.
1) When the PDEF file is read in step 2, it is important to use the
"-allow_physical_cells" option with the read_pdef command.
2) When setting the various dont_touch_placement commands in step 5, be
sure to dont_touch_placement on the CTS macro cells
set_dont_touch_placement \
[ get_cells "*" -hier -filter "@ref_name == CTS00B" ]
Getting Avanti/Cadence P&R Backannotation Data Into PhysOpt:
------------------------------------------------------------
1) SDF Version
Certain version of the Cadence tools produce SDF version 2.0. The
Synopsys SDF readers only accept SDF v1.2 or v2.1, so the file version
has to be changed to allow the SDF file to be read in. This can be
easily done using a UNIX sed command
unix> mv file temp
unix> sed -e 1,5s/2.0/2.1/ temp > file
For example:
unix> mv TOP.sdf1 temp
unix> sed -e 1,5s/2.0/2.1/ temp > TOP.sdf1
2) SDF backslashes
The SDF that the Cadence tools produces may contain backslashes to
'escape' forward slashes (which is the hierarchy delimiter) because the
original DEF input to their flow contained full pathnames. This would
be due to the input DEF describing cells that have logical hierarchy,
so their full pathnames would be present. Within the Cadence
environment, the full path names are treated as 'flat names', ie. the
slash is treated like an ordinary character in the cell's name. So,
when your SDF is written out the cell names will have the form :
top\/block1\/instanceA
When this SDF is back annotated into the Synopsys environment, PhysOpt
gets confused because it tries to search for an instance at the top
level that has the name specified in the SDF. What is required is to
remove the backslashes (which 'escape' the hierarchy delimiter) so that
they revert back to being hierarchy delimiters and the cell names will
then match what is in the Synopsys DB. This can be easily done using a
UNIX sed command
unix> mv file temp
unix> sed -e s/"\\\/"/"\/"/g temp > file
For example :
unix> mv TOP.sdf1 temp
unix> sed -e s/"\\\/"/"\/"/g temp > TOP.sdf1
3) setload data format
Some tools are unable to create 'setload' data using the tcl format
needed by PhysOpt. These tools provide the data using the older Design
Compiler format:
set_load -su value find(net, net_name )
For PhysOpt (as well as PrimeTime), the script has to be translated to
TCL format via 'transcript' (found at.../syn/bin/transcript). Here's an
example to translate 'file1' into 'file2'
unix> setenv SYNOPSYS_DIR /remote/dtg670/image/1999.05
unix> $(SYNOPSYS_DIR)/sparcOS5/syn/bin/transcript -r \
$(SYNOPSYS_DIR) file1 file2
'file2' would be used to apply the 'set_load' commands for Physical
Compiler shell. This file has the format:
set_load -subtract_pin_load value [get_nets { net_name }]
I hope this fully answered Neel's questions concerning how to use PhysOpt
with either the Avanti or Cadence CTS tools, John.
- [ A Dallas PhysOpt AE ]
---- ---- ---- ---- ---- ---- ----
From: Rajesh Pathak <rpathak@cadence.com>
Hi John,
Recently I came across an item in ESNUG that wanted to know experiences with
Power Compiler. I have used Power Compiler extensively while working for
Texas Instruments (Houston). Its been more than 2 years, the numbers are
hazy but the ballpark figures might be of interest to the readers. Power is
an optimzation constraint and the tool order of priority is 1) Timing,
2) Power, 3) Area. DC traditionally does 1) Timing, 2) Area, 3) Power.
There are two heuristics that Power Compiler uses to reduce power:
1. Taking advantage of the positive slack on non-critical paths, Power
Compiler trades path_delays for lower drive cells. Lower drive cells
means lower power.
2. The other technique is based on the switching activity on each of the
nets in the design which is captured during a typical simulation run
and is an additional attribute on each of the nets in the design
annotated by a standard file format (called SAIF I believe). A net
dissipates power as a product of switching activity (the average no.
of 0-->1 or 1-->0 transitions per unit time) and the net capacitance.
A low-switching activity net with a low capacitance and a high
switching activity with higher capacitance are exchanged for each
other resulting in a low switching but higher capacitance and a high
switching but a lower capacitance net. For example, cell foo is
instantiated with port connections n1 having switching activity of
0.2 and n2 with 0.4 with input "A" having a cap of 3pF and input B
having a cap of 5pF, the following will occur --->
foo I1(.A(n1), .B(n2), .Z(n3))
will become
foo I1(.A(n2), .B(n1), .Z(n3))
The result is a reduction of cumulative power.
For most of the modules that I worked on, I found a reduction of 1% to 5%.
Of course this was a 40 Mhz chip with each of the modules consuming power in
the range of 10mW to 100mW. One of the troubling things is that a switching
activity file is just a snap-shot of one application. An other application
might result in a different switching activity file and Power Compiler can
act in a malacious fashion. In the above example an application where
my switching activity of n1=0.4 and n2=0.1 will result in *increased* power
consumption if this application is run. This happens more often than most
people would like to believe. A savings of 1-2% could equally swing in the
other direction and in my experience it should not count as savings at
all. I found that one can push the boundary by revisiting synthesis
methodology accepted for non-low power applications. Some of the useful
techniques that really help are adding more cells to the library repository
1. by removing dont_touch
2. custom cells
3. artificially created "virtual cells" in .lib format.
Another technique is to tighten max rise/fall limit to decrease the short
circuit power consumption.
I am not sure if these observations can be extrapolated to high speed
designs. I did this work on a very low frequency (40 Mhz) design.
- Rajesh Pathak
Cadence Design Systems Houston, TX
( ESNUG 370 Item 7 ) -------------------------------------------- [05/17/01]
From: Tariq Roshan <tariq.roshan@acg.fujitsu-fme.com>
Subject: PrimeTime Scripts & "mkdepend" Missing From Lahti's Tcl TOPS ?
Hi John,
I have downloaded the paper 'Using Tcl to Implement an Efficient Synthesis
Environment' from your Deepchip site. It mentions an "mkdepend" script
for generating dependency lists. Do you know if it is available on the
Web somewhere? Is there a site containing the code for PrimeTime scripts
which go into TOPS methodology?
- Tariq Roshan
Fujitsu
( ESNUG 370 Item 8 ) -------------------------------------------- [05/17/01]
Subject: ( ESNUG 368 #1 ) Synopsys Also Does Strange DCL Support, Too!
> We were asking Avanti to complete the implementation of IEEE 1481 by
> including support for DCL/OLA (Ch1-8). They already support most of
> Ch 9-10, SPEF and PDEF. ...
>
> - Dan Moritz
> LSI Logic Minneapolis, MN
From: Chris Kiegle <ckiegle@us.ibm.com>
Hey John,
I know of a couple other companies that are working to use DPCM/DCL
libraries and the DPCM/DCL interfaces in Synopsys, but we still hear that
we are the only ones asking for these things. (DPCM is Delay and Power
Calculation Model library. Some people call it DCL.)
Something we hit on was a difference in the create_operating_conditions
constraint setting. Synopsys made changes in the DC commands between
99.10 & 2000.05 to make the commands the same in DC & PrimeTime.
In 99.10, the syntax for create_operating_conditions in dc_shell is:
create_operating_conditions -name OP1 -library My_library \
-temperature 100 -calc_mode worst_case -rail_voltages "VDD 1.8"
A "-temp" could be used as a short form for the temperature and DC would
also honor default value settings that existed in the rules. The user
would only have to set the values that were changing.
In 2000.05 / 2000.11, the syntax is
create_operating_conditions -name OP1 -library My_library \
-temperature 100 -process 1 -voltage 1 -calc_mode worst_case \
-rail_voltages "VDD 1.8 VDD2 1.4 VXX 3 ........"
The "-temperature", "-voltage", and "-process" ALL require value settings,
but the "-voltage" and "-process" aren't used by DPCM libraries. Those
variables were added in for the SPDM (Scalable Polynomial Delay Model)
library support. For DPCM, the calc_mode & rail_votages are used just like
in DC 99.10 with the exception that the rail_voltages setting must contain
settings for every rail voltage in the library rather than just those that
require changes from the default values.
A second thing we found is a difference in the way DC reads in the DCL
libraries between dc_shell and dc_shell tcl modes. Dc_shell reads in
DCL libraries, along with the .db files, when a design is read in.
In the dc-tcl shell, *only* the .db libraries are read in with the
design. A read_lib still only reads in the .dbs. Compile, report_timing,
and report_lib will cause the DCL libs to be read in. IT IS TOO LATE AT
COMPILE TIME IF YOU WANT TO SET DIFFERENT OPERATING CONDITIONS. Currently,
the operating conditions are set against the library and they can only be
modified if the library has been read in. So, the current flow we are
using is to 1.) read in a design, 2) do a report_lib, and then 3) set all
of the design constraints.
It's kind of stupid to have to do it this way.
- Chris Kiegle
IBM Essex Junction, VT
( ESNUG 370 Item 9 ) -------------------------------------------- [05/17/01]
From: Gregg Lahti <gregg.lahti@corrent.com>
Subject: Module Compiler, DC-Tcl, & Presto Don't Play Nice With Each Other
Hi John,
We've found a weirdness using DC 2000.11 and a combination of Presto,
dc_shell-t (Tcl), and Module Compiler. If we enable all three items, we
get errors at the "elaborate -gate_clock [module]" phase. The reports
generated during the elaboration don't provide any clock gating
information and then the error pops up at the end of the elaboration:
Error: Module Compiler License is not available; aborting
insert_clock_gating. (PWR-352)
Go to DCSH or disable Presto and the problem goes away. I would suspect
that this problem was masked when we had an Module Compiler license and
then this reared its ugly head when our Module Compiler license expired.
Anyone else see weird issues like these with Presto and Tcl?
Also, has anyone experienced issues of MC corrupting the synopsys_cache
with psuedocells? We were experimenting with MC and wound up getting
"cannot use estimated timing" error messages when we wrote out to a DB
or Verilog file. We tracked it down to a corrupted cache, but I couldn't
figure out if MC corrupted the DW components or if DC incorrectly grabbed
the psuedocells generated from MC. Clearing the cache resolved the issue
via brute force, but that seems overkill and a waste of compute resources
for future issues.
- Gregg Lahti
Corrent Corp. Tempe, AZ
( ESNUG 370 Item 10 ) ------------------------------------------- [05/17/01]
From: Greg Arena <Greg.Arena@Dialogic.com>
Subject: Does The Synplicity Tech Support Staff Treat You Like Shit, Too?
Hi, John,
I am an ASIC engineer working for a recently-acquired division of Intel.
We've been working on an ASIC design project in which we've been prototyping
our design with a Xilinx FPGA mounted on a custom-built daughterboard. We
have been using Synplify as the front-end tool to translate from Verilog RTL
into technology-specific primitves for place & route by the Xilinx back-end
tools. I wanted to comment on Synplicity's technical support and see if
anybody else has observed this problem since I know we are not the only
company that prototypes some of its ASIC designs in an FPGA first.
Every so often with our design, we have been getting an error reported from
the Xilinx MAP tool that there was a
"failure to merge XXX component with F5MUX"
and
"[the] design will exhibit sub-optimal timing"
This is an irritating problem because it results in a low-performance routed
design and it almost always comes up with this error reported on a component
of the design unrelated to the code that I had recently changed. The only
way to fix it is to try changing more code to see if Synplify produces an
EDIF file without the problem in it.
I contacted Synplicity about this on 11/29/00. They asked for more info
about the design which I provided. No response. I waited one week and
asked the Synplicity support engineer who had taken the call if she had
found anything or needed more information. Still no response. After two
weeks, I submitted an update to the problem on their web site asking if
somebody else coud look at it. As of today, the call is still sitting there
open on their support website after I log in.
I am wondering if anybody else has had these problems with Synplicity's tech
support and/or this specific problem. Xilinx's technical support group was
of no help on this one. This is very unprofessional on Synplicity's part.
I'm new to this industry, and it annoys me when I think that this probably
isn't the last problem that I will have that will go unresolved because a
vendor refuses to help a paying customer with a difficult problem.
- Greg Arena
Dialogic/Intel
( ESNUG 370 Item 11 ) ------------------------------------------- [05/17/01]
Subject: Get Cadence Silicon Ensemble Parasitics Into Synopsys Design Power
> I have some problems during the back-annotation of parasitics from Cadence
> Silicon Ensemble to Synopsys Design Power. After having completed
> floorplanning and P&R with Silicon Ensemble Ultra, I generate a Verilog
> netlist (including a clock tree). Additionally, I extract parasitics
> (setload file) from the layout within Silicon Ensemble Ultra/HyperExtract.
>
> I read in the Verilog netlist in Synopsys DesignAnalyzer & Design Power
> and try to back-annotate the setload file, but I get errors, because the
> names of clock nets in the Verilog netlist and the setload file differ.
> e.g. in Verilog netlist:
>
> clk_L1_I1__5 , clk_L2_I1__4 , clk_L3_I1__3 , clk_L4_I1__2 ,
> clk_L5_I1__1
>
> in setload file:
>
> clk_L5_N1, clk_L4_N1, clk_L3_N1, clk_L2_N1, clk_L1_N1
>
> Has anyone an idea, if there have to be set variables within Silicon
> Ensemble or to solve the problem in an other way?
>
> - Armin Windschiegl
> Technische Universitaet Muenchen Germany
From: Gary Nunn <garyn@cadence.com>
Hi Armin,
If the set_load file is coming from Silicon Ensemble's extraction or
estimation then you can use the following envar to have SE output a
pin-based set_load file:
SET VAR REPORT.SETLOAD.USE.NETNAME FALSE ;
I don't think that HyperExtract has the same feature.
- Gary Nunn
Cadence
---- ---- ---- ---- ---- ---- ----
From: Armin Windschiegl <arminw@lis.e-technik.tu-muenchen.de>
Hi Gary,
You are right - HyperExtract doesn't have this feature. I could not create
a setload file, which uses the same names for clock nets like given in the
Verilog netlist.
The problem's roots seems to be in the step "Export Verilog". When
selecting the clock nets in the my routed design, I can see that their
names are the same like given in the setload file. But how it creates the
command "Export Verilog" other clk-netnames, than given in the Silicon
Ensemble database? In the export Verilog form sheet there can only be set
a variable for VDD and GND pins.
The back-annotation of a Verilog netlist with a clock tree and a setload
file into power estimation tools should be a very common design flow. I
would be very grateful, if anybody could help to solve the problem.
- Armin Windschiegl
Technische Universitaet Muenchen Germany
---- ---- ---- ---- ---- ---- ----
From: Ralf Leisner <leisner@cadence.com>
Hello Armin,
There is a inconsistancy concerning the naming of inserted nets in our
layout tools on one hand and the 'hierachical-verilog-out-procedure' on
the other hand. If you do exchange files with netname references (like
RSPF) to tools outside Cadence, you may run in this kind of issues you
described. There are 2 solutions to get a consistant Verilog/RSPF-Pair:
1) Write out a flat Verilog netlist, because it is built up based on
the flat layout database and should reflect the flat representation
100% (including netnames).
2) Write out the hierachical Verilog netlist and read it back by ECO.
That would force the tool to syncronize the flat layout database with
the hier. Verilog netlist (including netnames). Repeat the RSPF
generation, and now the netnames should fit. Important:
- Write out the ECO report file after ECO and check it carefully
to ensure it reflects the changes you are expected.
- Set following variable: 'set v DEF.ECO.TRYRENAME TRUE;' It prevents
the tool (SEW/GE) from deleting routing informations of the
concerning nets.
Otherwise you would need to reroute the nets for which the names have been
changed.
- Ralf Leisner
Cadence Design Systems GmbH Haar, Germany
---- ---- ---- ---- ---- ---- ----
From: Gary Nunn <garyn@cadence.com>
The latest versions of SE have an "auto-resync" feature to update the net
names to be consistent with the hierarchical Verilog netlist. (As Ralf
noted, you need to run the parasitic extraction *after* the resync).
One minor change, the correct envar to set to allow the net renaming to
leave the routing intact is INPUT.DEF.ECO.TRYNETRENAME.
set var INPUT.DEF.ECO.TRYNETRENAME TRUE ;
The main issue with "net name based formats" is that there is no "standard"
defined for how flattened names will be stored. All of the companies agree
on the simple cases, but there are still a boundary case or two that differ
(I think that they are all associated with ports of intermediate modules
that have no connection at the instantiated level).
I definitely prefer Ralf's option #2. (The hierarchical netlist is more
readable/debuggable.)
- Gary Nunn
Cadence
( ESNUG 370 Item 12 ) ------------------------------------------- [05/17/01]
From: Kusuma Arkalgud <karkalgud@JasmineNetworks.com>
Subject: Do You Know Anyone Who Has Design A Synthesizable Link List FIFO?
Hi, John,
Do you know anybody who has designed a synthesizable link-list FIFO?
Would they like to share your code with me? I would also like to know
how a link-list FIFO is different from a regular FIFO and their
advantages/disadvantages.
- Kusuma Arkalgud
Jasmine Networks
( ESNUG 370 Item 13 ) ------------------------------------------- [05/17/01]
Subject: ( SNUG 01 #18 ) Synopsys Owns Up To BSD Compiler's Many Problems
> A MISS AND A HIT: It's unanimous -- everyone who has worked hands on with
> Synopsys' BSD Compiler absolutely detests it. BSD Compiler is reliving
> the life of its older brother, Test Compiler, when ESNUG was swamped for
> almost 2 years with "I hate Test Compiler" customer letters.
>
> - from the SNUG'01 Trip Report
From: "Mouli Chandramouli" <mouli@synopsys.com>
Dear John,
Let me first thank you for the informative, educational and somewhat painful
SNUG'01 Trip Report. I am the product marketing manager for BSD Compiler
and would like to acknowledge the issues raised regarding our boundary scan
synthesis and verification tool.
The customer comments are not unjustified. We have identified many of the
issues and are actively working to fix these defects in upcoming releases.
Please note that some of the issues that were raised had already been
addressed in the current release (2000.11).
In addition to fixing bugs, R&D is working hard on diagnostic enhancements
to BSD Compiler's unique IEEE1149.1 compliance checking features, and
improving the overall boundary scan design flow.
We hope these enhancements will also address many of the issues raised by
the user community.
Finally, Synopsys strongly believes that boundary scan is becoming a
critical part of upcoming test requirements, and we hope that our user
community will see the progress that we are making with BSD Compiler in
the current release and upcoming versions.
Regards,
- Mouli Chandramouli, Product Line Manager
Synopsys Test Automation Products Mountain View, CA
( ESNUG 370 Item 14 ) ------------------------------------------- [05/17/01]
Subject: ( ESNUG 368 #9 ) Moody PrimeTime Runs Commands On Its Own Whim...
> Here is a quote from an engineer working with me:
>
> "The worst problem that I've come across so far is PrimeTime's inability
> to correctly implement false paths. For example, setting false paths
> between all asynchronous clock domains (as suggested by Synopsys) does
> not always work."
>
> And another:
>
> "Also use extreme caution with the 'reset_design' command, you can easily
> be resetting far more than you bargained for!"
>
> I observed this "ignoring false paths" problem in the early days with
> PrimeTime. The realy frustrating thing is that you do not get to find out
> the tool has (partially) ignored your command until you get the results
> from the next report. Why, oh why, does it not tell you it has ignored
> you? There seems to be no way to find out why either!
>
> - Dyson Wilkes
> Ericsson Microelectronics Europe
From: Tobias Thiel <tobias.thiel@motorola.com>
Hi, John,
In the recent weeks I also got very frustrated by PrimeTime when it was
either ignoring the set_case_analysis command or it was unwilling to reset
what was set with set_case_analysis.
As long as I was applying set_case_analysis to input ports everything is
working fine. But when I set it on internal pins, like the clock input of
an extracted model that is instanciated, it sometimes simply shows no
effect. And what is worse, in some cases I was able to set the case
analysis for a pin, but than I am unable to remove it! Even a
reset_design won't do the job, I had to unlink the design and re-link it!
Luckily my customer was not relying on the timing information generated
with the PrimeTime script that I provided. But since interface problems
like these are almost impossible to work around, he missed his deadline
and I was looking (or at least feeling) bad.
- Tobias Thiel
Motorola Germany
---- ---- ---- ---- ---- ---- ----
From: Fu Hui <hfu@ezmsgp.hl.siemens.de>
Hi John,
We have same problem for PT-2000.05-2. We change it back to PT-1999.10
and it works fine now.
- Hui Fu
Microcontroller ICs & DSP
Infineon Technologies Asia Pacific
( ESNUG 370 Item 15 ) ------------------------------------------- [05/17/01]
Subject: ( SNUG 01 #15 ) But What About Mentor's FormalPro Or Innologic?
> EXIT WOUNDS: Out of the 27 e-mails I received on Formality, Verplex or
> Chrysalis: 22 were pro-Verplex; 5 were pro-Formality; and none were
> pro-Chrysalis.
>
> - from the SNUG'01 Trip Report
From: Albin Takami <Albin.Takami@nokia.com>
Hi John,
Concerning the comments you had about Chrysalis, Formality, and Verplex:
I was just wondering if anybody commented about Mentor's FormalPro or
Innologic Systems' ESV-CV? (If there were no comments, I'd be interested
in what users think about these two tools now.)
- Albin Takami
Nokia Mobile Phones San Diego, CA
( ESNUG 370 Item 16 ) ------------------------------------------- [05/17/01]
From: [ The Cat In The Hat ]
Subject: Seeking Source Code For The Defunct Cascade/Duet Memory Compiler
John, Please keep me ANONYMOUS.
I am looking for information on how to get access to the Cascade/Duet
Memory Compiler's source code. As you know, Duet went out of business and
with it all the support for their products vanished. We have been facing
issues with the memories compiled with the memory compiler that we got from
them. We know what the fixes to the memories need to be, but getting
access to the source code would make the task much easier. Thanks.
- [ The Cat In The Hat ]
( ESNUG 370 Item 17 ) ------------------------------------------- [05/17/01]
From: Andrew Peebles <peebles@cisco.com>
Subject: John, You Should Check Out This New Model Checking Company "@HDL"
John,
You should check out this new company "@HDL". They are launching at next
month's DAC. They are doing a hybrid static model checking and intelligent
random simulation product called "@Verifier".
Their team is the gang from Frontline Design and they are funded by Prabhu
Goel and Atiq Raza.
- Andrew Peebles
Cisco Systems
============================================================================
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
|
|
