> I recently became aware of an apparently undocumented variable in ver
> 2000.05 of Design Compiler: hdlin_enable_presto -- Synopsys informed
> me that setting this true will help the HDL Compiler "work better"...
>
> - Jeff Waite
> Netergy Networks, Inc.
From: Damir Smitlener <damir00@yahoo.com>
John,
I believe there was a typo in Jeff's original post. The actual switch
is hdlin_enable_*pesto*, not *presto*. Invoking this switch causes
Design Compiler to send an email to a North Beach restaurant named
"Pizzelle" ordering a large Pizza Verdi to be delivered to the Synopsys
help desk, thereby enabling them to "work better".
- Damir Smitlener
ASIC Alliance
( ESNUG 357 Subjects ) ------------------------------------------- [8/10/00]
Item 1 : URGENT READ ME: Three DesignWare Bugs Affecting 5 Foundation Parts
Item 2 : ( ESNUG 355 #5 ) Avanti Star-RC, EPIC Arcadia, Cadence Dracula
Item 3 : ( ESNUG 356 #2 ) Cadence Diva LVS Tricks For Identical Devices
Item 4 : ( ESNUG 356 #0 ) "Hot" Tech Docs & Users Debugging Beta "Presto"
Item 5 : Initialzing An Array Of Constant Integers In A Functions Return
Item 6 : Users Seek DC Hold Fixing Strategies & Insertion Delay Approaches
Item 7 : ( ESNUG 356 #4 ) Synchronizers & Timing Problems With Reset Trees
Item 8 : ( ESNUG 356 #5 ) Converting Xilinx/Altera Gates Into ASIC Gates
Item 9 : ( ESNUG 356 #7 ) DC, Multiple Clocks, and MUXes In Clock Gating
Item 10 : ( ESNUG 356 #6 ) Find The Driving Cell Of A Specific Net In DC
Item 11 : ( ESNUG 356 #3 ) Synopsys Formality With Scan/BIST/JTAG Issues
Item 12 : ( ESNUG 346 #2 ) C-Level "System Compiler" Spanks SystemC/CynApps
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 357 Item 1 ) --------------------------------------------- [8/10/00]
From: [ Synopsys DW R&D ]
Subject: URGENT READ ME: Three DesignWare Bugs Affecting 5 Foundation Parts
John,
Per our voicemails yesterday, here are descriptions of the DesignWare bugs
that we have recently uncovered. We would like to get the information about
these bugs distributed as widely as possible within our user base. We would
like to have them included in the next edition of ESNUG, if possible.
Anyone using any of the following parts:
* DW_fifoctl_s2_sf
* DW_fifo_s2_sf
* DW_asymfifoctl_s2_sf
* DW_asymfifo_s2_sf
* DW_16550
should read on below to see if their design is affected. Two of these DW
problems were fixed in the DesignWare Foundation 1299-3 patch EST
(Electronic Software Transfer) release. The third has a workaround and will
be fixed in the upcoming September 2000 EST release.
STAR 104287
===========
Affected Components:
* DW_fifoctl_s2_sf
* DW_fifo_s2_sf
* DW_asymfifoctl_s2_sf
* DW_asymfifo_s2_sf
The DesignWare 2-clock FIFO components may intermittently fail to
achieve the empty state, when there are simultaneous push and pop
requests (i.e. input pins push_req_n and pop_req_n are asserted, and
the rising edges of push_clk and pop_clk are close to one another),
and the pop interface:
* has only one word in the FIFO, OR
* has two words in the FIFO, and the almost empty parameter is set
to one.
This will cause the state flags at the pop interface to show incorrect
values.
A similar situation also exists with the full state at the push
interface. The 2-clock FIFO components may intermittently fail to
achieve the full state when there are simultaneous push and pop
requests (i.e. input pins push_req_n and pop_req_n are asserted, and
the rising edges of push_clk and pop_clk are close to one another),
and the push interface:
* has (depth-1) words in the FIFO, OR
* has (depth-2) words in the FIFO, and the almost full parameter
is set to one.
This will cause the state flags at the pop interface to show incorrect
values.
This is an asynchronous sampling problem, and it shows up under
special circumstances. It is unlikely that gate-level simulation would
demonstrate this problem.
This problem does not affect the behavioral simulation models of
DesignWare 2-clock FIFO components.
WHAT TO LOOK FOR IN YOUR DESIGN
-------------------------------
If your design uses a dual clock FIFO or FIFO controller
(DW_fifoctl_s2_sf, DW_fifo_s2_sf, DW_asymfifoctl_s2_sf, or
DW_asymfifo_s2_sf) and your system meets one of the following
conditions, then it is likely to be susceptible to this problem.
* Your system can perform a continuous sequence of pops on each
clock cycle of the pop interface until the pop_empty flag is set.
AND
Your system can issue a push request within four clk_pop cycles
before the pop_empty flag is asserted.
* Your system can perform a continuous sequence of pushes on each
clock cycle of the push interface until the push_full flag is set.
AND
Your system can issue a pop request within four clk_push cycles
before the push_full flag is asserted.
WORKAROUND
----------
There is no workaround for this problem. It has been fixed in
the 1299-3 patch EST release.
STAR 195016
===========
Affected Component:
* DW_16550
A. If the interrupt signal (intr) of DW_16550 is asserted (due to the
Transmit Holding Register being empty), it does not get reset
(as it is supposed to) upon reading the Interrupt Identity Register
(IIR). The interrupt signal stays asserted as long as the
Transmit Holding Register is empty.
B. When DMA_mode is '0', the interrupt signal (intr) of the DW_16550
is incorrectly asserted when there is a single byte in the FIFO
(as if the receiver FIFO trigger level is set at trigger level 1),
even though the receiver FIFO trigger levels are set to 4, 8, or 16.
WORKAROUND
----------
There is no workaround for these problems. They have been fixed in
the 1299-3 patch EST (Electronic Software Transfer) release.
STAR 107432
===========
Affected Component:
* DW_16550
The DW_16550 may generate a false character timeout interrupt, when
serial input data changes very close to the positive edge of the clock.
In gate-level simulations, this may show up as 'X' on the "intr"
(interrupt) pin of the DW_16550 component. In an actual implementation,
the interrupt may occur when it actually should not.
This problem is caused because the serial data input is not internally
synchronized with the DW_16550 clock, for the purposes of generating
the character timeout interrupt When serial input data violates the
setup time with reference to the clock, incorrect value of data may
get registered, which may lead to a false character timeout interrupt.
Workaround
----------
The problem can be worked around by externally synchronizing the serial
input with the clock, before feeding it to the "sin" input pin of the
DW_16550 component. This will eliminate the above described problem,
but will slightly delay the data into the DW_16550 UART. If you are
not using the character timeout interrupt, this bug will have no
affect on the functionality of your design.
The STAR 107432 will be fixed in a new release of Foundation library,
that will be available in approximately the middle of September, 2000.
Procedure To Download DesignWare Library Update
===============================================
To download an update to the DesignWare Foundation Library, via EST,
send email to designware54@synopsys.com. In that email message, send the
following information in the body of the message, in this format:
< <
For example, if your site id is 555, and you want to install the 2000.05
version of Foundation Library, then insert the following two fields in the
body of the message, separated by a few blank spaces:
555 2000.05
We are very sorry for any inconvenience that these STARs may have caused
you. Please contact Synopsys Technical Support at (800) 245-8005 (U.S.
only), or send e-mail to support_center@synopsys.com if you have questions.
- [ Synopsys DW R&D ]
( ESNUG 357 Item 2 ) --------------------------------------------- [8/10/00]
Subject: ( ESNUG 355 #5 ) Avanti Star-RC, EPIC Arcadia, Cadence Dracula
> That one anon review on parasitic extraction ( Item 46 in the DAC'00 Trip
> Report) was terrible! I have to imagine that this person isn't active in
> the backend world --- too many strangely wrong comments and thoughts.
> Have someone who is in the backend read it, and they'll laugh or cry.
>
> - John Lee
> Avanti Fremont, CA
From: [ Engineer X ]
John,
The Avanti AE is correct; I do mostly front end. I know a bit about layout,
but the last extraction stuff I did was when Cadence Dracula was brand new.
I visited about 200 booths at DAC and reported on all of them to the best of
my limited abilities. If he has specific corrections I would appreciate
them; I really want to know the scoop. Politics say I must be anon.
- [ Engineer X ]
---- ---- ---- ---- ---- ---- ----
From: John Lee <jolly@avanticorp.com>
To: [ Engineer X ]
I didn't mean to criticize you personally. Your opinions were more factual
than my opinions would be about front-end products. The extraction market
is fragmented, with about 5 major players -- Mentor (xCalibre), Synopsys
(Arcadia), Simplex (Fire&Ice), Frequency (Columbus) [Frequency is now known
as Sequence], and Avanti (Star-RC).
Historically, Dracula has been the #1 parasitic extraction tool. But about
5 years ago, Arcadia (from Epic then, now part of Synopsys) became the
market leader for "3D RC" extraction.
Recently (97, 98, 99), Star-RC has been the #1 RC extraction tool (according
to Dataquest, etc...) Year 2000 looks like another winner for us, in an
even bigger way.
RC extraction, in some ways, is more of an engine -- kind of like delay
calculation. It is a necessary technology. However, integrated RC
extraction, like integrated delay calculation in a static timing analyzer,
is most important. This is because "timing convergence" is so so important
for 0.18 micron and below physical design. This is where integrated RC
extraction into a P&R tool, or integrated RC extraction with simulation (so
called "analysis" for power/timing/noise) are more important to users.
So rather than just compare accuracy/memory usage/runtime (which are
important), you should also see how well you can sign-off on
power/timing/noise, and how it fits in with your physical design tool.
This is really where Star-RC XT (XT is the high performance option) excels.
This is why the major ASIC vendors like LSI, TI, Lucent, Philips/VLSI, etc.
have chosen RCXT for their flows. Or why the pure play foundries like TSMC,
UMC, CSM all have *purchased* RC for several years for their internal design
services.
Again, I'm really sorry for the rude message. It wasn't intended as a knock
against you, but rather against unreviewed reviews in a "foreign" field!
- John Lee
Avanti Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: [ Engineer X ]
To: John Lee <jolly@avanticorp.com>
> Historically, Dracula has been the #1 parasitic extraction tool. But
> about 5 years ago, Arcadia (from Epic then, now part of Synopsys) became
> the market leader for "3D RC" extraction.
Some engineers in my group benchmarked Arcadia and decided to stop using it
years ago. The results were too flaky compared to Dracula. On nets with
big differences, they couldn't justify Arcadia's numbers. Hence no mention
in my review.
> RC extraction, in some ways, is more of an engine -- kind of like delay
> calculation. It is a necessary technology. However, integrated RC
> extraction, like integrated delay calculation in a static timing analyzer,
> is most important. This is because "timing convergence" is so important
> for 0.18 micron and below physical design. This is where integrated RC
> extraction into a P&R tool, or integrated RC extraction with simulation
> (so called "analysis" for power/timing/noise) are more important to users.
>
> So rather than just compare accuracy/memory usage/runtime (which are
> important), you should also see how well you can sign-off on
> power/timing/noise, and how it fits in with your physical design tool.
Good point! The image I have of Avanti is that your tools work really well
as long as they only talk to other Avanti tools. My current customer, who
asked me to write my DAC report, is using Cadence P&R and Star-RC
extraction - life is not good. My review assumed that this situation would
continue - incorrect for other users.
> This is really where Star-RC XT (XT is the high performance option)
> excels. This is why the major ASIC vendors like LSI, TI, Lucent,
> Philips/VLSI, etc... have chosen RCXT for their flows. Or why
> the pure play foundries like TSMC, UMC, CSM all have *purchased*
> RC for several years for their internal design services.
My impression is that RC has a big and generally satisfied customer base,
but XT was new and there really aren't a lot of testimonials yet.
- [ Engineer X ]
---- ---- ---- ---- ---- ---- ----
From: John Lee <jolly@avanticorp.com>
To: [ Engineer X ]
Avanti Star-RC licensed the LEF/DEF interface from Cadence last year, so we
now have a neat, smooth flow with 3rd party P&R tools. Some of our biggest
customers are running this flow.
Many of our Star-RC users have upgraded to Star-RC XT; our corporate web
site has some of the testimonials there. It (XT) is worth checking out!
(Again, I apologize for the shameless plug).
If your customer is running a LEF/DEF flow, or similar cell based
methodology, RC XT should be an easy fit.
With respect to your comment on Arcadia, I think the biggest trouble that
users have, even today, is validating the accuracy claims from EDA vendors.
The most common way today to validate is to compare vs. Quickcap (also known
as Raphael-NES). Quickcap is a great reference solver, and there are
automatic flows from "full-chip" extraction tools like Star-RC to generate
comparison data.
- John Lee
Avanti Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: [ Engineer X ]
To: John Cooley <jcooley@world.std.com>
John (Cooley),
I may have been unclear about John Lee's response (or my limited
understanding of it). His point is that for DSM designs, you get into this
cycle of (tweak netlist -> tweak placement -> tweak routing -> do
extraction -> STA -> tweak netlist) and the integration of the tools is
far more important than whether any single step is really the fastest/most
memory efficient tool available. This is a damn good point. The
interesting thing here is that all the major physical synthesis players
are going to a single binary database that all the tools connect to. All
except Synopsys. They do not yet have a detailed router, and their EPIC
backend tools have been languishing for years (they claim this will soon
change - we'll see). The interesting thing is that they are the ones with
all the customer tape out stories. Seems like either they are right in
their assertion that this backend cycle doesn't matter if your placement
is good enough, or they have attempted to do less than their competitors
and hence gotten a finished product earlier. It will be interesting to
watch.
- [ Engineer X ]
( ESNUG 357 Item 3 ) --------------------------------------------- [8/10/00]
Subject: ( ESNUG 356 #2 ) Cadence Diva LVS Tricks For Identical Devices
> I have a little problem, I made a layout of a circuit which is symetrical
> in architecture but not in parameters: A differential input with 2
> resistors load. The only difference is transistor width.
>
> When I do a LVS, the netlists don't match, the netlister would want me to
> invert my 2 transistors. When I add an output pin, the problem is solved
> (the circuit becoming non-symetrical).
>
> Anybody know how to do to solve this problem without adding a new pin??
>
> - Sami Aissa
> Matra Nortel
From: Wayne Miller <Wayne.A.Miller@smsc.com>
When all else fails, use an LVS correspondence file to identify one or two
instance matches between the schematic and the extracted layout. It's a
bit of a cludge, but it works, and surprisingly, extraction to extraction,
many of the extracted instance names don't change. (If you're just making
small changes to your layout.)
- Wayne Miller
Standard Microsystems Corporation Long Island, NY
( ESNUG 357 Item 4 ) --------------------------------------------- [8/10/00]
Subject: ( ESNUG 356 #0 ) "Hot" Tech Docs & Users Debugging Beta "Presto"
> I recently became aware of an apparently undocumented variable in ver
> 2000.05 of Design Compiler: hdlin_enable_presto
>
> Synopsys informed me that setting this true will help the HDL Compiler
> "work better" but I haven't had a chance to test this out (yet). I was
> curious if anyone else had heard of this variable or had any feedback on
> it. Thanks.
>
> - Jeff Waite
> Netergy Networks, Inc.
From: Peter Kamphuis <peter.kamphuis@infineon.com>
Hi John,
The hidden variable "hdlin_enable_presto" is not so hidden at all.
Recently I attended Synopsys' Synthesis 2000 Seminar, presenting new and
changed features of the 2000.05 software. One of the slides showed:
New HDL Compiler - Presto
* Re-architected HDL Compiler for Verilog
(VHDL support in an upcoming release) [2000.11 ?]
* Over 50 verilog customer designs tested,
- 6x average runtime improvement over 1999.10
- 35% less memory than 1999.10 release
* Set the following dc_shell variable to enable
the New HDL Compiler
dc_shell> hdlin_enable_presto = true
dc_shell-t> set hdlin_enable_presto true
BTW, even the 2000.05 HDL Compiler Release Notes describe this variable.
As far as I can remember I was told that it's a completely new piece of
software. And as with all new software, there might be bugs in it.
That's probably why it's not yet used as default.
- Peter Kamphuis
Infineon Technologies AG Munich, Germany
---- ---- ---- ---- ---- ---- ----
From: [ A Little Leprechaun ]
John,
Attached, you should find some preliminary info from Synopsys on Presto.
I'm not be allowed to distribute this outside our company, so don't tell
anyone where you got it from, and keep me anonymous.
- [ A Little Leprechaun ]
Editor's Note: What Leprechaun sent me was a 51 page PDF Synopsys tech
doc that completely outlines what Presto is, how it works, its switches,
everything. You can download your own copy of what he sent me at
http://www.DeepChip.com (look in the new "Downloads" section.) It's
interesting reading. (And I wonder how long it'll be before I get
another nastygram from Synopsys Legal for publishing it...)
- John Cooley
the ESNUG guy
---- ---- ---- ---- ---- ---- ----
From: Clint Olsen <olsenc@ichips.intel.com>
John,
That hdlin_enable_presto was covered in Synopsys' most recent tutorials
covering DC 2000.05. It's not undocumented since I was able to file a STAR
against it. The switch enables Synopsys' "new" Verilog reader (Presto HDLC)
and supposedly handles some Verilog "corner cases" more robustly. For
example, don't-cares in expressions are supposed to be better handled (the
current Verilog reader is busted IMO) and the overall memory footprint of DC
when doing a "read -f verilog" is purported to be much less.
However, I managed to find a bug in the damn thing after a few minutes of
use with the "~" operator (requires parenthesis around it's arguments.
Oops). It is in "extended beta", so YMMV...
- Clint Olsen
Intel Hillsboro, OR
---- ---- ---- ---- ---- ---- ----
From: Jon Harris <jharris@siroyan.com>
Hi, John,
I've found the Verilog 2000 support via the hdlin_enable_presto option is
excellent, especially if a lot of your logic structures are replicated. I
have had some code which is 10-20x as long as it needs to be to simply
because Verilog 1995 is so limiting and a lot of potential generate
constructs have to be 'unrolled'.
The question is - does anyone know of any simulators out there which support
Verilog 2000, as that's kind of important if you want to start coding in it!
- Jon Harris
Siroyan
---- ---- ---- ---- ---- ---- ----
From: Brian Coffey <brian.coffey@analog.com>
Hi John,
PRESTO is Synopsys's new "HDL Compiler". I have used it and reported one or
two STARS against it. I think Synopsys hopes to introduce this in the next
release of Design Compiler as the default. I guess it is a "hidden switch"
in this release as it is in extended Beta. I actually found out about it on
a Synopsys Roadshow so it really wasn't hidden. Synopsys also have a new
Verilog gate netlist reader, which you can enable by setting
"set enable_verilog_netlist_reader true".
- Brian Coffey
Analog Devices Limerick, Ireland
---- ---- ---- ---- ---- ---- ----
From: Menno Spijker <menno_spijker@Mitel.COM>
Hi John,
Presto is a new HDL Compiler. I had a problem with Design Compiler and here's
the message that I got back.
"Signal Declaration inside generate statement will be supported in the
next release of VHDL Compiler. The name of the new Compiler is Presto.
It will in 2000.11 release. VHDL Compiler (Presto) will not be enabled
by default. The manuals will include the variable setting to enable it.
Most VHDL-93 constructs will be covered as well."
Seems the switch is not active in the current release yet. But at least
people know about it now.
- Menno Spijker
Mitel Semiconductor Kanata, Canada
---- ---- ---- ---- ---- ---- ----
From: Lars Bo Graversen <larsg@mips.com>
John,
Presto is the "new" HDL compiler which is included with DC release 2000.05.
It was mentioned in the Synthesis roadmap presentation at the recent DAC. I
have been playing around with it a little, but it keeps going "Fatal" on my
design. This seems to be related to the fact that we in general read in a
Verilog netlist containing some clock gating stuff (which is instantiated in
our RTL verilog) before reading in the RTL. This apparently does not (yet)
work with Presto.
"This is what is happening: The netlist reader is leaving the HDL Compiler
at some state, and is not resetting it before it's done. Reading in an
RTL file following it is causing Presto to fatal. There isn't any WA
for this, except to read the RTL before the netlist. This will be fixed
in the next release."
Is the answer I got from tech support on this issue.
- Lars Bo Graversen
MIPS Denmark
( ESNUG 357 Item 5 ) --------------------------------------------- [8/10/00]
From: Jonathan Ferguson <Jonathan_Ferguson/ARC@arccores.com>
Subject: Initialzing An Array Of Constant Integers In A Functions Return
Hi John,
I am wondering if you or any of the other ESNUG members know of a work
round/tip/trick for a problem I have.
I need to inizitalise a quite large array (up to 256x256) with an array of
constant integers returned by a function (the function generates the
constants dependant upon some parameters in a generic list.)
My problem is I belive Synopsys will only allow constants to be assigned
integers during elaboration. Is this correct and/or is there anyway to
get around this?
- Jonathan Ferguson
ARC
( ESNUG 357 Item 6 ) --------------------------------------------- [8/10/00]
From: [ No Names Here ]
Subject: Users Seek DC Hold Fixing Strategies & Insertion Delay Approaches
Dear John,
PLEASE ANONYMIZE THIS MESSAGE: thanks.
I would appreciate hold-fixing strategies from you/your readers. One of our
designs showed up several hold problems between FFs that had no intermediate
logic in the Q-D paths. We're now trying to address this issue in synthesis
land...
The option we're considering is using 'connection_class' in Library Compiler
to prevent Design Compiler from connecting one FF directly to another. This
is obviously a drastic measure, but I couldn't think of another way to
ensure no two FFs were 'directly' connected. Area is not a big concern for
our design, so we're not as concerned with the additional gate count.
- [ No Names Here ]
---- ---- ---- ---- ---- ---- ----
From: Ravikanth Nukala <nukala.ravikanth@st.com>
Hi John,
I have a question on Latency (insertion delay). I want to know who exactly
specifies the latency number in the ASIC flow? And how it is calculated? I
am talking with respect to clock tree insertion.
- Ravikanth Nukala
ST Microelectronics
( ESNUG 357 Item 7 ) --------------------------------------------- [8/10/00]
Subject: ( ESNUG 356 #4 ) Synchronizers & Timing Problems With Reset Trees
> I have a reset net in my design. I am using "set_ideal_net" command in
> Design Compiler, but I still see huge SN/RN to Q/QN delays in my SDF file
> for any FF connected to the reset net. My design is hierarchical. Does
> anyone know how to take care of this problem?
>
> - Hooman Dadrassan
From: Wayne Miller <Wayne.A.Miller@smsc.com>
If I understand this correctly, you have a reset that drives a large load,
and you're running a pre-layout gate level simulation.
What you're seeing is correct.
"Ideal nets are networks of nets that are free from max_capacitance,
max_fanout, and max_transition design rule constraints. Ideal nets
are useful for reducing DRC violations caused by clock trees, because
these networks usually have high max_capacitance and max_fanout
violations."
But set_ideal_net doesn't change the physics of gate delays. When you
heavily load a buffer, its delay and transition time increases. If you need
to fix this in pre-layout sims, modify the propagation delay reported in
your SDF file for the buffer. Of course, this only makes sense if you're
going to buffer the net later in P&R.
Your other choice is to have Synopsys buffer the net for you. My AE has
been telling me there's some new buffering algorithm that does this nicely
for RESETs and SCAN_TEST_ENABLEs. (I haven't tried it yet.)
- Wayne Miller
Standard Microsystems Corporation Long Island, NY
( ESNUG 357 Item 8 ) --------------------------------------------- [8/10/00]
Subject: ( ESNUG 356 #5 ) Converting Xilinx/Altera Gates Into ASIC Gates
> I was just wandering if you know what the ratio of the newer FPGA gates to
> ASIC gates is? I have asked Xilinx but they couldn't tell me. I am new
> to the FPGA/ASIC process and am trying to come up to speed. Even a
> ballpark conversion ratio would be helpful.
>
> - Chris Frailey
> Motorola
From: Dave Chapman <dave@goldmountain.com>
John,
I'd start by saying that it depends on the vendor. For traditional Xilinx,
it you get 5-7% utilization, you did good (20:1 or 14:1 ratio.) For the
newer Xilinx, most Altera, and most other vendors, it's kind of hard to get
above 15% utilization (7:1 ratio).
I would expect these numbers to improve as place-&-route software improves,
but not by much. The problem is that the "macrocell" style of building
CPLDs and FPGAs does not lend itself to good automatic utilization.
Macrocells containing an ALU slice and all kinds of stuff frequently get
used as a 2-input MUX.
Actel claims that their ProAsic family gets much better utilization due to
its "tile" architecture, but your mileage may vary.
I have a simple metric: Find out how many bits of RAM can be built out of
the programmable logic sections (NOT the built-in RAM), and then multiply
by 6. That number is the real-world utilitzation you'll get. Note that
this method produces numbers which are a lot lower that the numbers in the
colorful brochure.
Oh yeah, the "Buildable System" metric. It's _called_ B.S. Go figure.
- Dave Chapman Sonoma County, CA
---- ---- ---- ---- ---- ---- ----
From: Tom Ayers <tomayers@believe.com>
John,
Here is some additional information on conversion factors.
The conversion factors will only work for random logic. Memories vary
greatly in size and implementation between different ASIC implementations
(differential precharge discharge, single ended precharge discharge, single
ended minimum drive latch cell, standard cell latch array, standard cell
register array, etc) as well as differing greatly in FPGA implementation.
Here are some keys to remember:
1) Be careful about logic duplication. Many tools including Synplify for
synthesis and Xilinx Alliance for P&R can duplicate logic blocks either
to reduce net fanout or improve critical path speed. These factors can
change the conversion ratio in much the same way that compiling for
speed vs. area in Synopsys synthesis will do.
2) Memories should be handled one at a time. Both Xilinx and Altera
support special memory areas (block ram) on the die which can be used
for onchip memories but have width, depth restrictions and restrictions
on clocking and ports. Xilinx can also form memories out of CLB LUTs,
but Altera can not. At best, you can get 16bits of memory per LUT,
with approximately 6% additional overhead. Odd sizes has a minor effect
on the size, but additional ports have a dramatic effect as you would
expect.
Given this, the conversion ratios for Xilinx Virtex-E and Altera APEX 20K
random logic gates are approximately 5.3 and 4 respectively. We have not
seen a significant dependance on the type of logic implemented and given the
gate counts that these devices have statistics work in your favor. That is
to say that a Xilinx 2000E can get 378 Kgates and an APEX 20K 1500E can get
375 Kgates. You can do slightly better than this by minimizing logic
duplication if you do not care about running at speed. The best numbers are
4 for Xilinx and 3 for Altera.
Hope this helps.
- Thomas Ayers
Believe, Inc.
( ESNUG 357 Item 9 ) --------------------------------------------- [8/10/00]
Subject: ( ESNUG 356 #7 ) DC, Multiple Clocks, and MUXes In Clock Gating
> What I tried to avoid is to instantiate a technology/vendor specific MUX
> in my RTL code in order to make the code technology independent and
> portable in future. The best solution I have found from solvit is to
> instantiate a GTECH MUX. I am still not very happy for this solution
> either.
>
> - London Jin
> Toshiba San Jose, CA
From: "V. Menezes" <inod@hotmail.com>
John,
With regard to clock gating, the fundamental issue behind writing the code
by London was to ensure that prop delays are "matched." Leaving it to a
synthesis tool is asking for trouble. There are no guarantees the same
MUX cell is being used for matching the prop delays. The foolproof method
is to instantiate a hardcoded MUX instance. If you stick with a specific
ASIC vendor, there is a high probability that the cell name may not change
with technology, thus one may not have to edit the RTL. A small price
to pay!
As a side note, one should also be very careful with clock gating using
MUXes. It is possible for certain circuit topologies of MUXes to produce
a glitch at the output of the MUX, even if the inputs are at the same logic
level and the select input changes. While this problem is a non-issue for
combinational logic that is registered, it can be a disaster if there are
glitches on the clock line. This fact is sometimes hidden from a passive
user of a library. When ever using a MUX for clock gating, (scan mode,
power savings, etc) always use a clock gating MUX provided by your ASIC
vendor.
- V. Menezes
( ESNUG 357 Item 10 ) -------------------------------------------- [8/10/00]
Subject: ( ESNUG 356 #6 ) Find The Driving Cell Of A Specific Net In DC
> It would be great if someone could help me on this. SOLVNET on the web
> hasn't been helpful... I am running Synopsys v1999.05. I would like to
> replace the driver of a a specific net in Synopsys' design, with a driver
> of my own choosing. It would seem I need to:
>
> 1. find the net ("find" command)
> 2. get the driving cell of the net
> 3. delete this cell ("delete_cell" command)
> 4. create a new cell and tie its ports to that of the old cell
> ("create_cell")
>
> It is easy to find the net, with the "find" command. However, I am having
> great difficulty getting the driving cell of the net, once I find the net.
> I can do an "all_connected" on this net, but that gives me a pin list, and
> it includes the loads of the net. I would like to get the driving cell of
> the net, so I can use it as an argument to "delete_cell".
>
> Can anyone tell me how to find the driving cell of a net, assuming I have
> found the net? FYI, we don't have the TCL license.
>
> - Matt Gavin
> Rockwell Collins
From: Scott Evans <scott@sonicsinc.com>
John,
How about:
remove_variable pinList > /dev/null
pinList = all_connected(find(net, "NETNAME"))
remove_variable driverCell > /dev/null
driverCell = filter(find(pin, pinList) "@pin_direction ==out")
This should return a string with | / which you will need to split
to get the instance.
- Scott Evans
Sonics, Inc. Mountain View, CA
( ESNUG 357 Item 11 ) -------------------------------------------- [8/10/00]
Subject: ( ESNUG 356 #3 ) Synopsys Formality With Scan/BIST/JTAG Issues
> You have just to remove your scan outputs, and to force your scan_enable
> to logic 0.... If you use Synopsys Formality, it can be a good way to
> reduce run-time to remove local scan on each sub-bloc:
>
> foreach all_blocs [ find_references CONT:/LIB_NAME/* -hier ] {
> current_design $all_blocs
> echo "design : $all_blocs
> foreach scan_port [find_ports $scan_enable] {
> set_constant -type port $scan_port 0
> }
> foreach scan_port [find_ports $scan_out] {
> remove_object -type port $scan_port
> }
> }
>
> On core design, we earn weeks of simulation. More than that, equivalence
> checking is very fast for verifying automated/manual IPO.
>
> - Pierre Monteil
> ST Microelectronics Grenoble, France
From: Rich Owen <richo@appiangraphics.com>
Hi John,
One point: In ESNUG Post 356, Pierre Monteil from ST suggested forcing
the scan enable to zero on all flops and removing the scan output. While
this certainly would work, it has the big disadvantage of not verifying
that the scan enable chain and enabling logic is correct. I feel the
better approach is to set the scan enable as it would under test
conditions, by forcing the enable input pin. There may be places where
Pierre's approach is needed, but it should be used as a last resort.
I agree that formal equivalency checking is vital, particularly for
multi-million gate designs. We recently used Formality very successfully
to verify large blocks that had been optimized, at times by hand.
We only ran a very tiny subset of our verification suite on the gates,
and that was largely for "peace of mind". The other advantage of
equivalency checking is that once the scripts are up (usually a pretty
fast process), equivalency checking can be run on each iteration of
the layout. You're not going to do that with simulation!
I will say, however, that debugging is a pain. The candidate list of
potential errors often just vaguely points you in the right direction.
Towards the end of the layout phase, we would debug by finding the
differences between the current and the previously verified netlist,
and then comparing that to the candidate list of errors. We didn't
find the schematic viewer all that helpful, as we had been forced
to flatten our major blocks, and generating and viewing a 100k schematic
is not pretty. But there is now way we could have found the problems
by running simulation, so equivalency checking saved us.
- Rich Owen
Appian Graphics
( ESNUG 357 Item 12 ) -------------------------------------------- [8/10/00]
Subject: ( ESNUG 346 #2 ) C-Level "System Compiler" Spanks SystemC/CynApps
> I am starting on a project where a team of architects, familiar with C++,
> are writing all the ASIC functionality in C++ (for simulation speed).
> Then they are handing it off to a team (me and others) to port to Verilog.
> I was wondering if you could provide me with a list of commercially
> available tools that can port C++ to Verilog, and some idea of who has
> the lion's share of the market. Also, any info on strengths/weaknesses
> of these tools would be great.
>
> - Dan Joyce
> Compaq Austin, TX
From: "Dan Joyce" <dan.joyce@compaq.com>
Hi, John,
Back in March of this year, you allowed me to put in this request for
information on Verilog to C++ translators in ESNUG. I gave you one update
with a list of the replies I had received, and which tools I planned to
investigate further. I thought it was time to send you another update as
part of your ESNUG "Social Contract" of sharing what you discover. We have
narrowed it down to one tool, have done two evaluation trials, and have
decided to purchase the tool.
First let me give you some more details about our design problem.
Our project uses an in-house C++ simulation engine that is utilizes lex and
yacc parsers. We write the ASIC code in a "stylized C++". It looks alot
like C++, but has some Verilog looking features (like access to bit fields
within variables, and IO structs that deal with timing between module
interfaces.) It also has some limited capabilities to dump variables to a
waveform tool (ISDB format unfortunately, not VCD). There are some other
powerful features that give us the ability to run with a very flexible set
of test environments that are configurable on a test by test basis.
The lex and yacc parsers transform the "stylized C++" to ANSI C++, then we
can compile and simulate with a C++ executable. Tests are passed in as
input files (nice - no recompile for changes in the tests).
The problem is that to get to gates we have to do a "stylized C++" to
Verilog translation - by hand. Then, we have 2 code bases to maintain.
Most of the simulation is done in the C++. Mixed C++/Verilog simulations
are possible so that the Verilog version of a module replaces the C++
version, and the same tests are run against the Verilog.
- All changes in the Verilog modules (bugs, or redesigns to make timing)
must be moved into the C++ code, if it changes the functionality at a
clock cycle level.
- All changes to the C++ code (bugs or redesigns) must be propagated
to the Verilog if they are to make it into the gates.
We required the following from the tool:
1) Single code base in C++. This requires an automatic path from C++
to gates .
2) Make timing on the gates as well as we would be able to with full
control of the Verilog.
3) Simulation speed similar to what we have with our in-house tool
(thousands of clocks per second with a very large design.)
4) Reasonable Testing and Debug Environment.
5) No simulation licenses, or a reasonably priced site license (we
expect to run as many as 200 simulation runs a night.)
We evaluated:
A.) "SystemC Compiler" from Synopsys
B.) "System Compiler" from C-Level Design
C.) "Cynthesizer" from CynApps
We chose "System Compiler" from C-Level Design.
The main reasons we eliminated "SystemC Compiler" from Synopsys were that
1) Synopsys said SystemC was not ready.
2) SystemC simulations would require a SystemC simulation engine that
would provide simulation speed about as fast, or within an order
of magnitude of their VCS simulator (maybe 3 - 10 times faster than
VCS.) Our in-house simulator gives us about 3 orders of magnitude
simulation speedup compared with VCS when the entire simulation is
in C++ only.
The reason we eliminated "Cynthesizer" from CynApps was
1) We heard from several sources (including someone at CynApps) that
they were about the same as SystemC in simulation speed. They also
have a simulation engine, and the code was not pure ANSI C or C++.
After we were well into our second evaluation with C-Level, we were
told by an AE at CynApps that "with our application", he thought
their simulation speed would be comparable to C-Level or our in-house
solution. We did not investigate this claim since the C-Level tool
was doing so well.
We did two evaluations with "System Compiler" from C-Level Design.
The first was a small module which I had ported to Verilog by hand. My port
took 1 week, but involved some redesign to speed up one path. The C-Level
Apps Engineer ported the "stylized C++" to C-Level C++ in less than a day
(but did not do the redesign on the one path). When synthesized, the
surprising thing was that even when I broke the long path in my re-design,
their tool produced faster gates than mine with much less effort to
synthesize.
The second evaluation involved a very large C++ module (~4000 lines). We
did not have the option to break this up since our simulation environment
didn't allow this at the time. We did most of the port to C-Level style
ourselves in about a week. Within two weeks we had gates and timing was
down to as good as we could get by hand (less than 4 nS).
How did the C-Level tool fare against our criteria:
1) Single code base in C++. Meaning an automatic path from C++ to gates.
Yes. With our process, we have an automatic path from "stylized C++"
to C-Level C++; then System Compiler goes from C-Level C++ to Verilog;
then Synopsys DC_Shell goes to gates. We have the ability to simulate
mixed C++ and Verilog, so we can check the functionality at the pre-
synthesized C-Level Verilog output, as well as the gate level Verilog.
2) Make timing on the gates as easily as we would be able to with full
control of the Verilog. Yes. As good or better timing results with
much less effort than a hand port. There are some limitations to what
we can do with C-Level. Hierarchy is a little bit cumbersome. To get
the simulations to work, no submodule can have both registered paths
and purely combinatorial paths through it. The combinatorial paths
must be broken out into a separate module. This has been OK so far,
even with all our vendor macros (RAMs, LPRAs, etc.). We were also
impressed with the size. As few or fewer gates came out of DC_Shell
using the System Compiler Verilog as our hand coded Verilog.
3) Simulation speed similar to what we have with our in-house tool. Yes.
We have decided to continue to use our in-house simulation engine,
since we have many features invested in it. We have modified our lex
and yacc parsers to output a C-Level style C++ as well as the one with
which we compile to simulate. The experts have told me that our
simulation speed should be within 5% of the C-Level simulation speed.
Right now I am getting 25,000 clocks per second on a test with about
50,000 gates. I have also been told that the C++ simulation should
scale with design size much better than Verilog, so the speedup
comparison will show even more improvement over Verilog when the design
is larger.
4) Reasonable Testing and Debug Environment. Yes and No. With our chosen
process, we are using our in-house C++ simulation environment. We are
not using the C-Level simulation environment. So our simulation
environment is exactly as it would be without System Compiler.
However, it is worth comparing this environment to a Verilog one since
that is the kind I am used to.
Testing Environment: I have found the C++ language to be more powerful
to test in than Verilog. I have attended a Vera class and I believe
Vera gives Verilog users the power of C++, with a cost in simulation
speed. When running on a Verilog design, this cost is not seen as
dramatically because the Verilog is also slow. Testing with C++ gives
you all the power, but the speed is much better.
However, we did have to create some functions in C++ to give us all the
capabilities we were used to. Unfortunately, there are a number of
places where you can get yourself into trouble with C++. Memory leaks,
trashing internal data structures if not coded well, etc. These are
things Verilog and Vera (and I'm sure Verisity and Quickbench) protect
you from.
Debug Environment: We have added some waveform dumping capabilities but
these are not anywhere as easy as in Verilog, and require in-house
support. I would have preferred to use C-Level's process. They are
just now putting in automatic parsing of the C++ code and dumping of
variables and structs to a VCD file. This is also nowhere near to the
point where the Verilog tools are.
5) No simulation licenses, or a reasonably priced site license (we expect
to run as many as 200 simulation runs a night.) Yes. We run with
ANSI C++. We use industry standard C++ compilers to create an
executable. That can be run for free on our UNIX boxes.
Because our design was so big, and the task of verifying a cache protocol
requires so many clock cycles, we absolutely required the simulation speed
of a C++ environment. This left us with the options of
1) two code bases, Verilog and C++
2) one code base with a C++ to Verilog translator.
In this case the C-Level tool appears to give us an effective gain. We are
paying a price due to the fact that there are not many tools that support
HDL design and debug in C++. Waveform viewers, Code Coverage, Linting,
semi-formal verification, are not supported in this environment. (Actually
waveform viewers may be there by the time this is published. This, of
course, is an absolute requirement.)
However, for designs where the simulation speed is needed, this type of
process appears to give some very substantial benefits. Like you, John, I
do not understand why people would switch to another programming language
like SystemC, CynApps, or SuperLog if it did not give a significant
improvement somewhere.
I saw that C-Level got some bashing in your DAC trip report this year. From
what I can tell this centered on their initial attempt to get into both C++
and Behavioral Compiler at the same time. Their BC capabilities had a bunch
of problems. Now that they have reduced their tool to tackle only the
problem of C++ for the benefit of substantial simulation speed, I think it
is a much better product. It may be possible for the BC part of the tool to
be fixed. That would add another capability to the methodology. Right now,
it's not there. I have also been surprised to find out that I prefer coding
in C++ rather than Verilog (despite the fact that all my experience is in
Verilog and I am learning C++ as fast as I can). The code is much smaller
and simpler to write.
I know you said you like a customer tape-out before you believe anything
said about a new type of tool, John. We're not there yet with C-Level, but
I'll write you when it happens.
- Dan Joyce
Compaq Austin, TX
============================================================================
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
|
|
|
