From: fdrobert@dz12.collins.rockwell.com (Fred D. Roberts)
Subject: Customer ALERT Concerning Life-Threatening SNUG'99 Yo-yo's
John,
One of my co-workers went to SNUG'99 and brought back one of those
Synopsys freebie yo-yo's for me. So I start showing off all of my
school yard yo-yo tricks: loop the loops, rock the cradle, walk the dog,
and around the world. Well, I went into a new set of 'loop the loops',
and the yo-yo suddenly disintegrated! -- one piece flew one way, and the
other piece nearly hit the co-worker who gave it to me. I was left
standing there with the string dangling from my finger. "That was a life
changing experience, coming so close to death," my co-worker said. "I
don't think I will go to SNUG ever again. Too dangerous."
- Fred Roberts
Rockwell International Ft. Collins, CO
( ESNUG 317 Subjects ) ------------------------------------------- [5/99]
Item 1 : The Difference Between Cadence Cell Ensemble & Silicon Ensemble?
Item 2 : Bug in SPARC floating-point implementation?
Item 3 : Sleezy Synopsys Marketing Surveys -- Why We Hate EDA Salesdroids
Item 4 : How Do I Get DC To Buffer Every Output Port? Set_max_fanout?
Item 5 : Seven Cool Tricks From My Adventures Using Test Compiler
Item 6 : Five Lessons I Learned The Hard Way While Using DC 99.05
Item 7 : A Follow-up To The User Tcl Tutorial Questions From SNUG'99
Item 8 : My DW/Sim Nightmare Inferring Usable Pipelined Multipliers
Item 9 : Watch Out! Dangerous ModelTech SDF Back-annotation Sim X Hole !!
Item 10 : What's The Dirt/Success Story On The NEW DesignWare PCI Module ?
( ESNUG 317 Item 1 ) --------------------------------------------- [5/99]
Subject: The Difference Between Cadence Cell Ensemble & Silicon Ensemble?
> Please pardon the potentially obvious question, but I can't figure out
> what the difference is between Cell Ensemble and Silicon Ensemble.
> We're running Cadence 97A and it seems like both CE and SE do back-end
> place and route. SE seems to have a few more features, but to be less
> well integrated with the rest of the Cadence tools. Other than that,
> the on-oline documentation is unclear about how these two tools relate
> to each other and with the rest of Cadence.
>
> Can somone give me a quick insight into the difference between these
> two tools? If one is trying to generate placed and routed layout from
> Verilog or mixed Verilog/schematic designs, which tool should I be
> looking at? Thanks!
>
> - Erik Brunvand
> University of Manchester UK
From: Grant Erwin <grant_erwin@halcyon.com>
It has been a long time since I worked at Cadence, so this should be taken
with a grain of salt, but ...
Cell Ensemble was a two-layer metal tool. If you are using two layers
of metal (only) in your design, then CE will work just fine for you.
Silicon Ensemble, which used to be called Cell3 Ensemble, or just Cell3,
can handle much more sophisticated metallizations, up to six layers of
metal.
On a different note, I suspect you will see startlingly differing levels
of R&D support for these two tools. I don't know if CE is still even
officially supported, if it is, I bet bugs get fixed s-l-o-w-l-y ... on
the other hand, SE is their mainline APAR tool, with heavy competition
in the marketplace, so they are doing lots of maintenance on it.
The "bells and whistles" you refer to in Silicon Ensemble are critical
for doing deep submicron designs. If you're doing 2 micron stuff still
then it isn't mandatory to do clock tree synthesis, have accurate
timing models, et cetera.
- Grant Erwin
Halcyon
---- ---- ---- ---- ---- ---- ----
From: Jeroen Vermeeren <Jeroen.Vermeeren@nym.sc.philips.com>
The difference between Silicon Ensemble (SEDSM) and Cell Ensemble (CE) is
that CE is a channel router, and SE is an area based router. It is true, CE
is usually used for 2 routing layers and SEDSM for more then 2, but you can
use 3 layers in CE and "just" 2 in SEDSM.
My experience is that SEDSM gives better results. Even for 2 routing layers
you should be able to create a 10% smaller circuit with SEDSM then with CE.
Taken that you even get a result with CE, because it's so buggy. I thought
I read an End-Of-Life statement for CE in about a year or so, but I'm not
exactly sure.
- Jeroen Vermeeren
Philips Semiconductors CS Nijmegen
( ESNUG 317 Item 2 ) --------------------------------------------- [5/99]
From: Erik Runeson <erikr@iar.se>
Subject: Bug in SPARC floating-point implementation?
I just discovered what I consider a bug, or at least a deviation from the
IEEE 754 Standard, in the floating-point hardware of an Ultra-1 Sparc
station. When comparing two quiet NaNs with the predicates equal (==) and
not equal (!=), the Invalid Operation flag was raised. Now, the standard
very clearly states that these predicates should not raise Invalid Operation
when the operands are unordered.
Does anyone know why Sun has choosen not to follow the standard for
this case?
- Erik Runeson
IAR Systems AB Uppsala, Sweden
( ESNUG 317 Item 3 ) --------------------------------------------- [5/99]
From: "Jay Adams" <jadams@fore.com>
Subject: Sleezy Synopsys Marketing Surveys -- Why We Hate EDA Salesdroids
John,
I could not believe my eyes when I saw this marketing survey from
Synopsys. I actually was going to return it with additional comments on how
they could improve their product until I saw what this guy did. He put
prefilled answers *after* his "Thank you" and put them after a *whole page*
of white space, so the average person would not even notice them when they
responded. I would have given permission for him to use my survey
information with other companies, but instead of asking for it -- he thought
he would just take it.
- Jay Adams
FORE Systems
-----Original Message-----
From: DesignWare Foundation Group [mailto:fdation@Synopsys.COM]
Subject: DesignWare Foundation May99 EST update
Dear Jay,
In the past, you indicated that you are a user of DesignWare Foundation
Library. We wanted to let you know about our latest May99 EST release.
With this release, DesignWare Foundation Library (www.synopsys.com
/designware) dramatically improves in two key areas:
1) Solve complex control problems with the area-efficient, 8051
micro-controller:
* Royalty-free Intellectual Property (IP)
* Intel 803x/805x binary compatible
* 3x faster than the original controller at the same clock rate
* Now in limited production (visit www.synopsys.com/dwpromo)
2) Attain higher quality of results:
* 20% area savings with new "rpcs" algorithm for the arithmetic family
* 10% smaller and 30% faster multiplies with new squaring (x*x)
component
* 50% area savings with the duplex multiplier
* Halve area with new integrated divider and remainder component
Finally, in order to serve FORE Systems, Inc. better and to get the May99
release, please answer the following questions:
* How satisfied are you with DesignWare Foundation Library?
() Very Satisfied
() Satisfied
() Not Satisfied
* Why didn't you download our last Feb99 release?
() Someone else in my group/company already did
() Didn't contain anything new that I needed
() Didn't hear about it
() Don't use Foundation
() Don't have permission to install new release
() Too complex/No time
() Other
* Would you like instructions on downloading the May99 EST release?
() Yes
Thank you for making DesignWare Foundation your choice for Intellectual
Property.
Greg Tanaka
DesignWare Marketing Manager
designware@synopsys.com
* Can we share your data with other companies?
(X) Yes
* Can we contact you in the future?
(X) Yes
[ Editor's Note: No, I didn't modify that sleezy survey form in any
way; that Synopsys DW marketing huckster really did have those two
pre-answered questions 69 blank lines after his sig! - John ]
( ESNUG 317 Item 4 ) --------------------------------------------- [5/99]
From: Will Leavitt <leavitt@giganet.com>
Subject: How Do I Get DC To Buffer Every Output Port? Set_max_fanout?
John,
What's the best way to "set_max_fanout" on an output?
I would like to force design compiler to put a buffer on all output
ports, and to not use the buffered output internal to the module. The
obvious way to do this would be to do a
set_max_fanout 1 all_outputs()
but of course set_max_fanout can only be used on input ports (why???).
I can usually get what I want with the right combination of loads and
output delays on the output port, but there are cases where this
doesn't always work. Ideas?
- Will Leavitt
Giganet, Inc.
( ESNUG 317 Item 5 ) --------------------------------------------- [5/99]
From: Robert Wiegand <rwiegand@ensoniq.com>
Subject: Seven Cool Tricks From My Adventures Using Test Compiler
Hi John,
I just completed a design using Test Compiler. (I did most of the work in
the 1998.08 release, when I ran into that last bug (below) I switched to
the 1998.08-1 CD release, but it behaved the same. I have yet to try it
with 1999.05, I have several days of script modifications for non-backward
compatible command changes in the new version.) This particular design,
although relatively small (~35K + RAMs), packs a lot of nasty for Test
Compiler to deal with. There are 4 external clocks which become 8 internal
clock domains at the core level after various gating (for power control),
inverting and dividing logic in the clocks block (top level instances a
pads block, a clocks block, and a hierarchical core). Our ASIC vendor
allows for 4 scan chains, and prefers us to manage our own test_se (scan
enable) buffering. This led to some interesting problems and some cool
tricks to solve them.
COOL TRICK #1: The -scan and -incremental_mapping compile switches can
be used together.
This trick doesn't fix a particular problem, but I thought I'd mention it
here. My intention was to economize on Test Compiler/DCXP license usage.
Design exploration compiles can proceed without scan until design issues
are worked out, then scan is added incrementally with all the benefits of
compiling with scan. It did help to fit scan into my methodology as
described in the SNUG99 paper about MIN/MAX compile (shameless plug,
sorry!).
I chose not to route the scan chains at each module, but to wait for full
core level visibility before routing the chains with insert_scan. This led
to an interesting problem: compile -scan does not generate a test_se input
to a module. Insert_scan does, and at the core level the tool now sees all
loads on test_se at once. The compile log started at about 300ns timing
violation and I killed it after 6 hours.
COOL TRICK #2: To manage test_se fanout when running insert_scan at the
core level, run insert_scan with no optimization and use incremental
compile block by block to clean up the mess. Here's the script:
/* route scan chains without optimization */
set_drive 0 find(port,scan_enable_port) /* scan_enable_port = "test_se" */
set_resistance 0 find(net,scan_enable_port) /* net & port are same name */
set_don't_touch find(net,scan_enable_port)
insert_scan -ignore_compile_design_rules -map_effort low
remove_attribute find(port,scan_enable_port) rise_drive
remove_attribute find(port,scan_enable_port) fall_drive
remove_attribute find(net,scan_enable_port) ba_net_resistance
remove_attribute find(net,scan_enable_port) don't_touch
/* fix design rules from scan chain routing - buffer test_se */
suppress_errors = suppress_errors + {UID-95}
foreach (design_name,(find(design) - core_block) {
/* core_block = name of core design */
current_design design_name
if (find(port,test_se)) {
set_max_fanout 1 test_se
compile -incremental_mapping -only_design_rule
}
}
current_design core_block
suppress_errors = suppress_errors - {UID-95}
check_test
With the above procedure, the scan chains were routed and the test_se tree
was buffered in ~15 minutes. Be sure compile_no_new_cells_at_top_level
is set to false, or non-hierarchical blocks will not be fixed as I found
out the hard way.
Since I had 8 clock domains at the core, I now had 8 unballanced scan
chains. I turns out that clocks 1-3 were fairly balanced, but I needed to
mix clocks 4-8 on the forth chain to balance the rest. DCXP allows you to
mix edges or mix clocks in scan chains, but for the whole design, not
individual scan chains. Also, DCXP doesn't pay attention to insertion
delays on clocks. This is ok if you have one clock per chain, or mix edges
of one clock on a chain (DCXP will put negedge flops ahead of posedge
flops), but bad news if you want to mix multiple edges of multiple clocks
in a single chain. The desired order is from largest insertion delay
negedge to smallest insertion delay posedge. It can be done, as long as
you split your dual edge clocks into separate posedge and negedge domains.
COOL TRICK #3: To specify the clock domain order when mixing clocks and
edges on the same chain, split posedge and negedge into separate domains,
then use the all_registers command to specify the order:
/* name scan chains */
set_scan_path chain_1
set_scan_path chain_2
set_scan_path chain_3
set_scan_path chain_4
/* specify clock ordering in chains */
set_scan_path chain_1 all_registers(-clock clock1) -complete true
set_scan_path chain_2 all_registers(-clock clock2) -complete true
set_scan_path chain_3 all_registers(-clock clock3) -complete true
set_scan_path chain_4 all_registers(-clock clock5) \
+ all_registers(-clock clock4) + all_registers(-clock8) \
+ all_registers(-clock clock6) + all_registers(-clock7) -complete true
The mapping of core level clocks 1-8 to external clocks A-D is as follows:
Clock1 = posedge clockA
Clock2 = gated posedge clockA
Clock3 = posedge clockB
Clock4 = negedge clockB
Clock5 = gated negedge clockB
Clock6 = divided posedge clockC
Clock7 = posedge clockD
Clock8 = negedge clockD
Now for the top level. Here there were two new complications. First, the
clocks block had dividing logic in it and needed to be added to chain_4 (a
test_mode signal was used to bypass the dividing logic to make the divided
internal clock controllable). Second, the clocks were now defined from
external pins, and now paths crossing between edges of the same clock were
generating capture violations. At the core level, DCXP assumed all 8
clocks were posedge which hid this problem. The second problem, by itself,
can be solved by multi_pass ATPG. More on that in a bit. These two
problems interacted in some interesting ways. Based on the insertion delay
of the clock performing the divide in the clocks block, I wanted these
registers to be inserted in chain_4 between clock8 and clock6 with lockup
latches. Even though I had the core declared as existing scan, everything
was getting jumbled around. Once again, I needed to specify the scan
chain order, leading me to...
COOL TRICK #4: To specify the scan chain order from the top level when
mixing clocks, create temporary clock domains, then use the all_registers
command to specify the order:
/* create temporary internal clocks for register grouping */
create_clock core_block/clock1 -period default_period -name clock1
create_clock core_block/clock2 -period default_period -name clock2
create_clock core_block/clock3 -period default_period -name clock3
create_clock core_block/clock4 -period default_period -name clock4
create_clock core_block/clock5 -period default_period -name clock5
create_clock core_block/clock6 -period default_period -name clock6
create_clock core_block/clock7 -period default_period -name clock7
create_clock core_block/clock8 -period default_period -name clock8
create_clock clocks_block/clock9 -period default_period -name clock9
/* name scan chains */
set_scan_path chain_1
set_scan_path chain_2
set_scan_path chain_3
set_scan_path chain_4
/* specify clock ordering in chains */
set_scan_path chain_1 all_registers(-clock clock1) -complete true
set_scan_path chain_2 all_registers(-clock clock2) -complete true
set_scan_path chain_3 all_registers(-clock clock3) -complete true
set_scan_path chain_4 all_registers(-clock clock5) \
+ all_registers(-clock clock4) + all_registers(-clock8) \
+ all_registers(-clock9) + all_registers(-clock clock6) \
+ all_registers(-clock7) -complete true
/* remove temporary clocks */
remove_clock clock1
remove_clock clock2
remove_clock clock3
remove_clock clock4
remove_clock clock5
remove_clock clock6
remove_clock clock7
remove_clock clock8
remove_clock clock9
This worked great, except DCXP was juggling the order of the clock domains
in chain_4. It turned out that DCXP was assuming an inverted waveform on
one of the dual edge clocks to get a smaller number of cross clock
violations.
COOL TRICK #5 Before running the top level insert_scan, check for the
presence of a .tpf (test protocol file) file. If is exists, load it. If
it does not, create one. If there are ordering problems after insert_scan,
check and edit the .tpf file so that all clock waveforms are rising edge.
which scan_directory + top_block + ".tpf"
if (dc_shell_status) {
read_init_protocol scan_directory + top_block + ".tpf"
} else {
write_test_protocol -out scan_directory + top_block + ".tpf"
}
Ok, scan chains are routed in the specified order, life is good! Not quite
yet I noticed a pile of TEST-294 messages in the log file telling me that
all scan_enable inputs to the flops get disconnected during the top level
insert_scan. Since the insert_scan finished quickly, I figured it must
have reconnected these inputs to my existing test_se tree. Examining the
netlist, I found this to be true, but I also found a duplication of test_so
muxes at the core and in the pads. I.E. the scan outputs were muxed with
functional signals twice. I got around this by forcing the core level
insert_scan to generate dedicated scan inputs and outputs:
set_scan_configuration -dedicated_scan_ports true
I have not yet gotten around the other problem. I took the DC-XP Advanced
Scan Synthesis course after SNUG, and picked up this bit of info: DCXP
will interpret a pre-connect test_se as an unsupported functional
connection. The solution presented was to break the connection and remove
the net before running insert_scan. I tried various combinations of places
to break this connection, all of which produced the same TEST-294 messages
along with different incorrect implementations. The closest solution was
to leave the connection intact, producing the TEST-294 message but
producing a correct implementation. Has anyone else run into this? I've
tried it with 1998.08 and 1998.08-1.
Two more for the road: Multi-pass ATPG works great for mixed edge designs.
Take the .tpf file as generated earlier, copy it to same_name.pass2.tpf
and invert the necessary waveform.
COOL TRICK #6: Use tpf files for multipass ATPG. A generalized ATPG
script can be written by checking for the second tpf file:
read_init_protocol scan_directory + top_block + ".tpf"
check_test
create_test_patterns -output scan_directory + top_block + "_atpg.vdb"
which scan_directory + top_block + ".pass2.tpf"
if (dc_shell_status) {
multi_pass_test_generation = true
read_init_protocol scan_directory + top_block + ".pass2.tpf"
check_test
create_test_patterns -input scan_directiry + top_block + "_atpg.vdb" \
-output scan_directory + top_block + "_atpg2.vdb"
}
COOL TRICK #7: If there is no preference for bidirectional pins to be
input or output during scan, try both and pick the one with higher
coverage.
The last trick gave me an additional 3 or 4 tenths of a percent coverage.
With all the above tricks, and most importantly the up-front commitment of
all the designers to write scan compatible RTL, we were able to get just
over 99% coverage on this design.
- Bob Wiegand
Ensoniq, Corp. Malvern, PA
( ESNUG 317 Item 6 ) --------------------------------------------- [5/99]
From: gmann@ford.com (Greg Mann)
Subject: Five Lessons I Learned The Hard Way While Using DC 99.05
John,
I've been playing around with DC 99.05 quite a bit lately and thought I
should pass along what I've learned the hard way. Did you ever go into a
candy store as a child and see so many wonderful things and wanted to have
it all? But your Mom told you to pick just one thing. Well that might be
good advice when using new features in DC 99.05.
Synopsys version 99.05 has some nifty new features which are quite useful,
but also has some hidden "features" which can bite you -- especially if you
get too greedy and start using the nifty features all at the same time.
I'll mention some of the nifty features along with what's bitten me.
propagate_constraints:
The propagate_constraints command has already made my life much easier by
simplifying the application of constraints in a design hierarchy.
Constraints can be applied at a lower level of the hierarchy and then
propagated to the top level with the propagate_constraints command.
Propagate_constraints works as advertised and only as advertised. So be
sure to read the documentation. I had a case in which I segmented timing
paths using input and output delays on an internal pin. These constraints
are not propagated (yet--track STAR 69625). I was able to get around this
problem thanks to the the new "-through" option for timing exceptions.
Gated clock timing checks:
Design Compiler and PrimeTime now both provide for timing checks on gated
clocks. These timing checks can be controlled on a per-instance or
per-design basis. The catch is that Design Compiler and PrimeTime are
inconsistent in how they implement checks on gated clocks. So if you use
both tools, be sure to read the docs for each tool. My understanding is
that R&D is working to bring the tools more into line (read the release
notes for the latest PrimeTime release), but don't take anything for granted
yet at this point. Track ESTAR 69365 for this issue.
Design Budgeting:
Design Budgeting is a hot new feature which should be a vast improvement
over characterize when it comes to converging on a reasonable time budget.
It also budgets such things as fanout, etc. Apply top level constraints,
and the allocate_budgets command figures out a good set of constraints for
each sub-block which when met will guarantee that the top level constraints
are met. But be careful if your using other nifty features. If you have
gated clocks or exceptions with the "-through" option, the design budgeter
will completely ignore them. The result is that logic which gates clocks
may be under-constrained and logic along affected false paths will be over
constrained. Design budgeting is a great feature, but be careful if you're
getting fancy. Track STAR 69975 for the problem with ignoring
gated clocks.
Things that Got Broken in DC 99.05:
The syntax checker FATALs when you have exceptions in your script with the
"-through" option. It seems that the syntax checker guys kind of fell
asleep while the rest of Design Compiler moved forward. STAR 69179 has
been filed for this bug.
***This next one is BAD!!!***
The characterize command may convert an exception in the form
"set_false_path -from clk1 -to clk2 "
to
"set_false_path -to clk2"
in lower level blocks in your hierarchy. The result is that the lower level
block may now be completely unconstrained. This will happen in a case where
a design has multiple clocks (Test_clk & Sys_clk for example), but a lower
level module is only affected by the one clock. This problem is new with
99.05. The good news is that they already have a fix which will be
contained in an update which is due out at the end of May. I verified the
fix with a beta version of that patch.
Summary:
The 99.05 release of dc_shell is a big leap forward in a lot of ways, but
if you're feature greedy like I am, make sure you verify that the tool is
doing what it's supposed to. And listen to your Mom.
- Greg Mann
Ford Microelectronics Colorado Springs, CO
( ESNUG 317 Item 7 ) --------------------------------------------- [5/99]
From: [ Erich of Synopsys ]
Subject: A Follow-up To The User Tcl Tutorial Questions From SNUG'99
Hi John,
I was the Synopsys CAE at SNUG who gave the Tcl tutorial. To find it, go
to http://www.snug-universal.org for the slides. What follows below is a
write-up on the user questions I had at the end of my talk. Please do not
post my email address. I am not the CAE responsible for supporting Tcl and
I don't want to get flooded with email.
- [ Erich of Synopsys ]
---------------
Q: How do I configure my .synopsys_dc.setup to use both DC Shell (DCSH)
and DC-Tcl?
A: The recommended way to support both shells is to convert your home and
local .synopsys_dc.setup files into Tcl subset. This can either be done
manually or automatically with the dc-transcript program provided with
DC99.05.
If a particular user or project is going to stay in DCSH mode, then
their home and local setup files can stay in DCSH format. Likewise, if a
particular user or project is going to stay in DC-Tcl mode, then their
home and local setup files can stay in Tcl format. It's only when a
particular user or project must switch between DCSH mode and DC-Tcl mode
that things can get complicated. In this case, if the home and local
setup files are converted over to Tcl-subset then either shell can be
used.
Q: If I only want to use DCSH, do I have to re-write any of my scripts?
A: No. dc_shell will function the same it did before. You only have to
worry about converting scripts if you want to use Tcl.
Q: How can I tell which dc_shell mode is being used from within a script?
A: There is a read-only variable available in both dc_shell and dc_shell-t.
This variable is called "dc_shell_mode" and it will either contain the
value of "default" if you're using DCSH mode or it will contain the
value of "tcl" if you're using DC-Tcl mode. You can use it like this:
# This comment is required at the top of the .synopsys file
# in order for it to be recognized as DC-Tcl instead of DCSH
#
if {$dc_shell_mode == "default"} {
echo "You invoked dc_shell in DCSH mode"
} else {
echo "You invoked dc_shell in Tcl mode"
}
NOTE: You MUST use Tcl-subset for your .synopsys_dc.setup file if you
want to use both shells. This means that even if you have DCSH commands
that you only want to source if you're using DCSH mode, you MUST convert
them to Tcl-subset. There is no way around this. One of the most common
things that people want to do is use "alias" in their setup files. This
will still work and you can use the above if-else to define different
aliases depending on which shell you're using.
/*
* THIS WILL NOT WORK
*/
if (dc_shell_mode = "default") {
include a_dcsh_script
} else {
source a_tcl_script
}
# NEITHER WILL THIS
#
if {$dc_shell_mode == "default"} {
include a_dcsh_script
} else {
source a_tcl_script
}
In both cases, the syntax is incorrect.
# BUT THIS WILL WORK
#
if {$dc_shell_mode == "default"} {
source a_translated_dcsh_script
} else {
source a_tcl_script
}
Q: What's a Tcl collection?
A: I got the sense from the comments that I heard that users wanted to
better understand collections. I hope the following helps to give some
background and better understanding.
The collection concept comes from OOP (Object Oriented Programming).
Rather than treating all data as simple variable types like integers,
strings, or floats OOP treats data as objects. Objects can be made up of
primative things like strings and numbers, but they can also be other
things as well. Design Compiler objects include ports, pins, designs,
cells, nets, etc...
Additionally, OOP combines objects with functions and procedures to make
them more powerful and useful. This idea of coupling data (objects) with
the functions and procedures that know how to manipulate that data is
fundamental to OOP. You don't necessarily need a special programming
language to have OOP. OOP is a programming concept.
If you have been using Design Compiler, you have been using these
concepts all along, you probably just didn't think about it. In DC, you
create design objects by synthesizing RTL to gates. HDL compiler
transforms your RTL into a generic representation of your design
using GTECH cells, nets, ports, etc... DC then takes your constraints and
transforms these objects into your mapped design using library cells.
When you wanted to operate on your design in dc_shell, you could use
commands such as "find(cell)" or "find(pin)" and you would get back
either a string or a list of strings which would hold the requested
data. It was always rather ambiguous whether a given string was holding
a port name, net name, cell name, or a pin name. This may have been
handy at times, depending on the sorts of things you might do in your
scripts, but it is also very prone to errors.
Think of a collection as a place to hold things. Let's say you want to
manage 4 sheep named Larry, Moe, Curly and Shemp. You could just keep
referring to them by their names, but that means that every time you
wanted to bring them up in conversation, you'd have to say, "Larry, Moe,
Curly and Shemp". An easier way to deal with the sheep would be refer to
the herd, eg "MyHerd". So now rather then having to call each of
the sheep out, you can just say, "MyHerd". MyHerd is a symbolic reference
to the sheep, Larry, Moe, Curly and Shemp.
This is how collections work in Tcl. Once you create a collection of
objects, you need only refer to it by it's reference. As it happens this
reference is called a handle. It is easier to keep track of this single
handle than it is to keep passing around the individual names of the sheep.
In real life, manipulating either a herd or four individual sheep is the
same, but in the software world there is a difference.
That said, collection is a group of objects referenced by a string
identifier. There is a set of commands to create and manipulate
collections.
Creating collection commands:
find, all_inputs, all_outputs, etc., get_cells, get_nets, etc...
Manipulating collection commands:
sizeof_collection, foreach_collection, add_to_collection,
remove_from_collection, copy_collection, query_object
Q: How do you convert a collection to a list?
A: We recognize that users will want to do this to get their old scripts
working. Please understand that when you're using collections correctly,
there should be no reason to go back and forth between lists and
collections. However, if you find a real compelling reason, here's how
to do it.
This is an updated version of the collection_to_list procedure that I
gave in the tutorial slides. There was a typo in the version that got
printed and for that I most humbly apologize. Please use this instead.
# PROCEDURE: collection_to_list
# ABSTRACT: Converts a collection of objects to a list of
# string object names.
# RETURNS: a list of object names (strings)
# empty list if it can not get_object_name
# in each member of the given collection.
# SYNTAX: collection_to_list a_handle
proc collection_to_list { args } {
# This is an example of how to process arguments
parse_proc_arguments -args $args result_array
# Iterate through the collection, building up the return list
set var [list ]
foreach_in_collection a $result_array(handle) {
set name [get_object_name $a]
lappend var $name
}
return $var;
}
#
# Define the arguments, command information and usage
#
define_proc_attributes collection_to_list \
-info "Create a list from collection" \
-define_args {
{handle "A collection" handle string required} \
}
Q: How do you convert a list into a collection?
A: Basically, you can add lists of things to a collection once the
collection has been created. Since collections need to know the object
type, you cannot assign arbitrary lists of strings to a collection
directly. The easiest way to create a collection is with the get_
commands. Then you can add lists of objects to the collection:
set a_collection [get_ports {a b c}]
set a_collection [add_to_collection $a_collection {d e f}]
Q: How do you combine two collections into one?
A: Someone asked me how to combine two collections into one. I apologize
for not getting back to you directly but I couldn't find you again in
the crowd at SNUG. Here's an example using ports:
set collection_a [get_ports A*]
set collection_b [get_ports B*]
set combined_collection [add_to_collection $collection_a $collection_b]
Yes, you can also just type:
set combined_collections [add_to_collection [get_ports A*] [get_ports B*]]
Q: Can I use Tcl/Tk from within my DC-Tcl scripts?
A: No. The Tcl that is compiled in as part of DC-Tcl does NOT include Tk.
There's nothing to prevent you from writing scripts in Tk external to
DC. If you come up with something that you absolutely have to do in Tk
that you want to work with DC-Tcl, there's nothing preventing you from
creating an external Tk program and communicating with DC-Tcl via the
standard Tcl communications functions (like Sockets, for example).
( ESNUG 317 Item 8 ) --------------------------------------------- [5/99]
From: Gzim Derti <gderti@intrinsix.com>
Subject: My DW/Sim Nightmare Inferring Usable Pipelined Multipliers
John,
I've been trying to play with inferring pipelined multipliers using
DC but have run into a couple of road-blocks that I can't seem to
work around.
The code that I've generated is below.
library ieee, DW02;
use ieee.std_logic_1164.all;
use ieee.std_logic_arith.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_misc.all;
use DW02.DW02_components.all;
--Include DesignWare library that contains piped mult components
entity pipemult is
port(
resetz : in std_logic;
clk : in std_logic;
ina_s : in signed(15 downto 0);
inb_s : in signed(15 downto 0);
pmult_s : out signed(31 downto 0)
);
end pipemult;
architecture rtl of pipemult is
signal tempmult_s : signed(31 downto 0);
begin
tempmult_s <= mult_4s(ina_s, inb_s, clk);
process(resetz, clk)
begin
if (resetz = '0') then
pmult_s <= (others => '0');
elsif (clk'event and clk = '1') then
pmult_s <= tempmult_s;
end if;
end process;
end rtl;
The trouble that I'm having is two-fold.
1) When I use the inferred version as above, the resultant gates
function as I assumed they would, but when I try and perform an
RTL simulation, the multiply function takes only 1 clock cycle
to complete, instead of the 4 that I requested. In checking the
DW02_components.vhd file supplied by Synopsys, I can see why this
is the case, there is no delay modeled in the mult_4s function.
So, I guess I need to ask if anyone else has tried to use the
INFERRED pipelined multiplier function mult_4s or other and
gotten RTL simulation to match gates???
2) When DC compiles the code above, it generates correct gates, but
there is no way to tell DC to create a RESETABLE pipeline. When
DC spins the gates, it uses whatever gates it deems necessary, and
since the call to the mult_4s only reference inputs, output, and
clock, there seems to be no way to tell DC that I want to be able
to RESET the pipeline. This would be of ENORMOUS benefit for
testability.
And yes, I know that I can do this all manually and then use
balance_registers to distribute the logic between the n-stages of
flops that I place in the RTL. I'm just trying to figure out why
Synopsys would let you do this if you can't match RTL and gate sims??
I don't know if anyone else my have run into this, but I had to ask.
As always, thanks much for ESNUG, John.
- Gzim Derti
Intrinsix Corp. Rochester, NY
( ESNUG 317 Item 9 ) --------------------------------------------- [5/99]
From: "Sean Atsatt" <seana@sierraimaging.com>
Subject: Watch Out! Dangerous ModelTech SDF Back-annotation Sim X Hole !!
Hi, John
What a life! Getting this when I'm trying to tape out a @#!&* ASIC!
We just ran across a serious hole in back annotated timing simulations
causing incorrect functional simulation. The problem occurs when your SDF
back annotation for a gate uses conditional iopath assignments and not all
conditions are covered. This happens quite naturally when you have an X
input.
Consider the case of a single gate implementing the function
Y <= (A1 and A2) or B
Suppose that at a specific point in time A1 = X, A2 = 0, B=0, and B
transitions from 0 to 1. In this event Y will transition from a 0 to a 1.
The question is what is the delay for this event given the following SDF
timing data for the B to Y path.
(COND A1==0 && A2==0 && B ==0 (IOPATH B Y(30:50:90)(20:30:50)))
(COND A1==0 && A2==0 && B ==1 (IOPATH B Y(31:51:91)(21:31:51)))
(COND A1==0 && A2==1 && B ==0 (IOPATH B Y(32:52:92)(22:32:52)))
(COND A1==0 && A2==1 && B ==1 (IOPATH B Y(33:53:93)(23:33:53)))
(COND A1==1 && A2==0 && B ==0 (IOPATH B Y(34:54:94)(24:34:54)))
(COND A1==1 && A2==0 && B ==1 (IOPATH B Y(35:55:95)(25:35:55)))
(COND A1==1 && A2==1 && B ==0 (IOPATH B Y(36:56:96)(26:36:56)))
(COND A1==1 && A2==1 && B ==1 (IOPATH B Y(37:57:97)(27:37:57)))
The answer is that the delay defaults to the built in delay of the gate.
But wait, what if all the built in delays are conditional as well and none
these conditions apply either because of the X input? The answer for MTI
(Model Technology Inc.) VHDL was 0 delay. A fully functional and correc
data path has the wrong delay and with no warning!. This issue was
particularly exacerbated by the fact that we have a large number of RAM's
generating X's on every clock cycle. How many paths in our design are being
simulated incorrectly?
The proposed IEEE 1497 spec for SDF supports a CONDELSE construct, but
neither my Library nor my Simulator support it yet. I talked with MTI
about this issue, and there response was that they were behaving according
to spec and that this was a library problem. This is true in the strictest
sense, however the few VITAL libraries that I have access to don't cover
all the 8 valued possibilities, (0,1,X,U,H.L,Z,-) used in std_logic. I
don't remember how the Verilog libraries I have used in the past handled
this. I think that the simulator has a responsibility to at least warn
the user when a back annotated net list has no applicable delay value for
a gate. Here are the suggestions I sent to MTI (no response yet from MTI).
1. Add a switch which enables a warning if there is no delay that can be
applied from the set of SDF conditionals for that path. (The default
model delay will never be correct in deep submicron.)
2. Add a switch which enables a warning if there is no conditional delay
in the SDF file and no conditional delay in the vital model that can be
applied. (This is what happened to us)
3. Add a switch which enables the selection of the most conservative delay
value out of the conditional set if none of the conditionals are met.
The most conservative solution would be to select the maximum of the
possible delays (assuming the X value was 1 or 0) if you were running
SDF Max and the Minimum of the possible delays if you were running SDF
min. This would be a reasonable solution that would overcome library
issues.
Since I have never run across this before I am wondering if it only shows up
in deep submicron (we're at 0.25) designs where second and third order
affects must be modeled in order to get accurate results.
Do any of your readers have experience with this? Do other simulators
generate warnings when they can find no valid conditional delay to apply?
Do other libraries specify the X conditions in the SDF? I'd be interested
to hear more on this in ESNUG.
- Sean Atsatt
Sierra Imaging
( ESNUG 317 Item 10 ) -------------------------------------------- [5/99]
From: William Liao <wliao@mmcnet.com>
Subject: What's The Dirt/Success Story On The NEW DesignWare PCI Module ?
Hi, John,
Synopsys re-introduced a synthesizable PCI core in the DesignWare library
last year. Have you heard from any one that used it? Now it's in the
DW Foundation library. I heard the first version was difficult to use
(even Synopsys admited that), and the new version is much better. Is this
true? I'd appreciate any info you can pass to me.
- William Liao
MMC Networks
|
|
