"Customers always talk about one thing -- cost savings. They wait until
10:30 p.m. of the last day of the quarter just to negotiate the last
1 percent out of me. I don't understand it. If you save $10,000 on
an EDA tool, big deal. But if you get a better tool and better
support, you can increase your revenue by $10 million or $100 million."
- Gerry Hsu, the CEO of Avanti ( EE Times 01/23/01 )
( ESNUG 366 Subjects ) ------------------------------------------- [02/23/01]
Item 1 : ( ESNUG 365 #3 ) Another Customer Pissed About Synopsys Hotline
Item 2 : ( ESNUG 344 #5 ) A Second Time User Of PhysOpt Tells His Story
Item 3 : ( ESNUG 365 #10 ) Twelve More Synopsys ACS 1999.10/2000.05 Bugs
Item 4 : ( ESNUG 365 #2 ) User Having Trouble Closing Timing Using PKS
Item 5 : ( ESNUG 365 #1 ) PhysOpt Troubles & Avanti Discouraging PDEF 3.0
Item 6 : ( ESNUG 365 #11 ) PrimeTime With Real & Falsely Monotonic Libs
Item 7 : ( ESNUG 365 #14 ) Non-Error "Errors", DC/PT Tcl Nasties & ACS
Item 8 : ( ESNUG 365 #5 ) DesignSync A Poor Replacement For Cadence TDM
Item 9 : Undocumented DC Varible For VHDL'87 & VHDL'93 Incompatibilities
Item 10 : We're Having Some Troubles With The Synopsys DWPCI v3.4b Core ...
Item 11 : Customer Tells What It's Like To Use Module Compiler With PhysOpt
Item 12 : ( ESNUG 365 #8 ) Superlog, Verisity E-lite, and Avery VCK
Item 13 : How To Use The 'wget' FTP Program For Large Synopsys Downloads
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 366 Item 1 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #3 ) Another Customer Pissed About Synopsys Hotline
> Synopsys used to have a maintenance option that allowed customers to pay
> for software updates & Solvit access. This was significantly cheaper than
> paying for full support. Synopsys no longer offers that option and with
> the increase in tool prices my maintenance bill is up almost 60%. I don't
> understand why I should pay for services I don't use. Calling the
> Synposys hotline is useless. All they do is ask for a test case and file
> a STAR. And the FAEs who are any good work for the consulting group and
> Synopsys charges $$$$ for their services. I haven't heard many complaints
> on this. Is everyone else OK with this?
>
> - [ I Am Sparticus ]
From: [ Rage Against The Machine ]
Hey John,
I'm pretty sure that the problems that people have with Synopsys support is
one of those things that have people so pissed off that nobody has the
energy to talk about it anymore. Not getting decent answers or fixes from
the Synopsys hotline is just something users have come to expect. Perhaps
we don't want to bring up the topic because we're all too embarrassed
that Synopsys somehow got us to pay out the nose for their crappy service.
As far as my own experience, I will call the hotline only as a last resort.
When a problem or an issue has everyone in the office stumped, when I can't
get in touch with our local AE, and when I've exhausted every other option,
I'll end up saying to myself, "Aw, what the hell, maybe they can actually
help me with this one".
Nope. I'd have to say that in nearly every case, my call or e-mail to
Synopsys support personnel has resulted in one of the following ways:
o "No sir, you are wrong. I won't explain why, because you'd probably
catch a flaw in my logic. Can I please close this issue?"
o "I need you to spend the next 8 hours of your life putting together a
very large and cumbersome testcase for me, which probably won't give
me any more insight than I already have. Can I please close this
issue?"
o "I'll have to get back to you on that one, I'll call you back in 30
minutes"... (one month later)... "I was just checking to see if that
problem you had was resolved. Can I please close the issue?"
o "Yes, I think you've found something there. I've submitted a STAR that
will have you up and running again whenever we get around to fixing
that bug. Can I please close the issue?"
o "Yes, that may be an obvious bug, but that's just the way it is, and
nothing can change it. I'll close the issue for you now."
I may have sounded overly sarcastic there, but all of the situations I
described above have happened to me at one point or another. I'm thinking
that these guys only get paid if they can get PRs closed in less than 5
minutes. Anything they are presented with that might take more than a
day to resolve just isn't worth it to them.
Spartacus, you're not alone.
Please take my name off this, John, as there are still a few good Synopsys
FAEs out there who can help me.
- [ Rage Against The Machine ]
( ESNUG 366 Item 2 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 344 #5 ) A Second Time User Of PhysOpt Tells His Story
> I liked Bob Prevett's review in ESNUG 335 #1 of PhysOpt. I see he used it
> in a predominantly Avanti backend tool flow. I'm about to leave Matrox
> and join a new start-up, so I thought I'd send you a review of what it was
> like to use PhysOpt in a mostly Cadence backend tool flow. ...
>
> Next time, my plan would be to use PhysOpt in a completely hierarchical
> fashion. First synthesize and place, and then route all of my modules.
> I'll then assemble it into a full chip using a real top level router. ...
>
> - David Romanauskas, Design Engineer
> Matrox Montreal, Canada
From: David Romanauskas <dromanau@hyperchip.com>
Hi John,
I wrote about my experience with Physical Compiler (PhysOpt) just over a
year ago (2/23/00), and I thought that I'd let you know how things have
progressed since then.
I am now at Hyperchip in Montreal, and we used Physical Compiler on a design
we called "The Matrix", which is an intelligent switch and will be used in
our petabit router system (which, by the way, will be a kick-ass system!)
:-) Some key points of the design are:
- IBM ASIC flow with placement handoff
- 0.18um SA27E technology
- 16.6mm x 16.6mm die
- 155MHz clock
- 4.3M gates
- 3M bits of memory
Most of the aspects of Physical Compiler that are important to me have
remained the same since I am still seeing good results without having to
provide much placement guidance to the tool. No detailed floorplanning is
necessary, and I ran it on fairly large blocks (250k gates + RAMs).
The IBM floorplanner supported a hierarchical flow, so we took advantage of
that since the design consisted of 16 identical hierarchical blocks.
First, we ran Physical Compiler on one of the 16 blocks and closed timing on
it. To help with this, we made sure that the inputs and outputs of the
block were flopped. Also, to help with top level routability, we only
permitted the blocks to use 3 layers of metal. PhysOpt was placing the
input/output pin flops far from the pins within the modules, creating timing
and max cap problems when integrated at the top level. A TCL script was
used to place the flops at the pins to get around this. A net weight
attribute within PhysOpt probably could have helped with this.
Physical Compiler completed on the block in about 15-20hrs, and the block
met the target timing specs and was routable in 3 layers of metal.
After completing the placement of the block we ran the tool at the top
level. We generated both physical and timing models of the block -- the
physical LEF model with a script that converted the the IBM floorplan
netlist, and the timing model from PrimeTime (stamp model). During the top
level run, the blocks were considered as black-boxes and the rest of the
design between the blocks and the I/O's was optimized. Physical Compiler
handled the top level buffering quite well, even over a 16.6mm x 16.6mm die.
PhysOpt did have some difficulty with the logic near the main I/O's -- so we
grouped those with regions. PhysOpt still took the liberty of placing them
far outside the designated areas since it only considers regions as soft
boundaries, but it was much better than without the regions. Those areas
were meeting timing, but presented some trouble for clocking since they
spanned a much larger area than anticipated. According to Synopsys, this
should be resolved by using 'set_congestion_options -max_util', which I have
not yet tested.
In order to keep top-level run-time reasonable, 'create_placement' and then
'physopt -inc' was run, which was all that was really necessary in order to
meet the requirements of this design. PhysOpt took about 24 hours to run
at the top-level.
In order to save time when running on a new netlist, both the block-level
and top-level placement/physopt runs were executed at the same time. The
top-level placement used the same timing model as previous runs since
PhysOpt was consistant in meeting timing requirements for the block.
Running these in parallel resulted in a 24 hour turnaround time from new
netlist to a full chip placement that was meeting timing.
We used an IBM ASIC flow with placement handoff, and were able to meet all
the IBM requirements for release to layout (RTL). RTL is the last
checkpoint before sending the design to IBM for all the "fun" chip
finishing stuff including scan chain optimization, clock tree insertion,
detailed routing, etc. There was some optimization that was required at
IBM to meet timing and max-transition violations, but all that was
manageable.
Overall, we were able to use PhysOpt to quickly turn a new netlist into a
placement that would meet the IBM requirements. In the beginning, it did
take several iterations of finding the best method and constraints in which
to run PhysOpt, but once that was settled we were able to reliably place
the design in a short amount of time.
- David Romanauskas
Hyperchip Inc. Montreal, Quebec
( ESNUG 366 Item 3 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #10 ) Twelve More Synopsys ACS 1999.10/2000.05 Bugs
> In the interests of sharing results, here's a table of ACS/Budgeting
> related STARs Mario and I submitted for ACS:
>
> STAR Num Description Fixed?
> 113984 budget_shell crashes on my design N
> 109279 timing exception on a block caused
> that block to not be compiled due to
> dont_touch Y
> 105427 budget_shell crashes on my design N
> 105055 set_dont_touch_network sets dont_touch
> on all combinatorial fanout of that net N
> 104882 set_critical_range constraint not
> propagated further than pass0 N
>
> Thanks a lot guys!
>
> - Tom Fairbairn
> 3Com Europe Ltd Hemel Hempstead, England
From: "Vi Anh Nguyen" <vanguyen@broadcom.com>
Hi John,
I documented a list of ACS problems I encountered while using 1999.10-4 ACS.
I since used 2000.05-2 ACS. Some problems haven't been fixed. I list ACS
defects & limitations I found in those versions.
1999.10-4 ACS defects:
- ACS should have defaulted allocate_budgets' level to the same
set_compile_partitions' level, if the later existed. According to
Design Budgeting UG p.3-9, budgeting all levels of hier can lead
to a large number of *.con files generated by write_context. Provide
a value to limit file generation to the blocks to be syn'ed.
In the pass1/scripts/top.btcl:
source scripts/pass1/budget.scr
set cell_list [get_cell * -hier -filter "is_hierarchical == true"]
foreach_in_collection instance $cell_list {
set inst_name [get_attribute -class cell $instance full_name]
set inst_ref_name [get_attribute -class cell $instance ref_name]
echo "processing cell $inst_name"
set out_file_name [format "%s.%s" $inst_ref_name con]
write_context $instance -format dcsh -output
pass1/constraints/$out_file_name
}
The "is_hierarchical == true" should be changed to "is_partition == true"
This one was fixed in 2000.05-2
- If DEPTH < 1, ACS set DEPTH to 1 when generating Makefile. ACS needs to
allow DEPTH=0 for top-down compile.
- set acs_work_dir ./subdir
create_pass_directories passdir
This should put the passdir directory in the ./subdir. But instead it
creates it in the cwd.
- The following infos were not transfered from .synopsys_dc.setup by ACS to
pass#/scripts/env for dc_shell:
SS_SC_LIB for "set_min_library SS_SC_LIB -min_version FF_SC_LIB"
"PROJ = get_unix_variable("PROJ")". (This one has to be passed via
MAKEFLAGS)
auto-export to dc_shell.
set_ultra_optimization
aliases
define_design_lib
set_dont_use
set_implementation
Also, the .synopsys_dc.setup for ACS is not readable by dc_shell. The
tool should designate separate setup files for ACS (dc_shell-t) and
dc_shell.
- The *.btcl could not open long-named files and Apollo could not handle
long-named instance. The hdl_naming_threshold didn't work as this
variable takes effect only when there is at least one non-integer
parameter. I used the followings which limit the design name length:
template_naming_style = "%s_%p"
template_parameter_style = "%d"
template_separator_style = ""
- I used "operating_parameters" which was defined as
alias operating_parameters \
" \
set_operating_conditions -max_library SS_SC_COMB_NAME \
-max "WCIND" \
-min_library FF_SC_COMB_NAME \
-min "BCIND"; \
\
set_max_transition 0.8 current_design; \
set_max_transition 0.8 all_outputs(); \
set_critical_range 0.5 current_design; \
"
Which was later used in the default.compile. Later I got an error in
pass1/logs/iline20.btcl.out during the budgeting step:
Loading db file
'/projects/bcm4710/work/vanguyen/iline20/synth/acs/acs_dbase/
pass0/db/post_compile/mult_tc10x8_1.db'
Error: Cannot find operating condition 'BCIND' in library 'tsmc18'.
(DES-008)
Information: Previous messages occurred while trying to do:
'set_operating_conditions -library
[get_libs * -filter "full_name == tsmc18_1.db ||
full_name == tsmc18_1 || extended_name =~ */tsmc18_1.db:*"]
-min {BCIND} -max {WCIND}'. (LNK-021)
Evidently, the tsmc18ff_1.db defined in the FF_SC_COMB_NAME var was not
used in the full_name above.
This Error prevented the pass1/Makefile from being generated.
- The top-level design should be written out both flat and hierarchically.
Currently the top-level design is written out flat. This would
facilitate a final non-ACS compile required in 2-pass syn to perform
insert_san for scan replacement and routing.
Since dont_touch was set on all subdesigns and cells in the
pass1/scripts/top.autoscr when reading in
pass1/db/post_compile/, before writing out the top-level
design hierarchically ACS needs to:
set_dont_touch find(design -hier, "*") false
set_dont_touch find(cell -hier, "*") false
Furthermore, pass0/constraints/top.con needs to be reapplied to iline20
in the final non-ACS compile as DC complains that timing info on clocks
is lost.
- pass1/constraints/top.con has invalid commands:
set_dont_touch find(reference "BRF64X32AR1")
causing the error:
Warning: Can't find reference 'BRF64X32AR1' in design 'iline20'.
(UID-95)
Error: Design object list required for the '' argument.
(EQN-19)
Usage: set_dont_touch
(list of objects not to be modified)
flag (used to set true or false -- default is true)
The above cells are either std cells or custom macro cells.
- Duplicate command lines in pass1/scripts/top.autoscr:
include pass1/constraints/iline20.con
/**************Begin error-check***********************/
check_error -v
if (dc_shell_status == 1) {
exit 1
}
/**************End error-check***********************/
/**************Begin error-check***********************/
check_error -v
if (dc_shell_status == 1) {
exit 1
}
/**************End error-check***********************/
/******************************************************
Created by Tcl procedure acs_write_strategy -partition iline20
-pass 1 -level incr -format dcsh
******************************************************/
- Redundant subdesigns were read in pass1/scripts/iline20.autoscr resulting
in:
Warning: Design 'dpram19x10.db:dpram19x10_DW01_mux_any_190_5_10_0'
comes before design
'dpram19x10_DW01_mux_any_190_5_10_0.db:dpram19x10_DW01_mux_any_190_5_10_0'
in the link_library;
'dpram19x10_DW01_mux_any_190_5_10_0.db:dpram19x10_DW01_mux_any_190_5_10_0'
will be ignored.
2000.05 ACS defects:
- 2000.05 ACS creates pass0 dir in the wrong dir
set acs_work_dir ./subdir
create_pass_directories passdir
(This should put the passdir directory in the acs_work_dir. But instead
it creates it in cwd.)
2000.05-2 ACS defect:
- .compile was used in the generated pass#n/Makefile despite
the fact that only default.compile was created by users for
scripts/pas#n.
I hope this list of known bugs helps other ACS users, John.
- Vi Anh Nguyen
Broadcom
( ESNUG 366 Item 4 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #2 ) User Having Trouble Closing Timing Using PKS
> Our dual PhysOpt/PKS tape-out was done because we ran into some run-time
> issues with PKS on that core. It was taking 6 days to compile and we
> couldn't get any debug/improvement cycles in. The PhysOpt run took about
> 1 day but had about 10% larger area. So, I used Ambit to get an initial
> netlist with the area savings and PhysOpt to get a placement. I then
> returned to PKS after our internal scan insertion tool and clock tree
> generation to do the final timing tweaks. This allowed me to use the SE
> compatible global router in PKS, do incremental optimization based on that
> global route, and get less than 2% difference in pre- and post- final
> route timing in SE. With a PhysOpt placement, we see 5-10% difference in
> pre- and post- route timing.
>
> - Jay McDougal
> Agilent Corvallis, OR
From: Mark Warren" <mwarren@xtremespectrum.com>
John,
I'm having a heckuva time closing timing using PKS. Has anyone had any
experience with these?
1. I optimize and timing report looks good. I write out a netlist,
DEF, and ADB. I close the tool and read in the netlist, DEF, and
my constraints. Now the timing is no longer good -all I did was
write it out and read it back in. But, wait, there's more. I then
try reading in the ADB and it doesn't match either timing reports
from the original run, or the reread of the netlist. What's happening
here? My setup is the same for all three runs - same script. I'm
running version 4.0-s5 of PKS. The Cadence AE tried to tell me I
changed my setup variables for each of the runs. So, I ran through
as many combinations of steiner_mode, slew_propagation_mode, etc
that I could think of and I never got a timing report that matched
the first good one.
2. The Silicon Ensemble Crosstalk fixer. This is another cool tool to
try to fit into a flow. Any advice?
Thanks.
- Mark Warren
XtremeSpectrum, Inc. Vienna, VA
( ESNUG 366 Item 5 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #1 ) PhysOpt Troubles & Avanti Discouraging PDEF 3.0
> We are running into the same PDEF 3.0 for PhysOpt problem Bob reported back
> in March 2000 (11 months ago!) Wouldn't you think Avanti would have fixed
> this by now?! Could anyone who has them please send us the Scheme scripts
> used to process the Avanti PDEF 2.0 files for PhysOpt?
>
> - Andy Pagones
> Motorola Labs/CSTL Illinois
From: [ The Truth Is Out There ]
John, first off, thank you for all the work you put into ESNUG.
I'm not suprised that Avanti's R&D hasn't fixed problems with PDEF 3.0.
My sources at Avanti has told me that Avanti's R&D stand is to encourage
flows using PDEF 2.0 and discourage flows using PDEF 3.0.
Please keep my response anonymous.
- [ The Truth Is Out There ]
---- ---- ---- ---- ---- ---- ----
From: Kevin Grotjohn <krag@lsil.com>
John,
All of these PDEF X.0 versions that are not properly interfaced between
vendors have a solution. IEEE 1481 includes a section that clearly
specifies the syntax, semantics, and examples for the standard
planning/placement interface that supersedes earlier versions. The same
standard also covers SPEF which is commonly used for parasitics between
these tools, as well as DCL for standard timing engines.
Maybe the EDA vendors make more money from script consulting services to
interface tools, or selling integrated single vendor flows. It does cost
money to upgrade parsers/writers after all, and what would us designers do
if we had tools that interfaced cleanly? Maybe EDA vendors fear designers
will discover new features of the interfaces and demand tool support for
them?
- Kevin Grotjohn
LSI Logic
( ESNUG 366 Item 6 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #11 ) PrimeTime With Real & Falsely Monotonic Libs
> 1. You do need the cell delays to be monotonically increasing with output
> capacitance. This is I belive, quite a realistic requirement. If for
> some reason your library is not monotonic with increasing load, then I
> think its a library problem.
>
> - [ One Of The Lessor Pokemon ]
From: Keith Howick <howick@siliconmetrics.com>
John,
I was glad to see that many people agreed with Ajay's complaint, but was
disappointed to see the belief that cell delays must be monotonically
increasing with time. In my own experience characterizing hundreds of cell
libraries I've seen several with cells that exhibit real non-monotonic
behavior (and many more that exhibit false non-monotonic behavior). Though
uncommon, real behavior is usually a result of:
(1) Slew-control circuitry. This is most often the case for I/O cells,
but sometimes appears unintentionally in high-drive internal cells
because of how the cell was designed or extracted. If large output
transistors are broken apart and placed in parallel with some parasitic
resistance between them, a basic slew-control circuit is created.
Resistance isn't regularly extracted today, but it's becoming more
popular as frequency increases.
(2) Miller capacitance between complimentary output pins (e.g., Q and
QB on a flip-flop). How a secondary output is loaded can have a
dramatic affect on the delay behavior of the primary pin-under-test.
This is especially true if a large single-stage inverter separates the
pins. Though the value of capacitance seen through the miller effect is
constant vs. slew when measuring through a complete state transition,
the plot of current used to charge and discharge the miller capacitance
is not. This has a non-monotonic affect on the circuit's delay as
output load changes the output slew.
(3) Finally, and very rarely, if a small cell is characterized across a
large enough sweep of slew it can appear like a band-pass filter, and a
"duck-tail" appears at the very end of both the slew and load sweeps.
This is very rare as most people aren't interested in the very long
slews required to see it, but it crops up from time to time. Though
I've never taken the time to fully investigate the phenomena, I do know
from experimentation that the effect is sensitive to imbalances between
N and PMOS drive strengths and the hysteresis caused by disparate totem
thresholds.
However, what's the #1 reason for non-monotonic delay behavior across load?
Simulator Accuracy! I've too often met library developers that try to
meet unrealistic library development schedules by dialing-back the
accuracy of their characterizing simulations. Nothing will cause
non-monotonic behavior faster than this, and the behavior often looks
quite random. It's unfortunate that many managers consider library
development to be of small importance and require it to complete
rapidly, even though it's usually the some of the most leveragable time
spent in any design's development.
I agree that non-monotonic behavior is undesirable, but it nevertheless exists.
Ridding a library of it requires giving in to one or more truths of library
development. Developers and users must:
* increase simulator accuracy
* reduce the range of load and slew sweeps
* pay close attention to how cells are designed and extracted
* and know which cells will exhibit non-monotonic behavior anyway.
Thanks for your efforts with ESNUG, John! I enjoy the list immensely.
- Keith Howick, Sr. Methodology Engineer
Silicon Metrics Corp.
---- ---- ---- ---- ---- ---- ----
> A cell's library data is created by simulating the cell with a set of
> different output capacitances. If this output capacitance is increased,
> then it will take more time to charge up, and the delay and slew times
> will both increase as well. This sensitivity to output capacitance is
> used by PrimeTime to set the drive resistance in its driver models used
> in RC delay calculation. Therefore, PrimeTime uses this physics rule
> and requires that delay and slew in the cell's library data to both
> increase as output capacitance increases. A violation of this rule
> in the library data prevents PrimeTime from creating a driver model
> since the drive resistance will not be positive. A failure to create
> a driver model subsequently prevents any calculation of C_effective.
>
> - [ PrimeTime Tech Support ]
From: [ The Librarian ]
Johm - keep me anonymous, please. Just call me "The Librarian."
Delay and slew times will not always increase with capacitance; if the
capacitance is low enough and the input ramp large enough, you get the DC
transfer curve you remember from your undergrad days. The output waveform
depends only on the input ramp.
In theory your characterized cell would show the same ramp time for a range
of increasing capacitance here, but SPICE gets in the way. For the same
circuit, the same input ramp time, the same output load, but slightly
different characterization parameters, you will get delay and ramp variance
of about 0.5% just due to "numerical noise" in SPICE. This error can be
reduced but not totally eliminated by using a smaller TSTEP, but of course
that makes characterization take much longer.
If you have SPICE (and device models) available, measure the delay and ramp
of an inverter or buffer with a fixed load and input ramp as TSTEP
changes. Better yet, measure them when your input ramp starts at 1.01 *
TSTEP, 1.02 * TSTEP, etc. (don't laugh; I've seen SPICE decks that change
in the middle of a TSTEP increment). The results will surprise you as much
as they surprised me when I was trying to correlate SPICE to libraries.
Operating in the region where output ramp time does not depend on output
load is inefficient (lots of crowbar current) but not all library vendors
assign operating condition limits on a cell-by-cell basis. Thus there may
be cells operating in these odd corners and the 0.5% numerical error will
bite you.
If the no-dependency-on-output-load pops up outside the low-load, high-ramp
corner, the library probably has a problem. But in this corner, the
"negative drive resistance" is probably SPICE noise and you probably want
PrimeTime to assume a fixed delay within that narrow load range.
- [ The Librarian ]
( ESNUG 366 Item 7 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #14 ) Non-Error "Errors", DC/PT Tcl Nasties & ACS
> I would suggest:
>
> if [llength [get_ports Reset]] {
> set_output_delay 5 -clock clk [get_ports Reset]
> }
>
> If the port exists the get_ports command returns a collection handle which
> has llength of 1. If the port does not exist the get_ports command returns
> an empty string which has an llength of zero.
>
> This avoids the SEL-005 error and gets only a UID-95 warning that can be
> suppressed with the suppress_message command.
>
> - Henry George Berkley
> Electronic Consulting Santa Cruz, CA
From: Steve Golson <sgolson@trilobyte.com>
John, even better is
if [llength [get_ports -filter {@full_name==reset}]] {
set_output_delay 5 -clock clk [get_ports reset]
}
which gives no messages at all, not even the UID-95 warning.
Note that the {*} argument to get_ports is implied; you don't need to add it.
- Steve Golson
Trilobyte Systems
( ESNUG 366 Item 8 ) --------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #5 ) DesignSync A Poor Replacement For Cadence TDM
> The ONLY thing that the company has to its advantage is that it is the
> only company offering an interface between Cadence tools and its version
> control software. Synchronicity now owns the GDM interface of Cadence,
> so it might retain its monopoly.
>
> One telling thing: The company did not use its own version control
> software during development of version 1 and 2 -- they used CVS. It
> wasn't until management forced the company to use its own tool did they
> start fixing things in version 3.
>
> After much toil and turmoil with the tool, we decided to scrap the whole
> thing and write our own interface for Cadence based on Perforce. We also
> considered using CVS or even just UNIX tar/cp nightly.
>
> - [ Elvis of Graceland ]
From: Adam Krolnik <krolnik@lsil.com>
John,
Our group reviewed Synchronicity DesignSync at the conceptual level;
comparing it to our existing system and Cadence's tool TDM (Team Design
Manager.)
DesignSync was very expensive for the featureset that it presented. Even
Clearcase wasn't this expensive. People who buy DesignSync had better be
getting a very good discount. There are tools out there with equivalent
functionality and much lower pricing.
DesignSync provided basics, but no structuring around them to ease the use
of the tools as a whole. We were trying to compare DesignSync to the
Cadence TDM tool flow (since Cadence recommended them as the replacement.)
They weren't even close - DesignSync had fewer features than TDM.
DesignSync did not have anything resembling the TDM work/integration/release
cycle. They did not work well in a checkout/checkin/submit and repeat
environment common to RTL design work. DesignSync did not go beyond TDM
with features that were necessary -- removal of files from future releases
(not removal from the database.)
Be wary when you have to purchase an expensive tool and then write a large
framework to implement the process you desire because the tool vendor says,
'we can't implement everyone's process'. They should be providing
sample/example processes for using the tool.
I'm still searching for a good SCM tool.
- Adam Krolnik
LSI Logic Plano, TX
( ESNUG 366 Item 9 ) --------------------------------------------- [02/23/01]
From: "Gregg Lahti" <gregg.d.lahti@intel.com>
Subject: Undocumented DC Varible For VHDL'87 & VHDL'93 Incompatibilities
Hi, John,
Somewhere between 1998.08 and 2000.05, DC changed its method of reading
VHDL. I got bit by this when I was pulling in some legacy VHDL code that
synthesized fine in 1998.08 that used the following constaint declaration:
constant nc1 : std_logic_vector(3 downto 0) := to_stdlogicvector(X"01");
In 2000.05, DC would error reading in the VHDL on the line above with an
"expression is ambiguous" message. Turns out, that DC 2000.05 and higher
revs by default read in VHDL '93. An undocumented variable "hdlin_vhdl_87"
is required to be set to true for the above code to work:
set hdlin_vhdl_87 true ;# Tcl mode, '87 compatible read
or
hdlin_vhdl_87 = true # DCSH mode
Initially, Synopsys Support offered up the '93 compatible code workaround.
To be 2000.05 & VHDL '93 compatible, the X"01" needs type coersion to a
bit_vector type. The following code works if you're in the default '93
mode in 2000.05:
constant nc1 :
std_logic_vector(3 downto 0) := to_stdlogicvector(bit_vector'(X"01"));
Note that the hdlin_vhdl_87 doesn't exist. A "info vars hdlin*" or the
standard help commands didn't show it. Nowhere in SOLVNET or the DC docs
was this documented and it took about a month to get this resolved by
Synopsys support after I complained that it worked fine in prev versions
(so much for reuse, right?). Of course, by the second day of this problem
I wound up converting all 200+ of my constant declarations into a hard
std_logic_vector value to get my synth job done. :^(
Somewhere, Cliff Cummings is laughing at the hoops we VHDL users go
through...
- Gregg Lahti
Intel Corp
( ESNUG 366 Item 10 ) -------------------------------------------- [02/23/01]
From: Lars Rzymianowicz <larsrzy@ti.uni-mannheim.de>
Subject: We're Having Some Troubles With The Synopsys DWPCI v3.4b Core ...
Dear John,
First of all, thanks for running ESNUG! Every new post makes my day. ;-)
We just plugged in the Synopsys DWPCI v3.4b core into our design.
Everything's fine, with one exception: in the PCI Config Header, the first
16 words are device independent (command, status, BAR regs, etc.) We can
read/write them in the simulation via PCI config cycles. Fine. After these
regs, there is space for up to 48 user device-dependent registers, starting
at adr x40. Via the parameter 'cfg_num_dev_regs' (device-specific
registers) you can define, how many regs you would like to use. We set it
to 4, and we verified, that these regs show up in the generated netlist.
But we can't write these regs via PCI config Cylces. All following reads
return 0.
We analyzed the netlist (we only have encrypted sources, so we have to load
the netlist into Design Analyzer and look at the gates) and found out, that
the 'enable' of those config DFFs can never be true! Its fanin logic is
sth like 'A and NOT_A and ...' We observed all interface signals to the
config module, and they match the signals from the manual (dwpci.pdf, Sec
5-31ff, Accessing Configuration Space Registers). So the question now is:
is there any parameter, which blocks write access from the PCI side to these
regs? Is this a bug? Or what?
We'd appreciate any help from other DWPCI users!
- Lars Rzymianowicz
University of Mannheim Mannheim, Germany
( ESNUG 366 Item 11 ) -------------------------------------------- [02/23/01]
From: Maynard Hammond <maynard@subasic.sciatl.com>
Subject: Customer Tells What It's Like To Use Module Compiler With PhysOpt
John,
Thought I would let you know about my experience using Physical Compiler in
conjuction Module Compiler. I am an engineer with Scientific-Atlanta. We
build set-top boxes for cable companies. One of our ASICs has a CPU in it.
Our goal has been to get this to run as fast as possible. This has not been
easy.
In our previous flow, I went through numerous iterations of dc_shell,
Primetime, rewriting source code and extracting key data path and coding it
in Module Compiler. Over several months I had a system that still didn't
meet timing goals. I wrote code to take Module Compiler's .layout and a
.lef to placed cells. My counterpart at the foundry spent 3 months hand
placing cells and routing to get the design closer to specs. When all was
said and done, we had increased the CPUs speed from what dc_shell alone
and push-button routing produced to a design that was 37% faster. This was
good but still didn't meet our specifications.
Several months ago, we started working with Synopsys and their physical
tools. Synopsys provided great support. I had multiple FAEs to help me
when problems appeared -- and they did! I went through several versions of
code. Initially, I wasn't able to read in the raw Verilog or Module
Compiler code and go to placed gates. I had problems with Module Compiler
datapath. With their 2000.11 release, these issues have been resolved.
Today I am able to go from RTL to placed gates in less than 24 hours. My
design is 67% faster than dc_shell alone and push-button routing produced.
You can view the datapath in the design! It works great!
It did take effort to get the scripts working right, though. I found out
the hard way that you can't diverge from the flow shown in the Synopsys
Physical Compiler User Guide. Initially, my flow was different (I had to
work around several bugs in the beta code). Once I transitioned to their
suggested flow, it all worked. I was forced to move our scripts to Tcl.
(Something I needed to do for a long time). I found that if I grouped the
adders, shifters, muxes, etc., from the data path in separate groups,
PhysOpt was able to produce better results. I did this by using the "rpgen"
and "group" directives. Connecting up the scan chains has also given me
some headaches. Again, following the flow specified in the Users Guide is
key. My flow is:
* read in .mcl modules.
* compile with scan ( dp_keepscan +, dp_scanmode +, dp_physical +)
* dont_touch .mcl blocks
* read in Verilog modules
* apply constraints, ungroup, etc.
* compile -scan
* remove dont_touch from .mcl blocks
* setup scan parameters
* read in physical layout
* physopt -scan_order
* physopt -inc (Physopt -scan_order, doesn't buffer scan chains as
needed)
With a 1 day turn-around, I was able to try many different "layouts" and
find what worked best. When I submit placed designs to the foundry, they
are able to quickly insert clock trees, route and extract timing. My timing
numbers from PhysOpt have always been within 3% of the extracted timing
numbers from the foundry. We will be taping out our CPU in the next couple
of months.
- Maynard Hammond
Scientific-Atlanta Inc. Lawrenceville, GA
( ESNUG 366 Item 12 ) -------------------------------------------- [02/23/01]
Subject: ( ESNUG 365 #8 ) Superlog, Verisity E-lite, and Avery VCK
> I must admit that I agree with Janick's point of view regarding Superlog.
> Superlog provides nice features like re-entrant tasks, which opens the
> door to powerful constructs like recursion and concurent calls, but fails
> to take the verification effort beyond the current dead-end path of
> Verilog: lack of OO, lack of proper random generators, lack of temporal
> checking and lack of functional coverage specification description to
> name a few. The problem with Verilog is its simplistic linear procedural
> nature.
>
> - Martin d'Anjou
> Nortel Networks
From: David Duxstad <dduxstad@mn.rr.com>
John,
Martin d'Anjou's posting (ESNUG 365 #8) on Superlog vs. E-lite was a good
read. While I agree that less lines of code is a critical factor, E-lite
isn't the only way to achieve that goal. Lately, I've been working with
VCK from Avery Design Systems. It has most all the features that are
"missing" from Superlog and is based on Verilog. It adds extensions to
Verilog (called VLE) that support robust random number generators, lists,
temporal checking, functional and code coverage functions, and records.
Since the syntax for these extensions in VCK is based on Verilog, there
is no need to learn another language. Avery plans to propose these
extensions to OVI in the near future, so they will not be proprietary.
d'Anjou presents a simple expect function that is coded in a few lines.
The function is to detect a change in "y" from n1 to n2 cycles after a
change in "x". Here's that same expect function in VCK:
initial
begin
e_handle = $expect( value_change(y),,go_fail(n1,n2), n1:n2,posedge clock);
end
always @(x) $expect_trigger(e_handle);
task go_fail;
input n1,n2;
integer n1,n2;
$display("Check failed: y did not occur within %d to %d cycles after x",
n1,n2);
endtask
task value_change;
input my_input;
@(my_input);
endtask
And while the use of tasks in the $expect() function may make this code
slightly more wordy than the E-lite example, the code is just as powerful,
if not more powerful, and easier to read. And, it was all done in Verilog.
Additionally, Avery has created a cool C/C++ API that allows you to write
much of your verification code in a higher level language that is very well
supported by the open software folks. I use GNU gcc and DDD on Linux for
my C coding and debug and it works very well.
The verification code that I've been working on makes extensive use of what
they call the VCI channel. With this VCI channel, communication between
the C process and Verilog is done over a TCP-IP link. This allows me to
run the C process on a separate machine, freeing up CPU resources for the
Verilog simulation. Alternatively, you can used a shared memory scheme
on the same machine if you like, it just depends on the simulation
environment you are trying to set up.
I'm a big believer in standards and non-proprietary languages and I think
those are essential for IP/SOC designs coming our way. Verification of
SOCs is difficult enough without the added complexity caused by the
introduction of proprietary languages.
- David Duxstad
Duxstad Consulting
---- ---- ---- ---- ---- ---- ----
From: [ Roger Rabbit ]
John,
Keep this anonymous. I don't want Verisity people calling me any more.
A while ago I was involved in the evaluation of Specman for a project. It
seemed to be right down the tools alley. I had written a PERL script that
generated address and data for a processor BFM using random rule sets.
This generated a Verilog task call sequence and the BFM would execute this.
It was self checking, as you could write rules for register and memory
accesses. This took a little more than a day to write and it was very
extensible. Verisity wanted to demonstrate their power, so I gave them the
PERL and a overview of the driver. It took better than a week to get the
code.
Now, this doesn't mean that the person writing the code took a week, or
perhaps he didn't understand the concepts, although this was in the same
class of operations as their demo was. The time from when I gave them
the task to when the completed the task was over a week.
Needless to say, I haven't been a huge fan of Specman, it works, we have
groups here that use it on designs, most using contractors to code the "e".
I find "e" to be very different from Verilog and even VHDL which produces
a large learning curve. I had great hopes for Superlog, it is an extension
of the Verilog language which makes learning it additive, but it seems that
some people are finding holes in the language. I have three questions for
the general population and perhaps this would be of interest to others.
1. Is Specman the state of the art, can Superlog measure up, is neither
the answer?
2. Is this the rebirth of the "Verilog is better, no VHDL is better" wars?
3. Has anyone heard of, or tried the PERL linkage tool from NelSim
http://www.nelsim.com/ ?
We can do some interesting things with PERL right now and extending that
would be great.
- [ Roger Rabbit ]
( ESNUG 366 Item 13 ) -------------------------------------------- [02/23/01]
From: Ton van Hekezen <tvhekezen@lucent.com>
Subject: How To Use The 'wget' FTP Program For Large Synopsys Downloads
Hi, John,
Synopsys promotes 'wget' on their web site for ftp-ing large downloads, such
as for the new Design Compiler/TestCompiler/PrimeTime release:
http://www.synopsys.com/support/est_wget.html
However, they don't tell you everything you need to get it working.
The 'wget' program is a GNU command line utility to download large files
using ftp. It can only do batches downloading of files. The main advantage
of wget is that when the connection get lost before the file has been
transmitted, wget tries again without having to retransmit the part that
has already been received. Looking at the current internet situation in
Europe, that is more than nice-to-have for downloads larger than 30 MB.
The command line syntax is
wget ftp://user:password@ftp.synopsys.com/path/file
However, my Solvnet username is my email address so it contains an '@',
which conflicts fundamentally with the '@' between password and hostname.
This would make wget unusable for downloading most of the stuff, as most
of it is (Solvnet-)password protected!!
A new version of wget will probably 'fix' this problem, however, in the
meantime, use this trick: replace the '@' in your email address by %40.
Of course, the same applies to an '@' in your password. For instance,
suppose my Solvnet username is ton@someco.com, my password is secret,
then a wget command could be:
wget ftp://ton%40someco.com:secret@ftp.synopsys.com/path/to/file.tar.gz
I emailed this to Synopsys, but it took them long (at least more than a week)
to add this to their website. ;-(
In addition, note that for most company networks, you'd probably need to set
the proxy in the ~/.wgetrc file, something like:
use_proxy = on
http_proxy = http://proxy.somecompany.com:8000/
no_proxy = .somecompany.com
My few eurocents,
- Ton van Hekezen
Lucent Huizen, the Netherlands
============================================================================
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
|
|
