> Anyway, I'd like to move beyond this issue and encourage more detailed
> *technical* user letters about Vera and/or Specman -- you know, bugs,
> tips, gotchas, workarounds, scripts, etc...
>
> - John Cooley
> the ESNUG guy
Editor's Note: Mark your calendar; today is "All Hail Janick Bergeron"
day. Yup. Why? You know how in ESNUG you can get a Synopsys license
fetching TCL script, learn about a hidden switch in Behavioral Compiler
to turn on Xilinx DW parts, read another engineer's opinion that flat
P&R is "where it's at", find another engineer's review of Veritool's
HDL Lint, two user's impressions on Mentor's new MacroTest tool, and a
real review of a new Verilog book? Janick was the first engineer who
understood my request last week that we should move beyond "I luv/hate
Vera" / "I luv/hate Specman" letters and into the technically meaty
letters we so enjoy reading in ESNUG. Janick has kicked off this new
level of discussion with his letter on the missing classes header problem
in Vera. Cool! So... if you think Vera has a memory leak problem, write
me. If you have an "e" script that seeks out all missing corner cases,
write me. If you know of a way to optimize multiple Vera licenses, write
me. If you found a nasty bug in Specman -- you guessed it -- write me!
You get the idea. Let's get a real user Vera/Specman discussion going on
here. [And if you need to be anon, no problem -- just say so in your
letter.] And remember: happy "All Hail Janick" day! :^)
- John Cooley
the ESNUG guy
( ESNUG 341 Subjects ) ------------------------------------------- [1/00]
Item 1: ( ESNUG 335 #1 ) PhysOpt, Gambit, Module Compiler, Avanti Saturn
Item 2: Synopsys Wins "Honor" Of First User-Discovered Y2K Bug In EDA!
Item 3: ( ESNUG 339 #1 340 #2 ) New Version 1.1 Of IPOfix Now Available
Item 4: On-Line Registration Open For March 30-31 EuroSNUG 2000 In Paris
Item 5: ( ESNUG 340 #3 ) Make "Fake" DC Library Elements With Sub-Designs
Item 6: What's The Customer Dirt On ModelSim's Verilog/VHDL Co-Simulation?
Item 7: Altera Apex Is Flakey; How About Using FPGA Compiler II Instead?
Item 8: ( ESNUG 340 #8 ) I Disagree With Zain's Use Of "Initial" Blocks
Item 9: ( ESNUG 339 #5 ) A2ps, Enscript, Trueprint, and LEDA's KRYPTON
Item 10: Customer Seeks Utility To Convert VHDL Source to Verilog Source
Item 11: Strange Timing Bug Found In Synopsys VHDL VSS 99.10 Simulator
Item 12: ( ESNUG 338 #6 339 #4 ) DC/PT 3-D Load-Dependent Lookup Tables
Item 13: ( ESNUG 339 #3 340 #5 ) We Force All Our FF's To Zero On Reset
Item 14: DC 99.05-4 "set_wire_load -selection_group" Attribute Won't Set!
Item 15: Three Solutions To Fix The Vera "Missing Classes" Header Problem
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
( ESNUG 341 Item 1 ) --------------------------------------------- [1/00]
Subject: ( ESNUG 335 #1 ) PhysOpt, Gambit, Module Compiler, Avanti Saturn
> Using our PhysOpt flow, 300k gate layout partitions typically took 2 to
> 3 passes to achieve both timing and routing convergence. Each iteration
> (doing steps 4 through 8 above) took 2 days for the first pass and 1 day
> for each incremental pass. Since PhysOpt tweaks placement for timing
> fixes while simultaneously assessing routing congestion, we found it
> made better optimizations. We also found first pass placement quality
> from PhysOpt was better in both timing and routeability than first pass
> placements from the Avanti Apollo timing-driven placer.
>
> - Bob Prevett
> NVIDIA Santa Clara, CA
From: Nick Summerville <nsummerv@ford.com>
Hi, John,
I read Bob's review of PhysOpt in ESNUG 335 #1 and was intrigued by the
placement/timing results he quoted. I had evaulated some of the placement
software from which the PhysOpt software came and did not see the kind of
placement quality he talked about. Perhaps my knowledge of the basis of
PhysOpt placement is incorrect. Did this placer come from technology
developed by Gambit? What kind of utilizations do you typically achieve,
or, what kind of transistor densities do you usually achieve?
I was also wondering what the total placement times were for the block(s)
in question. I can see how the INITIAL placement for PhysOpt or a variety
of other placers would be better than Avanti. Avanti's initial placement
frequently is not that great. But in our evaluations (admittedly some time
ago) the Avanti placer achieved the best final placement in the shortest
amount of time.
With respect to the timing driven placer (and router) in Avanti, yes the
run times and level of effort are substantially greater when timing-driven
is invoked. We have found that frequently it is less effort to run the
placer in non-timing driven mode, achieving a certain level of utilization,
and then do IPO/ECO corrections to close the gap on timing. However, I'm
certain Nvidia's clock speeds are greater than ours. We typically are under
60 Mhz, and frequently are under 40 Mhz. We rarely have systemic timing
failure, only small numbers of paths that need to be corrected. Whenever
we've had systemic failure, we often can trace the problem to inappropriate
constraints during synthesis.
And finally, do you think the PhysOpt placer would be faster or yield
smaller layouts than the Avanti placer run in non-timing mode?
- Nick Summerville
Ford Microelectronics Colorado Springs, CO
---- ---- ---- ---- ---- ---- ----
From: Bob Prevett <prevett@nvidia.com>
John,
Gil Herbeck of Radix20 wrote me saying "I gather from your description of
the PhysOpt flows that you guys aren't using Module Compiler anymore." If
anyone got the impression, I'm sorry. Module Compiler and DC were used to
generate the original netlist from Verilog/MCL. PhysOpt didn't come into
the picture for us until after we had a netlist ready for P&R.
- Bob Prevett
NVIDIA Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: [ An Engineer At LSI Logic ]
Hi John,
Keep me anon. I work in the Methodology Development group at LSI Logic. I
read Bob's review of Synopsys PhysOpt in ESNUG and am very interested in
finding out more of your issues in working with an Avanti backend. Were
there issues with getting the PDEF into Avanti? Was it translated via
SCHEME? Did both cell placement and global routing information transfer
from PhysOpt into Avanti? Did PhysOpt have a good understanding of
blockage due to memories, power rails, etc?
Also, he didn't mention whether his "old" flow utilized Avanti Saturn for
physical re-synthesis. Did it?
- [ An Engineer At LSI Logic ]
( ESNUG 341 Item 2 ) --------------------------------------------- [1/00]
From: Paul Fletcher <paulf@chdasic.sps.mot.com>
Subject: Synopsys Wins "Honor" Of First User-Discovered Y2K Bug In EDA!
John,
Have you noticed the Y2K bug in the Synopsys design_analyzer? I just
noticed it the other day myself, in version 99.05-2. They have fixed it
in 99.10, but I remember being told that version 98.08 was Y2K clean.
If you bring up design_analyzer and look at the date in the little box
at the bottom the date has 100 for the year. (For instance: 1/100)
This is not a killer bug but it just goes to show how easy these things
can slip by. Keep up the great work.
- Paul Fletcher
Motorola SPS Chandler, AZ
( ESNUG 341 Item 3 ) --------------------------------------------- [1/00]
Subject: ( ESNUG 339 #1 340 #2 ) New Version 1.1 Of IPOfix Now Available
> Since the days of JTAG we've been using Pearl/Primetime w/ some scripting
> glue to fix everything that can be fixed by buffer insertion and cell
> size changes. Thank Jeff for this and I'll see how he does it.
>
> - Stefan Thiede
> Philips Semiconductors Sunnyvale, CA
From: Jeff Winston <jwinston@maker.com>
Hi John,
I enhanced IPOfix last week so it can write out and read back (in ASCII
text form) the changed database so users could muck with it using other
programs and scripts. Many users might find this feature very useful.
It allows users to add their own scripts in the flow with IPOfix. Now
it's IPOfix 1.1 on http://www.DeepChip.com for downloading.
- Jeff Winston
Maker Communications Framingham, MA
( ESNUG 341 Item 4 ) --------------------------------------------- [1/00]
From: Ronald Niederhagen <ronald@synopsys.com>
Subject: On-Line Registration Open For March 30-31 EuroSNUG 2000 In Paris
Hi, John,
Could you send out a posting to ESNUG announcing registration opened for
SNUG'00 Europe conference to be held on 30-31 March 2000? Reg info is on
http://www.snug-universal.org/europe/europe.htm
We plan on high attendance this year due to the conference being held in
Paris. Highlights include new product demos, the highly anticipated
Physical Compiler Tutorial, and, of course, user presentations.
SNUG'99 Europe was in Munich last year was a huge success, and having it
in Paris this year is sure to uphold the sucessful tradition. This year
we get to drop our beer steins, and raise our wine glasses.
See you in Paris.
- Ronald Niederhagen
SNUG'00 Europe Technical Chair Muenchen, Germany
( ESNUG 341 Item 5 ) --------------------------------------------- [1/00]
Subject: ( ESNUG 340 #3 ) Make "Fake" DC Library Elements With Sub-Designs
> Is there a way to create a Synopsys library element from a design so that
> Synopsys treats the subdesign as a library component? Say, for instance,
> I have a large design that is made up of many subdesigns; I'd like to be
> able to replace one or more of the designs with a Synopsys library
> component to cut down on the memory usage to make things run faster, etc.
> (And for the moment, lets not worry about loading ...)
>
> - Tom Cruz
> IBM Microelectronics Division
From: Brian Kane <briank@torrentnet.com>
Hi John,
Have him look at the DC "model" command - I think it does what he wants.
- Brian Kane
Ericsson IP Silver Spring, MD
---- ---- ---- ---- ---- ---- ----
From: [ A Synopsys PrimeTime CAE ]
John,
It sounds like PrimeTime's model extraction will do exactly what Tom wants.
You load in a netlist, extract the model of any arbitrary subdesign, and
presto - PrimeTime gives you a single-cell linkable .db file which contains
a macrocell with all the proper timing and load/drive behaviors. You can
plop one or more of these down in DC or PT or Chip Architect or whatever,
and have it faithfully act like the design (without having all the baggage
of those gates in memory).
- [ A Synopsys PrimeTime CAE ]
---- ---- ---- ---- ---- ---- ----
From: Scott Evans <scott@sonicsinc.com>
Hi, John,
Would a STAMP model serve his needs or is that more than you were looking
for? You would need access to PrimeTime. The essential commands you need
are extract_model and compile_stamp_model (as well as being sure to set
the various extract_model* variables).
- Scott Evans
Sonics Inc. Mountain View, CA
---- ---- ---- ---- ---- ---- ----
From: [ Another Synopsys PrimeTime CAE ]
Hi John,
It sounds like a perfect use for model extraction, but since he has
searched the manuals I assume he's looked at the PrimeTime Modeling User
Guide, and I could be missing something instead.
Model extraction allows you to create a timing model (essentially, a
somewhat complex library element) from any gate-level netlist. Its purpose
is as you say to cut down on memory usage and CPU analysis time. You can
replace n blocks in your design with extracted models. These models capture
the worst-case/best-case paths from primary inputs and leading to primary
outputs. Internal register-to-register paths are discarded as they are
generally not needed in the full-chip context (they can be analyzed at the
block-level). You have the choice of generating a .db version of the model
(PT and DC think of it as a compiled .lib) or a Stamp source file, but
not .lib.
You basically set up the design you want the library element for, create the
clocks, false paths, MCPs, etc., then tell PT to create the element for a
particular operating condition:
extract_model -library_cell -output mymodel -operating_conditions {WCCOM}
Not all library cell attributes are preserved in the model (but area is
preserved.)
- [ Another Synopsys PrimeTime CAE ]
---- ---- ---- ---- ---- ---- ----
From: Oren Rubinstein <oren@gigapixel.com>
John,
Design Compiler has a command called "model", which does everything you
need, including updating the library. After Tom models his design, he
should use remove_design to get rid of the original.
- Oren Rubinstein
GigaPixel Corp. Santa Clara, CA
( ESNUG 341 Item 6 ) --------------------------------------------- [1/00]
From: Georg Zehentner <zehentner@heidenhain.de>
Subject: What's The Customer Dirt On ModelSim's Verilog/VHDL Co-Simulation?
Hi John,
We're thinking about using Modeltech's ModelSim to simulate a Verilog gate
level design in a VHDL-Testbench. (We want to reuse the VHDL testbench we
designed together with the Verilog RTL code of the design.) I'm interested
in any user experiences with ModelSim's Verilog engine & their VHDL/Verilog
co-simulation. How about their:
- Simulation time ( especially for designs about 100k gates)?
- Compile time ( especially for designs about 100k gates)?
- Backannotation (again, for 100k gates)?
If someone has experiences compared to Verilog-XL or Synopsys's VCS or
Viewlogic's Fusion, it would be great. Many thanks for moderating the
ESNUG, John.
- Georg Zehentner
HEIDENHAIN GmbH
( ESNUG 341 Item 7 ) --------------------------------------------- [1/00]
From: Justin Smith <justin@aus.atmospherenet.com>
Subject: Altera Apex Is Flakey; How About Using FPGA Compiler II Instead?
John,
As part of the verification of our ASIC design, we plan to build an FPGA
based prototype using Altera 20K Apex devices. Unfortunately we are having
problems compiling our VHDL directly with Quartus (Altera's Apex software).
We get lots of 'internal' errors, plus it appears that Quartus is quite
restricted in its VHDL support. Another option would be to use Synopsys
FPGA Compiler II. I was wondering if anyone has had any stories about using
FPGA Compiler II in conjunction with Altera Quartus ?
- Justin Smith
Atmosphere Networks Osborne Park, Western Australia
( ESNUG 341 Item 8 ) --------------------------------------------- [1/00]
Subject: ( ESNUG 340 #8 ) I Disagree With Zain's Use Of "Initial" Blocks
> The three categories of a synthesis subset are "Supported", "Not
> Supported", and "Ignored". Synthesis tools ignore initial blocks, and
> it is not wrong to use these statements in synthesizable code. Note that
> these examples are not presented as synthesizable descriptions. Initial
> blocks are useful for pre-synthesis simulation of state machines that do
> not have any hardware resetting mechanisms. This section presents a
> basic state machine and adds to it in the later sections. Without a
> resetting mechanism, the only way to simulate is to use an initial block.
> With resetting mechanism, it is still a good practice to use initial
> blocks. Page 252 shows a state machine with an asynchronous reset.
>
> - Zain Navabi
> Author of "Verilog Digital System Design"
> Northeastern University Boston, MA
From: Vigyan Singhal <vigyan@home.com>
Dear John,
I must disagree strongly with one comment in Prof. Navabi's response to his
book review by Cliff Cummings.
The use of initial blocks for synthesizable blocks is extremely dangerous.
First, if the state machines do not have any hardware resetting mechanisms,
that is clearly not a synthesizable state design. Even otherwise, let's say
you use an initial block to initialize a design for RTL simulation. This
makes the sematics of RTL and synthesized gate-level different, and is very
dangerous. Consider a flow where you simulate only the RTL and use formal
equivalence checking to verify the equivalence of RTL vs gate-level. The
following may very easily happen:
RTL simulates fine. Synthesis has no bugs, and formal equivalence checking
approves the equivalence of RTL vs gate. However, the real gate-level
does not initialize correctly because synthesis (and equivalence checking)
ignored the initial blocks. But since you didn't do any gate-level
simulation, you're dead!
On the other hand, if you do not rely on initial blocks, this cannot happen.
Anytime your RTL has different simulation and synthesis sematics, you are
opening up a dangerous gap in the otherwise reliable static verification
flow. As Cliff orginally said, the use of initial blocks should be
restricted to testbenches in an ASIC design design flow.
- Vigyan Singhal
( ESNUG 341 Item 9 ) --------------------------------------------- [1/00]
Subject: ( ESNUG 339 #5 ) A2ps, Enscript, Trueprint, and LEDA's KRYPTON
> 1.) Pretty Printers. I'd like a pretty printer for Verilog (and
> other things like TCL, dc shell, perl) which highlights keywords, etc.
> In poking around I ran across a2ps, Enscript, and Trueprint. I've
> tried out Enscript and it pretty well does everything I want, but I
> was wondering if anyone out there has tried all three or another that
> I haven't heard of and has an opinion on which is best (or are they all
> pretty much the same)?
>
> - Tomoo Taguchi
> Hewlett-Packard San Diego, CA
From: Ed Arthur <earthur@lucent.com>
Hi John,
Regarding pretty printers, Tomoo has done pretty good research. I wrote
the original Verilog modes for both Enscript and A2ps -- and haven't even
heard of Trueprint!
I think A2ps is a bit more flexible than Enscript (you can do 4-up for
instance) but Enscript is a bit easier "out of the box". I still haven't
had time to install Trueprint yet!
As for code obfuscators, you've hit the nail on the head. I've not seen
one which leaves library elements alone and prints a cross reference. I
see an opportunity here... code-obfuscators.com and an IPO... :)
VCS has a built in "mangler" with 3 levels of "manglosity" and you can
also specify on a cell by cell basis what not to mangle.
- Ed Arthur
Lucent Technologies
> 2.) Obfuscation Utilities. I want to send test cases to vendors, but I
> want to obfuscate the code/netlist (change reference names like wire,
> port, instance, module names) so that the design intent is not obvious,
> but the design is still simulateable/synthesizable. Back in Feb 1997,
> you mentioned a program called KRYPTON from a French company called
> LEDA that does what I want. I poked around the web to see if I could
> find them and couldn't. Also in an old ESNUG, someone mentioned that
> Verilint does the same function. Those are the only two that I've
> heard of, but I was wondering if there are others out there.
>
> - Tomoo Taguchi
> Hewlett-Packard San Diego, CA
From: Bruno Verhaeghe <bruno@leda.fr>
Hello John,
My name is Bruno Verhaeghe, I am working as a Manager R&D for LEDA. I
have seen in the ESNUG that Tomoo was asking some questions about our tool
KRYPTON. Concerning our existance, LEDA still exists and still offers
PROTON. Since we are a French company our web page adress is www.leda.fr
and I admit it isn't easy to find.
- Bruno Verhaeghe
LEDA S.A. Saint Martin D'Heres, France
( ESNUG 341 Item 10 ) -------------------------------------------- [1/00]
From: "Paul Chazhoor" <paul.chazhoor@wipro.com>
Subject: Customer Seeks Utility To Convert VHDL Source to Verilog Source
Hi John,
Please may I know where I could get a utility to convert VHDL source files
to Verilog. Are there any free ones anywhere? If they're only sold, what
are your good/bad experiences with them?
- Paul Chazhoor
Wipro Infotech Bangalore, India
( ESNUG 341 Item 11 ) -------------------------------------------- [1/00]
From: Arrigo Benedetti <arrigo@vision.caltech.edu>
Subject: Strange Timing Bug Found In Synopsys VHDL VSS 99.10 Simulator
Dear John,
I want to share with you and the ESNUG crowd an amazing VSS bug. I had
this fragment of code:
p0 : process (clk, GSR)
begin
if (GSR = '1') then
addr_d <= (others => '0');
elsif (clk'event and clk = '1') then
addr_p <= ui_addr;
end if;
end process;
that refused to simulate the way it should with VSS 99.10. addr_p was not
the registered version of ui_addr, but an identical copy of it. After a
few hours I discovered that the problem was with the "addr_p" identifier:
changing the name of the signal to "addr_d" solved the problem. Isn't this
amazing?
- Dr. Arrigo Benedetti
Caltech Pasadena, CA
( ESNUG 341 Item 12 ) -------------------------------------------- [1/00]
Subject: ( ESNUG 338 #6 339 #4 ) DC/PT 3-D Load-Dependent Lookup Tables
> I am wondering how this can be true: "Setup/Hold depends on loads on both
> Q and Qbar." from the SYNOPSYS CAE' statment. For DFF's, we see a
> master/slave architecture. Otherwise, it is a LATCH. So, the setup time
> of a DFF should not be affected by LOADING, since the loading is blocked
> and afftected only the slave stage. What I am missing here??
>
> - [ Made In Taiwan ]
From: [ The Synopsys Library Compiler CAE ]
Hi John,
This is in response regarding the ESNUG 339 #4 3-D lib queries.
On my earlier response regarding 3-D constraint tables: Setup/Hold
constraints do not depend on loads on Q and Qbar. In fact the 3-D constraint
tables are indexed by the related pin, the constraint pin and the load on
the related output pin.
> The Synopsys .lib has become a very popular format which can be parsed by
> many tools (from Synopsys and other vendors). Along with this development
> additional commands and constructs like the 3-D tables were added. These
> are very well described in the Library Compiler Manuals, what is missing
> is a list or table of tools that can read this information and actually
> use it in a meaningful way. Let me give an example.
>
> /* Library defaults */
> slew_lower_threshold_pct_rise : 20.00 ;
> slew_upper_threshold_pct_rise : 80.00 ;
> slew_derate_from_library : 1.00 ;
> input_threshold_pct_fall : 50.00 ;
> output_threshold_pct_fall : 50.00 ;
> input_threshold_pct_rise : 50.00 ;
> output_threshold_pct_rise : 50.00 ;
> slew_lower_threshold_pct_fall : 20.00 ;
> slew_upper_threshold_pct_fall : 80.00 ;
>
> The above lines are only meaningful to PrimeTime. There is no hint to
> this in any documentation that I looked at, so a user may have the
> impression that all Synopsys tool understand this.
>
> - Stefan Scharfenberg
> Motorola SoCDT Munich, Germany
Regarding Stefan's enquiry about how the tools use different attributes
in the library, Chapter 4 ( Technology Library Attributes ) of the Library
Compiler Reference Manual Vol 1, has a list of all the attributes, the
different levels ( library, cell, pin ) where they are used in the library
and the different tools that use them ( like synthesis, test, fpga ). We
do not explicitly have tool names like DC because liberty is now an open
format and there are lots of other EDA vendor tools that use these
attributes. This table has been very useful for all the people that use
Liberty.
> Synopsys version 1999.10 supports 3-dimensional lookup tables for delay
> modeling. I hope to find out what other tools (e.g., Avanti, Cadence,
> etc.) already have or plan to have compatible timing modeling. What have
> you heard from your vendors? Are there characterization tools out there
> that can write .lib's with this syntax?
>
> - Andy Pagones
> Motorola Labs
Regarding Andy's question on 3-D delay tables, usually ASIC vendors have
their own characterization tools and there are a couple of ASIC vendors
who write out characterized data in this format. Lots of other EDA vendors
support the Liberty Tap-In program and I am not sure which tools exactly
support this particular feature, but a lot of tools from different EDA
vendors read timing information from Liberty.
- [ The Synopsys Library Compiler CAE ]
( ESNUG 341 Item 13 ) -------------------------------------------- [1/00]
Subject: ( ESNUG 339 #3 340 #5 ) We Force All Our FF's To Zero On Reset
>> The main point I was trying to make is that spending time crafting X's
>> in the RTL is non-productive and error prone. In addition, as Cummings
>> previously stated, it violates faithful semantics between the RTL and
>> gate level simulation.
>>
>> - Harry Foster
>> Hewlett-Packard Computer Technology Lab
>
> Our approach to finding un-initialized flops on our last design was to
> use several scripts to find flops without resets.
>
> - Greg Brookshire
> Raleigh Technology Corp Cary, NC
From: wsnyder@maker.com (Wilson Snyder)
Hi, John,
I reset very few flops, adding reset hurts the gate count and cycle time
too much, so the technique I use here is almost the opposite; get rid of
all X's and do two state simulation. While originally this technique was
created for a two state simulator, I still use it and like it. It prevents
the classic gate-level simulation problem where you have a multiplexor with
a X select input:
(uninitalized x) -----------
____|____
(initialized 0) ---->| |
| 2:1 MUX |------ Simulator says X
(initialized 0) ---->|_________|
Then the X's tend to propagate to the universe and never settle out. If
the uninitalized element was either 0 or 1, the output would be 0, and all
would be fine. (The simulator is correct in putting the X though.)
So, do what the real hardware does, power up everything 1 or 0.
How do you get rid of them? Write a simple PLI ACC program that loops
through every reg in the design, fetches the value, and if X sets it to 0.
You call this routine during reset, and all X's are gone. You then run an
entire regression.
Yes, but then even if you were missing resets your chip would work, but
fail in silicon! So, run it again, setting all X's to 1. Make many more
runs, with random values assigned to the X's. If you have a good random
regression strategy, you can be pretty certain all is well.
To add some peace of mind, we print out the flops that are X, and do look
through them by hand. But, even after checking them by hand we've had this
strategy detect reset bugs, and have never had a reset bug in silicon.
- Wilson Snyder
Maker Communications Framingham, MA
( ESNUG 341 Item 14 ) -------------------------------------------- [1/00]
From: Gzim Derti <gderti@intrinsix.com>
Subject: DC 99.05-4 "set_wire_load -selection_group" Attribute Won't Set!
Hi, John,
A few observations that I've been making lately concerning Design Compiler
99.05-4 (I know, I'm behind a rev, but this might carry forward...)
I'm currently working with a vendor's library that contains wire_load_models
for both 4 and 5 Layer Metal. I've got to try and force DC to use the
4LM only. So, I read the manual and it talks about a -selection_group
switch which should do this for me. I try and do the following...
set_wire_load -mode enclosed -min_block_size 20000 -selection_group 4LM
do a report_attribute on the design, and guess what, the selection_goup
attribute is unset! On a whim, I try and do a "compile -no_map" followed
by the same command as shown above, and low-and-behold, the attribute can
NOW be set on the design in question. So, now my sequence of events for
a working compile is...
apply constraints
compile -no_map
apply constraints AGAIN
compile -map_effort.........
(grumble, grumble, grumble........)
On a side note, I've noticed that DC is MUCH better at choosing the faster
DesignWare parts if you perform a "compile -no_map" BEFORE you do a
"compile -map_effort". Don't ask me why, but that's what I'm seeing lately.
Anyway, basically I'm just venting and hoping to help someone else through
this ever deepening quagmire known as Design Compiler.......
- Gzim Derti
Intrinsix Rochester, NY
( ESNUG 341 Item 15 ) -------------------------------------------- [1/00]
From: Janick Bergeron <janick@qualis.com>
Subject: Three Solutions To Fix The Vera "Missing Classes" Header Problem
Hi, John,
If you wanted user letters about VERA, all you had to do was ask. You did
not need to place an ad in the EE Times. :-)
When you implement a class to be used by some other source file, VERA can
automatically generate the header file that will contain all necessary
external declarations to satisfy the VERA compiler. Think of the *.vr file
as the package body or the *.c file, and the *.vrh (automatically generated)
as the package or the *.h file.
There is one problem though: if your implementation uses other externally
declared classes (through #include directives), the necessary #include
directives are *NOT* included in the generated header file. This requires
every user of your class to know what other file must be included
beforehand. If you change something and require an additional file to be
included, everyone must change their code to include that file as well.
To put it politely: it violates the most basic data encapsulation principle.
For example, here's my class "myC" which uses classes "herC" and "hisC":
#include "herC.vrh"
#include "hisC.vrh"
class myC extends herC {
hisC hisC_obj;
}
The generated header file will be:
/////////////////
// Vera Header file created from myC.vr
/////////////////
#ifndef INC__TMP_MYC_VRH
#define INC__TMP_MYC_VRH
extern class myC extends herC {
hisC hisC_obj;
}
#endif
Notice how the files "herC.vrh" and "hisC.vrh" are not included, even
though the declaration in the header file makes use of the classes defined
in them. If I include the generated "myC.vrh" in another VERA source file
without manually including these header files:
#include "myC.vrh"
I'll get a compilation error:
Version: 4.1.3
"myC.vrh", line 7 near <name> "herC" : parse error
extern class myC extends herC {
^
Compilation errors: 1
Because the VERA compiler does not know about "hisC" and "herC".
SOLUTION #1: Manually include are pre-requisite header file:
#include "herC.vrh"
#include "hisC.vrh"
#include "myC.vrh"
As pointed out earlier, its a high-maintenance proposition and a violation
of the data encapsulation and hiding principle.
SOLUTION #2: Manually write the *.vrh file.
This is what C/C++ programmers do. However, unlike C/C++, VERA does NOT
like a class to be declared both extern and local in the same file so you
cannot directly include the header file in the implementation file. You
have to play preprocessor games with the "extern" keyword. Also, the syntax
for declaring classes in header files is not as flexible: you cannot use
attribute blocks. For example, this is illegal syntax in a header file
but perfectly legal in a source file:
[extern] class myC {
packed {
integer count;
string name;
}
}
You'll have to explicitely put the attribute on each line:
extern class myC {
packed integer count;
packed string name;
}
SOLUTION #3: Fix the stupid header files!
A PERL script can peruse the source file & add back any #include directives
to the generated header file. John, please put my "vrhfix" script on your
website at http://www.DeepChip.com for downloading, OK? Using "vrhfix",
the generated header file above now becomes:
/////////////////
// Vera Header file created from myC.vr
/////////////////
#ifndef INC__TMP_MYC_VRH
#define INC__TMP_MYC_VRH
// Added by vrhfix, $Revision: 1.2$:
#include "herC.vrh"
#include "hisC.vrh"
extern class myC extends herC {
hisC hisC_obj;
}
#endif
My Makefile target for compiling VERA now looks like this:
%.vrh %.vro: %.vr
vera -cmp -h $*.vr && vrhfix $*.vrh
I've already reported this enhancement request to the VERA group. It should
be very easy to implement as the *_VRH symbols properly handle multiple
inclusion of the same header file. Any VERA code already written will
remain compatible with this solution.
- Janick Bergeron
Qualis Design Corporation Somewhere, Oregon
|
|
