EDITOR'S NOTE: Well, I'm happy to say that normal ESNUG is now back after
that 6 week hiatus caused by DAC (and the writing that massive DAC Trip
Report... ugh!) I did get some funny stories after publishing that report
on DeepChip.com, tho. In the report I had written a nice long rant about
the absolute importance of tape-outs for the new EDA tools. I also wrote
a separate rant about how "I'm used to EDA marketeers lying to my face,
but the Cadence guys do it so unabashedly, it's insulting. Do you guys
have secret bets on who can get away with the biggest, most ridiculus lie
you can pitch to a customer???". On the Friday when I put the report up
on DeepChip.com here on the *East Coast*, I phoned Vik Chaudhary (the
Cadence NANO marketing manager) to see if *West Coast* Cadence could get
the report up on their browsers. (The report was so big there was a
question if it would have problems going that far over the Internet.)
Sure enough, within 2 minutes, Vik was telling me "You know, John, I
should really talk to you about how unimportant tape-outs are..."
- John Cooley
the ESNUG guy
P.S. Check out http://www.EEdesign.com -- Goering snagged a customer
interview on that funky new "symbolic simulation" stuff from InnoLogic.
P.P.S. And thanks, guys, for answering my 3 way career question from last
week (of should I do more synth/Verilog -or- backend -or- Vera/Specman.)
( ESNUG 355 Subjects ) ------------------------------------------- [7/26/00]
Item 1 : Customers Not Happy With Cadence Tech Support & New Install System
Item 2 : Synchronizers To Deal With Timing Problems Within Reset Trees
Item 3 : ( ESNUG 331 #6 ) How Does Equivalence Checking Handle Scan FF's?
Item 4 : ( ESNUG 344 #9 345 #11 ) Issues Running TCL In Design Analyzer
Item 5 : ( DAC 00 #46 ) The Anon User On Parasitic Extraction Out-To-Lunch
Item 6 : ( DAC 00 #1 ) Yes, But Xilinx Bought LavaLogic For $2 Million...
Item 7 : ( DAC 00 #12 ) Stu Pissed At Cooley; Stu On C/Superlog/PLI/VCS
Item 8 : Seeking User's Good Experiences/Horror Stories With DW_ECC Block
Item 9 : Multiple Clocks -- Need Help Doing RTL MUXing For Scan Testing
Item 10 : ( DAC 00 #43 ) Correcting How CadMOS' CeltIC Tool Does It's Job
Item 11 : How Can I Restrict Libs In DC To Specific Blocks In My Design?
Item 12 : ( ESNUG 351 #9 ) InterHDL's Verilint vs. Avanti's Novas Pricing
Item 13 : ( ESNUG 82 #2 ) How Do I Handle Opposite-Input Tri-states In DC?
Item 14 : Problems With "Find" To Find The Driving Cell Of A Specific Net
Item 15 : ( ESNUG 348 #8 351 #5 ) Synopsys DesignPower & Cadence NC-Verilog
Item 16 : ( ESNUG 350 #10 ) "Mystery" Book On Behavorial Synthesis Returns
Item 17 : How Do You Convert Xilinx Gates To ASIC Gates? Favorite Ratio?
Item 18 : Three Very Cheap/Free/Shareware GDS-II Viewers for Windows95/98/NT
Item 19 : ( ESNUG 346 #10 ) Find Number Of Instances Of Each Module In VCS
Item 20 : A Good Overview Article For Beginners On VLSI Clock Routing
Item 21 : ( ESNUG 345 #3 ) Free Realistic Cadence Silicon Ensemble Library
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 355 Item 1 ) --------------------------------------------- [7/26/00]
From: "David T. Witkowski" <david.witkowski@tropian.com>
Subject: Customers Not Happy With Cadence Tech Support & New Install System
Not sure if any of y'all have tried to use Cadence's "new and improved"
software download system yet. If not, you're in for a treat. The old
scripts/CDROM site no longer exists. I've successfully downloaded
files from the new site, but haven't figured out how to use them. It is,
shall we say, rather bizarrely implemented.
First of all, why is the tar being extracted to a hidden directory? It's
putting things into a directory './.build' which doesn't make a whole lot
of sense. Is there a reason it should be invisible?
Second of all, in the older system, there was an obvious point (./CDROM)
that Softload would reference. In this new system, there is no CDROM dir.
I tried using ./.build/install/IMAGES.DIR but Softload doesn't like this.
In the past, running SETUP.SH would launch Softload with the necessary
paths. This is no longer the case, and as mentioned the correct path is
unobvious. There's a whole assload of stuff in ./.build/install/bin.sun4v,
including of course Softload, but no "uber-script" which controls/sets
paths etc.
What are all the subdirectories under ./.build for? There's a bunch of
choice_inNNN and choice_outNNN entries, plus prodNNN. (Where NNN is some
integral number, not necessarily 3 digits.) Each of these seems to have
their own install subdirectories. Do I need to run each one, or does
Softload handle this for me?
And last but not least, why is there no documentation on this new system?
Where is the README file that explains all this?
A serious problem with the new download site is that you have no idea which
ISR you're looking at. The date/time is not part of the filename anymore.
If I download one, then go to the site a week later, how do I know if the
ISR has changed or not? There's a "timecode" file which contains a file
listing, and the line "The timecode of this IC443/sun4v ISR is 20" but what
does that mean? If I have an install, and I run "icfb -W" to get
subversions, how does that map to this "timecode"?
The old system worked fine. I'm sure they had their reasons for making the
change, but where's the transition info/doc? I'm rather honked off, to be
honest. I'm here at 11:30pm on a Sunday trying to do an ISR before the
work-week begins and I can't even get Softload to recognize the install
files. What a pain in the butt.
- David Witkowski
Tropian
---- ---- ---- ---- ---- ---- ----
> The old system worked fine. I'm sure they had their reasons for making the
> change, but where's the transition info/doc? I'm rather honked off, to be
> honest. I'm here at 11:30pm on a Sunday trying to do an ISR before the
> work-week begins and I can't even get Softload to recognize the install
> files. What a pain in the butt.
From: Gary Helbig <ghelbiggh@mailcity.com>
That was the problem. No revenue for Design Methodology Services with the
old system.
- Gary Helbig
---- ---- ---- ---- ---- ---- ----
From: "David Witkowski" <david.witkowski@tropian.com>
Well, I've asked two different AEs and neither of them seem to know how to
make the new stuff work. Weird.
- David Witkowski
Tropian
---- ---- ---- ---- ---- ---- ----
From: Gary Helbig <ghelbiggh@mailcity.com>
Truth is, they didn't know how to make the old stuff work either.
For example, if you -don't- follow the instructions, you can make a
self-installing LDV30 disk. Follow the instructions, and you have to do
the install by hand.
And their install routine requires a -seperate- "share" folder for each
product. With identical contents. HUH?????
They're running DMS (tech support to the rest of the world) as a profit
center. Changes their priorities. (See the March 19,2000 Dilbert comic
strip for a full explanation)
- Gary Helbig
---- ---- ---- ---- ---- ---- ----
From: "David Witkowski" <david.witkowski@tropian.com>
That's an annoying thing, to be sure. Depending on how I set my paths, I
get various copies of lmstat/lmdown/whatever.
- David Witkowski
Tropian
---- ---- ---- ---- ---- ---- ----
From: Gary Helbig <ghelbiggh@mailcity.com>
OH, MY, GAWD! Do -not- get me started on Cadence/flexlm issues. The
diatribe will go on for -days-.
Do yourself a favor. Trot on over to www.globetrotter.com and learn
something about flexlm.
In less than an hour, you will know more than the entire Cadence staff, and
will be able to set it up properly.
Now if only they could learn how to cut license files...
- Gary Helbig
---- ---- ---- ---- ---- ---- ----
From: "David Witkowski" <david.witkowski@tropian.com>
> Do yourself a favor. Trot on over to www.globetrotter.com and learn
> something about flexlm.
Will do.
FYI, the download system appears to be working now. However, they're still
posting the files in an odd manner. Each "cdrom" is a separate tarball, and
there's no instruction that says "put these here files into separate
directories." But if you know to untar "1of2" into ./CDROM1, etc then
you'll be fine.
- David Witkowski
Tropian
( ESNUG 355 Item 2 ) --------------------------------------------- [7/26/00]
Subject: Synchronizers To Deal With Timing Problems Within 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: johne@vcd.hp.com (John Eaton)
If you have an unfiltered async reset signal coming in a pad and going to
every flipflop in your design then you will run into trouble. As your
delays approach your clock period you become unable to bring the chip out
of reset on a known clock edge. State machines around the chip may come
out of reset on different clock edges. If your reset signal is asyncrous
to your clock, then they may not even come up in the right state.
You should filter your reset signal to ensure that transtions less than a
certain width do not propagate into your reset chain. The last thing you
want is a sub-nanosecond glitch coming in your reset pad and going to the
async reset of any flop.
You should use sync rather then async resets whenever possible. The only
difference to the flop is during the time period before the first clock
occurs. This will not effect the operation of the majority of flops in
your system. You will have a few that directly control pads that stil will
need an async reset.
Put a pulse stretcher on your reset so that your internal reset is several
cycles long. Then instead of buffering reset to every level you can resync
it using a flipflop. This will delay your reset by severl cycles but makes
it easy to ensure then every flop sees reset at the same clock.
- John Eaton
Hewlett-Packard Vancouver, Canada
( ESNUG 355 Item 3 ) --------------------------------------------- [7/26/00]
From: Lou Villarosa <louv@paradyne.com>
Subject: ( ESNUG 331 #6 ) How Does Equivalence Checking Handle Scan FF's?
Hi, John,
I was considering using formal verification. However some questions came to
mind on how it actually works.
Internal scan and boundary scan were inserted into the design using Test
Compiler. At this point is it not true that the RTL and the gate netlist
are no longer functionally equivalent? Does formal verification handle this
effectivively. Also my ASIC vendor required that the ATPG vectors and a
subset of the functional vectors be simulated at gate level using estimated
pre-route delay for min and max conditions. So I had to spent a lot of CPU
time doing simulations anyway. Is top level design verification the proper
place for formal verification?
- Lou Villarosa, Jr.
Paradyne Corporation
( ESNUG 355 Item 4 ) --------------------------------------------- [7/26/00]
Subject: ( ESNUG 344 #9 345 #11 ) Issues Running TCL In Design Analyzer
> Oh Great! We get our entire synthesis environment setup for TCL-based
> scripting (DC, PT, etc) and find out that Design Analyzer doesn't support
> TCL. This really blows chunks, considering there is no elegant way to
> automagically determine if you would like TCL or DC-flavored usage in your
> ~/.synopsys_dc.setup file. Hence any DA usage must now have a separate
> kludge to get the library paths, environment setups, etc to work! Yuck!
>
> Rumours say that Synposys is re-writing the GUI interface of Design
> Analyzer to be TCL-friendly, but that isn't available now when I need it.
> Now why can't Synopsys release tools (DA & DC) that at least work together
> in a nice fashion?
>
> - Gregg Lahti
> Intel Corp Chandler, AZ
From: [ A Synopsys CAE ]
Hi John,
I would like to respond to Gregg Lahti's post ( ESNUG 344 #9 ), concerning
the how to use Design Analyzer in a Tcl based synthesis environment.
DC has a special group of commands called the TCL subset which can be used
in the .synopsys_dc.setup files and will work for both DCSH and DCTCL. To
tell DC that the .synopsys_dc.setup contains TCL subset commands the first
character in the first column must contain a '#' character. An example:
# TCL / DCSH compatible ~/.synopsys_dc.setup file
set target_library {lsi_10k.db};
set link_library {* lsi_10k.db};
set symbol_library {lsi_10k.sdb};
This script will work for Design Analyzer in a DC-Tcl environment.
The following table summarizes the possible combinations of
.synopsys_dc.setup files in the various directories for the two dc_shell
modes (for DC-Tcl environment + DA use the last configuration):
Current Working
dc_shell Mode Synopsys Root Home Directory Directory
------------- ------------- -------------- -----------
dcsh mode Tcl-subset dcsh dcsh
dcsh mode Tcl-subset Tcl-subset dcsh
dctcl mode Tcl-subset Tcl Tcl
dcsh/dctcl mode Tcl-subset Tcl-subset Tcl-subset
More details of the TCL subset can be found in the "Design Compiler
Command-Line Interface Guide".
A New GUI for synthesis will be available later this year.
- [ A Synopsys CAE ]
---- ---- ---- ---- ---- ---- ----
From: Gregg Lahti <gregg.d.lahti@intel.com>
I jogged my memory this morning and realized my post caused me to remember
the workaround that fixes my gripe. A big, hearty, thank-you to Synposys AE
Chris Papademetrious [chrispy@synopsys.com] for recommending this fix!
I paired down his example to something that I use when going between the two
synthesis enviroments:
# Tcl-s
#
# Sample .synopsys_dc.setup file.
echo {Sourcing home .synopsys_dc.setup file}
echo {}
set company {Intel Corporation}
set designer [getenv USER]
# Also note that the source command is sensitive to the setting of
# the sh_source_uses_search_path variable.
set sh_source_uses_search_path {true}
if { [getenv {PROJ_SYN_SETUP}] != {} } {
set proj_startup_file [getenv {PROJ_SYN_SETUP}]
echo {Including project startup file } $proj_startup_file
source $proj_startup_file; ## -echo -verbose
echo {Done including} $proj_startup_file
redirect /dev/null { unset proj_startup_file }
} else {
echo {No project startup file included}
echo {Set environment variable "PROJ_SYN_SETUP" for project-wide setup}
}
# this is for personal aliases
source ~/.synopsys_aliases.tcl
Good Luck.
- Gregg Lahti
Intel Corp Chandler, AZ
( ESNUG 355 Item 5 ) --------------------------------------------- [7/26/00]
From: John Lee <jolly@avanticorp.com>
Subject: ( DAC 00 #46 ) The Anon User On Parasitic Extraction Out-To-Lunch
John -
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 I'm sure they'll laugh or cry.
But thanks for the great web site and mailer! I definitely got a lot out of
the other reviews.
For the record, our Avanti party was definitely the best, but perhaps that
is because I had 1 beer too many.
- John Lee
Avanti Fremont, CA
---- ---- ---- ---- ---- ---- ----
From: Hank Walker <walker@cs.tamu.edu>
John,
Nobody does full-chip 3-D extraction. What they do is in effect pattern
recognition and stitch together some 3-D results, maybe with parametric
tweaks. This inherently has an accuracy problem at the boundaries of
patterns. There are true 3-D capacitance extractors around now that are
100x faster than FastCap, which itself is much faster than Raphael, with
only a small error. These are not fast enough for full-chip extraction,
but certainly for cell extraction or maybe segments of a critical net or
regular array (e.g. memory).
- Hank Walker
Texas A&M University College Station, TX
( ESNUG 355 Item 6 ) --------------------------------------------- [7/26/00]
Subject: ( DAC 00 #1 ) Yes, But Xilinx Bought LavaLogic For $2 Million...
> Oh, yes, remember that talk last year of using Java as an HDL? That
> concept died this year. LavaLogic filed for bankruptcy.
From: gnippiks <gnippiks@yahoo.com>
Yes, but... http://eet.com/story/OEG20000710S0112
Xilinx buys system-level synthesis tool for FPGA suite 07/10/00
SAN MATEO, Calif. Xilinx Inc. announced it purchased the LavaLogic business
unit of TSI TelSys. Corp. (Columbia, Maryland) for $2 million in cash. The
move puts Xilinx closer to bringing FPGA design to the system level, making
it more accessible to software engineers and expanding the user base of its
programmable logic devices."
- G. Nippiks
( ESNUG 355 Item 7 ) --------------------------------------------- [7/26/00]
Subject: ( DAC 00 #12 ) Stu Pissed At Cooley; Stu On C/Superlog/PLI/VCS
> PLAYING BOTH SIDES: While there's a nest of new C-based EDA tools still
> trying to prove themselves, if you went into the Synopsys NDA suite at
> DAC you would have seen how their VCS R&D guys have crafted VCS to be
> able to read in C *without* going through the PLI. (Although bypassing
> the PLI did seem to piss off one consultant I know...)
From: Stuart Sutherland <stuart@sutherland-hdl.com>
You've put my foot in my mouth for me, John! It's not so much that you
misquoted me, but you sure changed the context! You have associated a
comment in my report on DAC-2000 with a completely different topic from
what I was commenting about. So, I claim the right to both set the record
straight, plus to say what I really think about this other topic.
The topic you inferred that I was referencing was VCS's new, not-officially-
announced C language extensions to the Verilog language. You stated
"Although bypassing the PLI did seem to piss off one consultant I know...",
followed by my comment that "In the area of PLI support, VCS is the worst
product there is."
My comment was regarding VCS's failure to be IEEE-1364 compliant, and had
nothing to with possible extensions to the Verilog language. And I standby
that comment. VCS is based on the 1990 OVI Verilog standard, and has never
been updated to the IEEE 1995 standard. With the IEEE Verilog-2000 standard
soon to be ratified, VCS is completely obsolete as far as standards are
concerned. If you want to see a Synopsys sales or marketing person do true
parallel processing, just ask them when VCS will support the 1995 IEEE
standard for the Verilog PLI. You will probably get three lies all stated
in one fork-join block: 1) "VCS is IEEE compliant." 2) "Synopsys is
working on implementing the PLI VPI routines." 3) "Nobody wants the VPI
routines, so Synopsys does not need to implement them."
Extending VCS to accept C language constructs directly in the Verilog HDL
has nothing to do with IEEE compliance. The Verilog 1364 standard has no
restrictions on a product adding proprietary extensions to the language.
And no, John, these C language extensions do not "piss me off". To the
contrary, I am in total agreement with adding more C capability to Verilog.
I wish we would have had the time to add more C constructs to the IEEE
Verilog-2000 standard. But, it takes time to add major new features to a
standard, AND make sure that the new features can be implemented in a
practical way. (Theoretically, anything can be implemented, but do we
really want something if it has negative trade-offs, such as killing
simulation or synthesis performance.) We need companies such as Synopsys
and Co-Design (with SuperLog) to prove what extensions to Verilog or VHDL
are really worthwhile before making radical changes to the actual standard.
Though adding C constructs to the Verilog HDL is a good idea, I also think
it is a very bad idea to try to replace the Verilog PLI. If replacing the
PLI is what Synopsys intends to do, then I think they are heading in the
wrong direction at a high rate of speed. There is a distinct difference in
what an INTERFACE does, versus what proprietary language EXTENSIONS do.
Verilog PLI advantages:
o A standard, portable interface. A properly written PLI application
will work with any IEEE compliant Verilog simulator, with no changes
to the code. It sure would be nice if VCS were IEEE compliant :(
o Protection to the internal simulation data structure. The PLI is a
layer between user code and the guts of the simulator, and prevents
user code from corrupting the simulator's internal data structures.
o Source code protection. PLI applications can be delivered as object
files. No Verilog or C source code needs to be provided to the end
user of a PLI application.
Verilog PLI disadvantages:
o OVI's PLI standard was poorly documented. The IEEE 1995 Verilog
standard is better, but still full of errata. These ambiguities mean
PLI applications are not as portable as they should be. For
Verilog-2000, we spent thousands of man hours making the PLI standard
as accurate as possible (I'm co-chair of the PLI standard task force).
o The PLI is slow compared to directly interacting with the simulation
data structure. That is the price of having an interface layer that
protects the data structure and gives portability. The VPI library
in the 1995 PLI standard is designed to be much faster that the older
TF and ACC libraries (too bad VCS does not support the VPI library).
Language extension advantages:
o Better performance compared to the PLI. Language extensions can
bypass the interface layer, but at the cost of no protection to the
data structure. User code can directly corrupt the simulation.
o Tight integration with Verilog HDL constructs. C constructs such as
pointers, structures and enumerated types become HDL constructs.
The PLI allows the usage of structures and such, but exchanging data
between the HDL and a C structure is only possible through the
interface layer.
o The capabilities of the HDL are still available. Time, concurrency,
design structure, digital logic values, arbitrary vector widths and
such are natural to Verilog, but are not natural to C. A PLI
application is pure C, and while it can access the Verilog information
(through the interface layer) a PLI application cannot actually model
with HDL constructs. Extending the HDL gives the best of both worlds.
Language extension disadvantages:
o Proprietary to specific products. Code which uses the extensions will
not be portable to other software products from other vendors. Even
tools such as lint checkers will need to be proprietary.
o No source code protection. The same problem that exists with HDL's
today will continue; End users must have source code to read into
simulation tools, synthesis tools, etc.
o A high risk of corrupted simulation data structures. Give a hardware
engineer pointers, pointers to pointers, addresses of pointers and
all the other levels of indirection that C permits, and there are
going to be unstable models. Add in C's memory allocation and
de-allocation, and hardware models will start having memory leaks,
illegal memory references and all sorts of other issues.
To summarize, C language extensions to Verilog are a good idea, but they do
not replace the need for a PLI. The extensions are great for performance,
abstract bus-functional level models, system level modeling, and test
benches. A procedural interface provides portability, data structure
protection and IP protection. If Synopsys is going to offer both C
language extensions and *FULL* PLI support in VCS, then they are definitely
on the right track and will have a great product. If they are
not... Well, fortunately, SuperLog IS planning to do both.
Back to my original statement, which was quoted out of context: As of
today, "In the area of PLI support, VCS is the worst product there is."
Until VCS supports the full IEEE PLI standard, I will continue to
suggest to my customers that NC-Verilog is a better choice. If C
extensions to Verilog are needed for abstract modeling or testing, then
until VCS is IEEE compliant, I will recommend looking at SuperLog.
- Stuart Sutherland
Verilog PLI consultant Tualatin, OR
( ESNUG 355 Item 8 ) --------------------------------------------- [7/26/00]
From: Brad Sonksen <sonksen@entridia.com>
Subject: Seeking User's Good Experiences/Horror Stories With DW_ECC Block
John,
I was looking into using the DW_ECC block and wanted to know if anyone has
had any comments about this module or interesting experiences with it,
either good or bad. Could you please post this question for me?
- Brad Sonksen
Entridia Corp.
( ESNUG 355 Item 9 ) --------------------------------------------- [7/26/00]
From: London Jin <jinl@taec.toshiba.com>
Subject: Multiple Clocks -- Need Help Doing RTL MUXing For Scan Testing
Hi John,
My design is a multiple clock domain design. In scan mode, however, there
is only one clock: master_clock from chip pin. In order to balance the
clocks, I need to MUX all clocks including the master_clock.
wire scan_clk = scan_mode ? master_clk : master_clk;
Design Compiler recognizes that this is feedthrough logic, and thus no
MUXing logic is generated at all. I talked to Synopsys tech support, and
was told that there was no way to generate MUXing logic with the above
code. I seeks for designers' help.
- London Jin
Toshiba San Jose, CA
( ESNUG 355 Item 10 ) -------------------------------------------- [7/26/00]
From: Jim McCanny <jim@CadMOS.COM>
Subject: ( DAC 00 #43 ) Correcting How CadMOS' CeltIC Tool Does It's Job
John, nice report.
I wanted to correct a statement made by one of your contributors:
"CadMos sells a tool that sounds a lot like the Moscape tool. It does
static noise analysis. It doesn't look for a switching signal that
slows down another switching signal, instead it looks for a switching
signal that toggles a static signal (which takes a lot more coupling
capacitance)."
The last sentence is incorrect. Our CeltIC tool look at both the impact of
noise on static signals (crosstalk effects on functionality) and the impact
on other switching signals (crosstalk effects on delay). Our CeltIC tool
will generate an incremental SDF that includes both the increase and
decrease in delay for impacted nets. This SDF can be used with static
timing tools such as PrimeTime to calculate the impact of noise on timing.
- Jim McCanny
CadMOS San Jose, CA
( ESNUG 355 Item 11 ) -------------------------------------------- [7/26/00]
From: Yeshwant Kolla <kolla@cs.utah.edu>
Subject: How Can I Restrict Libs In DC To Specific Blocks In My Design?
Hi John,
I'd like to know if you or anybody else in ESNUG have tried constraining
Design Compiler to use one set of libraries for certain blocks in a design
and a completely different set for the remaining blocks in the same
design?
I know I can synthesize the blocks separately with the respective libraries
but then increasing the drive strengths along the critical path at the upper
entire design-level aren't taken into account, right?
- Yeshwant Kolla
Univ. of Utah
( ESNUG 355 Item 12 ) -------------------------------------------- [7/26/00]
Subject: ( ESNUG 351 #9 ) InterHDL's Verilint vs. Avanti's Novas Pricing
>> On the dark side, customers are still furious about Gerry's $47K price on
>> interHDL's VeriLint.
>
> Just to set the record straight, InterHDL had already raised the price
> before we bought the company, and I have the InterHDL price list to
> prove it. We have since lowered the price to $21K for the unlimited
> use batch version.
>
> - Mike Glenn
> Avanti Fremont, CA
From: Jay Dowling <jay@acut.com>
WOW, how nice of them, only ONE order of magnitude more than I paid for it.
- Jay Dowling
Acut
( ESNUG 355 Item 13 ) -------------------------------------------- [7/26/00]
From: Volker Rzehak <v-rzehak@ti.com>
Subject: ( ESNUG 82 #2 ) How Do I Handle Opposite-Input Tri-states In DC?
Hi, John,
In the "early" days of ESNUG there was a thread talking about a Synopsys
bug concerning the usage of tri-state buffers that have 2 enable inputs
that require opposite logic levels. I just ran into the same problem
and am trying to find a solution. Was there a solution posted (that I
didn't find)?
I tried to use the 'pin_opposite' attribute in the library but Design
Compiler failed to map the tri-state buffers. I tried the 'x_function' with
the same result. I tried the 'contention_condition' with the result that
Design Compiler mapped the tri-state buffers but tied one input to VCC (as
it did without any special attribute).
I think there must be someone who has solved this problem.
Thank you for your help and your ESNUG newsletter!
- Volker Rzehak
Texas Instruments Deutschland Germany
( ESNUG 355 Item 14 ) -------------------------------------------- [7/26/00]
From: Matt Gavin <mtgavin@collins.rockwell.com>
Subject: Problems With "Find" To Find The Driving Cell Of A Specific Net
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
( ESNUG 355 Item 15 ) -------------------------------------------- [7/26/00]
Subject: ( ESNUG 348 #8 351 #5 ) Synopsys DesignPower & Cadence NC-Verilog
> Monitoring behavior is simulator dependent.
>
> In his particular case, Pedersen's data_valid (a single bit) in HDL is
> connected to port 'in' of Pedersen's "XYZ" instance. His port 'in' is
> defined inside the "XYZ module" as a bus width of 3. Pedersen's
> data_valid is connected to in[0]. Since the other 'in' bits are not used,
> NC-Verilog internally represents the port 'in' as a single bit object,
> which is interpreted by our PLI as 'in'. But inside Verilog-XL or VCS,
> Pedersen's port 'in' is represented as a 4-bit bus object, which is
> interpreted by our PLI as 'in[0], 'in[1]', etc.
>
> - [ A Synopsys DesignPower CAE ]
From: Steven Sharp <sharp@cadence.com>
NC-Verilog cannot be internally representing the port 'in' as a single bit
object if it is declared as a four bit object. That isn't how Verilog works.
This may be an issue with "vectored" versus "scalared" nets. Perhaps this
PLI application is not handling one of them correctly.
- Steven Sharp
Cadence
> Our PLI monitors the in[0] and checks whether the in[0] exists. Our PLI
> checks the rtl2saif (forward SAIF) output file & NC-Verilog for in[0]. A
> mismatch occurs since in the rtl2saif output file the port is represented
> as in[0] and in NC-Verilog the port is represented as 'in'. Our PLI then
> writes out the backward SAIF file. Since port is interpreted by PLI as
> 'in' under the NC-Verilog environment, our PLI fails to find the name 'in'
> in rtl2saif output and therefore the port name is not written out to the
> backward SAIF file. In Verilog-XL or VCS, the in[0] port is represented
> with a matching name so our PLI is able to monitor and, check in rtl2saif
> and write out in the backward SAIF file information about that port.
>
> Pedersen's Workaround:
>
> 1) Remove in\[0\] line in the rtl2saif file; then data_valid is captured.
> 2) Change in\[0\] to 'in' inside the rtl2saif output file; then
> data_valid and in are both captured.
>
> - [ A Synopsys DesignPower CAE ]
From: Parvathy Uma <puma@cadence.com>
While this may do as a workaround (not a good one if you are actually
looking at bits) the correct solution would be to get the latest version of
the Design Power PLI. The problem was in the PLI code; problem description
follows:
The user PLI looks at all the nets in a module and once it finds a
vector net, checks whether it is a expanded vector net.
If it is a expanded vector net, it uses acc_next_bit to get
each bit of the expanded vector net.
Then it does a acc_fetch_type on the net bit and decides to put a vcl
trigger based on the return type.
Verilog-XL returns type accNet whereas NC-Verilog returns accNetBit
(Since it is actually a net bit, NC is correct in returning type
accNetBit.)
For a number of reasons, XL cannot always figure out whether bit of a
expanded vector net is a net or a net bit. The solution to this particular
problem is for the user PLI to anticipate a return type of accNetBit.
The STAR # for this problem is star #98945
- Parvathy Uma
Cadence
( ESNUG 355 Item 16 ) -------------------------------------------- [7/26/00]
Subject: ( ESNUG 350 #10 ) "Mystery" Book On Behavorial Synthesis Returns
> The only reference I know is a book:
>
> Behavioral Synthesis: Digital System Design Using the Synopsys
> Behavioral Compiler, with Disk
> By Knapp, David
> List Price: $78.00
> 231 Pages
> Published by Prentice Hall
> Date Published: 06/1996
> ISBN: 0135692520
>
> available at www.clbooks.com
>
> - Muzaffer Kal
From: Carl Harris <Carl.Harris@wkap.com>
Hi, John,
There is another book and it is now available... once again! This is the
"mystery" book you referred to in a ESNUG issue after DAC last year and in a
subsequent article in EE Times:
"Understanding Behavorial Synthesis:
A Practical Guide To High-Level Design"
by John Elliott
List Price $120
348 Pages
Published by Kluwer
Date Published:06/1999
ISBN:0-7923-8542-x
Disk Included
This book was published about this time last year and just before DAC,
Mentor purchased the entire first printing. The second printing has just
come into stock and is available directly from Kluwer or from
http://www.fatbrain.com -- to name a couple of sources.
- Carl Harris
Kluwer Publishing
( ESNUG 355 Item 17 ) -------------------------------------------- [7/26/00]
From: Chris Frailey <Chris.Frailey@motorola.com>
Subject: How Do You Convert Xilinx Gates To ASIC Gates? Favorite Ratio?
Hello, John.
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
( ESNUG 355 Item 18 ) -------------------------------------------- [7/26/00]
Subject: Three Very Cheap/Free/Shareware GDS-II Viewers for Windows95/98/NT
> Could anyone give me any pointers to GDS file viewer for WIndows95/98/NT?
> Freeware is preffered, but shareware is OK. I know there are commercial
> ones which cost me $500 and up.
>
> - Sonny
From: Jim_Thompson <Jim_T@analog-innovations.com>
If you're doing any serious GDS2 viewing you might as well pop for the $500
and get GDSVU from: http://www.artwork.com/gdsii/gdsvu/gdvw_dnl.htm
I have no connection with this company, just happen to use then product.
- Jim Thompson
Analog Innovations, Inc. Phoenix, Arizona
---- ---- ---- ---- ---- ---- ----
From: Serban-Mihai Popescu <serbanp@ix.netcom.com>
Look for the Boolean package (http://www.xs4all.nl/~kholwerd/bool.html).
- Serban-Mihai Popescu
---- ---- ---- ---- ---- ---- ----
From: s0nny@my-deja.com (Sonny)
I have downloaded it & tried it to see if it can handle a kind of big GDSII
file. It was 40MB big, and my PC is MMX200/64MB, well, it went hang.
Maybe because of my PC is so poor...
Thanks for the good info anyway!
- Sonny
---- ---- ---- ---- ---- ---- ----
From: stefan_liebing@hotmail.com
I tried Boolean, too, with some small GDS2-flies, it was quite OK, but any
attempt to load larger files (10+ MB) resulted in heavy harddisk activity
and a program-crash after some time, even on a PIII/500 with 128 MB.
- Dr. Stefan Liebing Nehren, Germany
---- ---- ---- ---- ---- ---- ----
From: Serban-Mihai Popescu <serbanp@ix.netcom.com>
Dear Stefan,
If you just want to look at GDS files, you can try a program I wrote for
Linux (it's plain C, so you might be able to compile it under Windoze
too). It converts GDSii to PS or HPGL (still some problems with this
one). See http://home.netcom.com/~serbanp.
Even if it's not quite optimized, it worked OK on some medium size GDSii
files (10...20M) I had on hand. The corresponding huge (up to 100M) PS
file can be nicely displayed by using gv.
- Serban-Mihai Popescu
---- ---- ---- ---- ---- ---- ----
From: iyer@mi.net
Check out http://www.concentric.net/~Viyer/ and download "sfviewer1.2". It
will let you view/export/print GDSII files. Let me know if you have any
questions or suggestions.
- Iyer
---- ---- ---- ---- ---- ---- ----
From: s0nny@my-deja.com (Sonny)
Lyer,
I have downloaded your software in the last October. I forgot the details
but it went something wong with that version.
I'll try it again, thank you for your information.
- Sonny
( ESNUG 355 Item 19 ) -------------------------------------------- [7/26/00]
Subject: ( ESNUG 346 #10 ) Find Number Of Instances Of Each Module In VCS
> Is there a tool using which i can find the total number of instances of a
> given module in my design? e.g. I may be instantiating DFF's or MUX cells
> everywhere, and I need to know how many of each type are instantiated
> across the entire hierarchy. At least VCS does not seem to print out this
> info.
>
> - Sudheendra Hangal
> Sun Microsystems Mountain View, CA
From: "Ira D. Baxter" <idbaxter@semdesigns.com>
My company, Semantic Designs, has a Reengineering Toolkit and a related
tool, CloneDR, that might help. CloneDR ("clone doctor") detects exact and
near-miss blocks of identical code fragments (without being told what to
look for) in large-scale sources (on up to 1 million lines of source code.)
We've used the CloneDR on a VHDL DLX design. Among "duplicate" fragments,
it found, it discovered that instruction and data caches were parameterized
by bus and clock signals. CloneDR could be used for counting modules;
quality analysis; and possibly IP extraction. See http://www.semdesigns.com
- Ira Baxter
Semantic Designs, Inc. Austin, Texas
( ESNUG 355 Item 20 ) -------------------------------------------- [7/26/00]
Subject: A Good Overview Article For Beginners On VLSI Clock Routing
> I am currently teaching a course (advanced undergraduate and beginning
> graduate) to VLSI Design Automation. Does anyone know a good overview
> or tutorial article on clock routing (e.g., IEEE Spectrum level) that
> would make a good reading assignment?
>
> - Christof Paar
> Worcester Polytechnic Institute Worcester, MA
From: s_d_lew@my-deja.com
You might want to check out: Jason Cong, Lei He, Cheng-Kok Koh, and Patrick
H. Madden, Integration, the VLSI Journal, Vol. 21, Nos. 1&2, November 1996,
pp. 1-94
- S. Lew
( ESNUG 355 Item 21 ) -------------------------------------------- [7/26/00]
Subject: ( ESNUG 345 #3 ) Free Realistic Cadence Silicon Ensemble Library
> I'm a graduate student in computer science. I'm now implementing layout
> with the Cadence Silicon Ensemble tool. But we don't have the cell
> library together with the tool. Is there someone who can tell me where
> can I find and download such a library that is compatible with Silicon
> Ensemble?
>
> - HongLiang Chang
> University of Minnesota
From: [ Anon, Please ]
Saw your request for help on ESNUG. (John, make me Anon, please.)
Try http://www.artisan.com/index2.html
On the left hand side there are "FREE LIBRARIES" which I believe include LEF
for SE. You will have to fill out some application to get access to the
libs, but Artisan should be OK about letting students use them too
(unsupported, of course).
- [ Anon, Please ]
============================================================================
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
|
|
