> Some cute pictures of Vito feeding the sheep with interesting titles,
> that's a prank. Feeding him deep fried sheep nuts, that's a prank.
> Setting the man up and putting him in jail is not just warped, childish,
> and petty, but just plain mean.
>
> If the police don't charge you with anything, I sure hope either Vito or
> Synopsys publicly humiliates you to the extent you deserve (a lot).
>
> - Drew Sher
> Magic Knot
From: John Swan <John_Swan-ACIC00@email.mot.com>
Hi, John,
I looked at the story about Vito's troubles (www.DeepChip.com) and didn't
believe for one minute that it actually happened that way -- that you
would spitefully put him in jail for the night! It was a funny story!
I'm sure Vito had fun making it up with you!!! (How else could you get
those pictures? The cops simply didn't notice you following Vito all the
way to his jail cell?!?)
You could have played the part of the evil computer guy on Jurassic Park
with your devious mind. The same actor played evil Newman in Seinfeld,
too. Any Hollywood movies coming up that you should try out for? :)
- John Swan
DigitalDNA Systems Architecture Lab
Motorola Schaumburg, IL
( ESNUG 334 Subjects ) ------------------------------------------- [10/99]
Item 1: ( ESNUG 333 #1 ) Verplex, Formality, Anonymity, & "Transit"
Item 2: ( ESNUG 322 #1 ) full_case/parallel_case, Evil Twins of Synthesis
Item 3: ( ESNUG 329 #11 330 #3 ) Converting Transistors Into Schematics
Item 4: The New, Free Xemacs-21 Editor Can Easily Handle Files Up To 512MB
Item 5: ( ESNUG 333 #6 ) Get DC Verilog Netlists Into Cadence Dracula LVS
Item 6: What's The Dirt On The Cadence Affirma FormalCheck Model Checker?
Item 7: A Few EDA Vendor Links Missing From The DeepChip "EDA JumpZone"
Item 8: Five Chip Designers Discuss The Foolishness Of C-Based HW Design
Item 9: Welcome To My "Translating Dc_shell Scripts To TCL" Horror Story
The complete, searchable ESNUG Archive Site is at <http://www.DeepChip.com>
( ESNUG 334 Item 1 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 333 #1 ) Verplex, Formality, Anonymity, & "Transit"
> Then, I was introduced to Verplex. Within 2 hours of getting the tool
> installed (and no design center support), I had an RTL to Flat Gates
> comparison completed on the 300k block. Of over 6k key points in the
> block, I had almost all equivalent with the exception of 16 aborted
> points. I then talked to the AEs for Verplex, and had a new release in
> no time that took care of the abort points (interesting to note that the
> aborted points were logic cones in the module that chrysalis could never
> do!). All of this with only 10-15 lines of scripting (definitely not like
> the Chrysalis tool!). I then tried the same block targeted to another
> vendor...BANG! a synopsys bug found with critical state points dropped.
> I have found that Verplex does a great job on RTL2FLATGATES and
> RTL2HIERGATES on blocks <350k. Either 10x performance over the
> competitors or it completes and they don't. Also, the memory usage seems
> to be about 1/2 to 2/3 of the competitors. For post layout, test
> insertion, and ECOs, I can do my 6.5M gate design in less than 1.5 hours.
>
> - [ Big Brother Is Watching ]
From: London Jin <londonj@eng.adaptec.com>
Hi John,
I am very much concerned about thi vague "synthesis bug" Big Brother
mentions in his letter. What kind of scenario is it? Can he please share
with us?
- London Jin
Adaptec
---- ---- ---- ---- ---- ---- ----
From: "Alex Koegel" <alexk@smlink.com>
Hi John,
Wait a second,.. 6.5M gates !?? That anon guy [ "Big Brother" ] who posted
must be working for a company that doesn't care about the chip final
production cost.
With a 0.35 um process (7K gates per mm^2), that's a 930 mm^2 -- which is a
30.5mm on-the-side chip.
With a 0.25 um process (15K gates per mm^2), that's a 433 mm^2 -- which is a
20.8mm on-the-side chip. Still huge...
- Alex Koegel
SmartLink - VLSI Group Netantya, Israel
---- ---- ---- ---- ---- ---- ----
From: Jeff Hu <jeff.hu@itexinc.com>
Hi John,
I used to 'delete' ESNUG directly from email list -- not even bother to read
it. That was changed until I found some meat in ESNUG-332. Now I read your
newsletter carefully and try to learn people's experience. However, there
is one thing that I would like to recommend. People who post articles in
ESNUG should include their real name and email address in case readers want
to find out more. There is no need to hide from this user group as long as
the comments he/she made are real.
- Jeff Hu, Cad Manager
ITeX
---- ---- ---- ---- ---- ---- ----
From [ Ground Control To Major Tom ]
Hi, John,
Anon please. I like seeing letters promoting Verplex in ESNUG. They
encourage Synopsys to improve Formality's capacity and speed, and for
Avanti to do the same with Chrysalis.
Verplex is winning yesterday's war by doing only RTL and gate-level
comparisons. They don't discuss it, but Synopsys has transistor-level
equivalence checking in Formality called Transit. It lets you compare
your source RTL with your post-layout transistor netlists (in CDL format.)
- [ Ground Control To Major Tom ]
( ESNUG 334 Item 2 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 332 #1 ) full_case/parallel_case, Evil Twins of Synthesis
> The popular myth that exists surrounding "full_case parallel_case" is
> that these Verilog directives always make designs smaller, faster and
> latch-free. This is false! Indeed, the "full_case parallel_case"
> switches frequently make designs larger and slower and can obscure the
> fact that latches have been inferred. These switches can also change
> the functionality of a design causing a mismatch between pre-synthesis
> and post-synthesis simulation, which if not discovered during gate-level
> simulations will cause an ASIC to be taped out with design problems.
>
> - Cliff Cummings
> Sunburst Design Beaverton, OR
From: Jack Hollins <jhollins@lsil.com>
Hi, John,
I just had to drop you a note of thanks for distributing the 'case' article
among those of us (especially on the west coast) who didn't make it to the
Boston SNUG. I'd nominate this as one of the most potentially impactful
ESNUG posts of the year. Keep up the great work.
- Jack Hollins, Design Engineer
LSI Logic Milpitas, CA
---- ---- ---- ---- ---- ---- ----
From: "Ashutosh Varma" <ashu@axiscorp.com>
Hi John,
Axis Systems has just announced availability of their IEEE compliant XSIM
simulator. The reason I am mentioning this simulator in relation to this
post is because XSIM, besides being a native compiled code Verilog
simulator, also has a feature called Design Xaminer which does:
i. Static synthesis subset compliance check for RTL design
ii. Dynamic RTL vs. post-synthesis gate semantics checking
It is the latter capability which deals with problems like the ones
mentioned by Cliff in his post. The XSIM simulator will point out a
parallel-case or full-case violation in your Verilog RTL simulation using
your actual test-bench and test-vectors. (This saves you the iteration of
first doing synthesis and then doing *slow* gate-level simulation before you
notice these problems. Also note that these problems cannot be detected by
static timing analysis tools like PrimeTime, Pearl, or Velocity.)
It also detects other potential cases of mismatches between RTL and
post-synthesis gate simulation, like X propagation (in RTL simulation, X's
are not propagated in Verilog). www.axiscorp.com
- Ashutosh Varma
Axis Systems Sunnyvale, CA
---- ---- ---- ---- ---- ---- ----
From: Paul Gerlach <paulge@mdhost.cse.tek.com>
John,
An interesting paper. I certainly hadn't thought much about it. At first I
didn't agree with Cliff. Now I partially do. To summarize my thoughts (many
of which are just Cliff's...):
1. If synopsys can detect parallel cases and optimize for them, I certainly
agree that usage of parallel_case is worthless.
(Except for one-hot machines as Cliff mentions - we use that method)
2. It seems that many places in my own code I have non-full cases that
are really fully specified in my mind. In the past I've used full_case.
Cliff says don't do that; I now agree.
But Cliff also says (in 3.3) that using a default: out = 'bx;
also isn't good because then your simulation & synthesis don't match.
Here I disagree. I think you're trying to optimize the wrong part of
the design: simulation vs. gates match. In doing so, you're giving up
some of the power of RTL simulation. In RTL I'm able to write code
in such a way that my logic will blow up to X's when a make a false
assumption. (i.e. I *believe* the case to be fully specified, if it's
not, I want X's introduced into my sims, not some latch function or
other valid input - X's are easy to detect and trace back)
In my opinion the power and usefulness of inserting X's to detect designer
failure in RTL outweighs the fact that synopsys will never "create" an
X from gates.
Also, have x's on the right hand side allows synopsys to treat something
as a don't care, perhaps further optimizing logic. If I fully specify
all outputs, even when I don't believe some will happen, I'm
constraining the function.
Personally I hold the X propogation feature of RTL to be more important
to me than the don't care optimization.
Editorial comment: in 4.3 Cliff said "this example happens to infer
priority encoder logic when sythesized." This confused me for a long time.
It seemed contradictory with statements made in 4.5. UNTIL I realized
that it created a priority encoder because that's what the truth table
specified, not any code construct or directive. I thought it was being
infered that even though synopsys *knew* it was parallel, it was still
building a priority encoder anyway. I understand Cliff now. :-)
- Paul M Gerlach
Tektronix, Inc. Beaverton, OR
---- ---- ---- ---- ---- ---- ----
From: Paul Miranda <paul.miranda@amd.com>
John,
That article on parallel_case and full-case hasn't done anything to convince
me to not use them. If I really want something to be parallel or full, then
I will put them in. According to the article, they will do what I expect.
Unless I totally missed something, these constraints will only hurt a design
if you add them when you shouldn't.
- Paul Miranda
AMD
---- ---- ---- ---- ---- ---- ----
> 4.5 A "parallel" case statement with "parallel_case" directive
>
> The casez statement in Example 7 is parallel! If a "parallel_case"
> directive is added to the casez statement, it will make no difference. The
> design will synthesize the same as without the "parallel_case" directive.
>
> The point is, the "parallel_case" directive is always most dangerous when
> it works! When it does not work, it is just extra characters at the end of
> the case header.
>
> module intctl2b (int2, int1, int0, irq);
> output int2, int1, int0;
> input [2:0] irq;
> reg int2, int1, int0;
>
> always @(irq) begin
> {int2, int1, int0} = 3'b0;
> casez (irq) // synopsys parallel_case
> 3'b1??: int2 = 1'b1;
> 3'b?1?: int1 = 1'b1;
> 3'b??1: int0 = 1'b1;
> endcase
> end
> endmodule
From: Dave Chapman <dave@goldmountain.com>
John,
This is dangerous and confusing, because it relies on the idea that the
compiler will interpret parallel cases such that, if more than one case is
satisfied, the FIRST ONE ENCOUNTERED will be chosen. Some stack-algorithm
parsers use the opposite, and will produce unpredictable results.
Much better would be to use explicit if statements.
Case statements are way too ambiguous for stuff like select logic,
arbitration, and interrupts.
- Dave Chapman
Goldmountain Sebastopol, CA
---- ---- ---- ---- ---- ---- ----
From: William Liao <wliao@mmcnet.com>
Hi, John,
Cliff's paper is quite useful, and I think it should be required reading
for all synthesis newbies. However, I strongly disagree with the idea
that "full_case" and "parallel_case" should be used sparingly. I try
my best to add "full_case" and "parallel_case" to every case statement.
I don't think Cliff's reasons for avoiding these directives are valid.
He wants to avoid them because when they "work", they cause unexpected
simulation and synthesis mismatches. But the causes of these mismatches
appear in the synthesis log as the warning messages Cliff mentioned in
his paper. Shouldn't a good engineer examine the log and fix the
problem instead of avoiding the problem?
Nor do I think the three reasons given in the paper (smaller & faster
design, removing latches, removing priority encoders) are valid. If
anyone actually believes these are the right reason to use "full_case"
and "parallel_case", they really need to sit down and carefully study
Cliff's paper before they screw up another project (unless they work
for my competitors, in that case they should continue as they are ;-))
The main reason I use these two directives is to do sanity checks.
When I add "parallel_case" to a case statement, I am telling Design
Compiler that I have carefully checked my case items, and none of them
overlap. If Design Compiler generates a warning message, it is telling
me that it disagrees, and I should check again. I always follow DC's
advice, and it has saved me many times. Similarly, when I add
"full_case" to a case statement, I am telling Design Compiler that all
possible case items are listed. Again, if it generates warning messages
because of the "full_case", I check my code.
I have another use for "full_case", and it is more dangerous, but I
think I am covered. I use "full_case" to avoid "default:", hoping
that Design Compiler understands it should optimize the circuit by
taking advantage of the "don't care". (Note the word "hoping", but
it is another story.) When "full_case" is used this way, it is entirely
possible that I miss a valid case item. My solution is to add a default
case that DC won't translate, like this:
module mux (in, s, out);
input [2:1] in;
input [1:0] s;
output out;
reg out;
always @(in or s)
case (s) // synopsys full_case parallel_case
2'b01: out = in[1];
2'b10: out = in[2];
// synopsys translate_off
default:
begin
$display("******* error");
$finish;
end
// synopsys translate_on
endcase
endmodule
Now if I miss something, I will get a message in my simulations,
and still gives DC some room for optimization. I believe this is no
worse than having a default item in the case. Why? Let's assume that
there is a default item that sets "out" to "in[2]". Let's further
assume that "out" should be "in[1]" when "s" is "2'b00". If by some
coincidence "in[1]" and "in[2]" are the same when the default item
is triggered, I won't find the bug. But my code catches this problem
and stops the simulation.
Finally, I believe many if not most case statements can be easily
rewritten to take advantage of "full_case" and "parallel_case". I'll
use Example 13 in Cliff's paper as an example.
module code4b (y, a, en);
output [3:0] y;
input [1:0] a;
input en;
reg [3:0] y;
always @(a or en) begin
casez ({en, a}) // synopsys full_case parallel_case
3'b0_??: y = 4'b0000;
3'b1_00: y = 4'b0001;
3'b1_01: y = 4'b0010;
3'b1_10: y = 4'b0100;
3'b1_11: y = 4'b1000;
endcase
end
endmodule
The statement "y = 4'h0" is now integrated into the case statement, and
"// synopsys full_case parallel_case" are added to make sure all case items
are parallel, and all possible "{en, a}" combinations are covered.
- William Liao
MMC Networks
( ESNUG 334 Item 3 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 329 #11 330 #3 ) Converting Transistors Into Schematics
> If this user wants extract the functionality of the cell and generate a
> truth table, there are two ways to look at the problem:
>
> 1) lots of library characterization tool vendors perform this step
> automatically as part of the delay measurement process
>
> 2) it is very difficult because of issues with dynamic logic,
> pass-gate logic, and feedback cells (i.e. flip-flops)
>
> These aren't contradictory; the tools tend to fall down when given "messy"
> cells. He may need to hire some outside help to do this tranlation by
> hand or, of course, the library characterization vendors would be only
> too happy to help you -- for a price.
>
> - David Chapman
> Chapman Consulting Santa Clara, CA
From: Christian.Jay@infineon.com ( Christian Jay )
Hi, John,
We are currently here in Siemens/Infineon in evaluation process with a new
small company located in the South of France. They have a beta-version of
TraLaLa (Transistor Level Analysis and Logic Abstraction) which proposes
unique features such as automatic recognition of dynamic logic, pass logic,
sequential logic structure recognition, structural pattern matching of
identical structures, ...
More info can be found at : <http://www.sansistor.com>
- Christian Jay
Infineon Technologies / Siemens Sophia Antipolis, France
( ESNUG 334 Item 4 ) --------------------------------------------- [10/99]
From: [ Size Matters ]
Subject: The New, Free Xemacs-21 Editor Can Easily Handle Files Up To 512MB
John,
If your readers are fighting the 128MB filesize limit in EMACS when
working with test vectors, SDF, etc., you should tell them about Xemacs-21.
(www.xemacs.org) It can handle files up to 512MB. Be sure to compile
with --use-minimal-tagbits. We're about to tape out and it has been
really helpful with those monster SDF files.
Please post this anonymously.
- [ Size Matters ]
( ESNUG 334 Item 5 ) --------------------------------------------- [10/99]
Subject: ( ESNUG 333 #6 ) Get DC Verilog Netlists Into Cadence Dracula LVS
> My company has its own fab and, unlike an ASIC buyer, after synthesizing
> a chip with Design Compiler and laying it out w/ our place-and-route tool,
> we use Dracula to run LVS. Now, Design Compiler writes out Verilog (not
> CDL/spice). LVS usually requires a CDL/Spice netlist (CDL is 99%
> identical to Spice):
>
> Design Compiler -> (Verilog netlist) -> Translator -> (CDL) -> Dracula
>
> For the past few years we've been using a Verilog2CDL/Spice translator
> from a vendor who is not fully committed to supporting and upgrading it.
> Our current solution has lots of problems and we're more than ready to
> find a better solution. Although many of our new products will use
> Avanti's Hercules instead of Dracula (Hercules readily accepts Verilog
> input), most of our projects will still use Dracula this year.
>
> Can anyone tell me either (1) how they get Design Compiler output into
> CDL/Spice, or (2) a different solution to this problem? Are there other
> Verilog2CDL/Spice translators available on the market?
>
> - Andy Frazer
> Integrated Device Technology Santa Clara, CA
>
From: Nir Sever <nir@gigapixel.com>
John,
Dracula supports Verilog (version 4.6 if I recall correctly). The flow is:
1. Run 'van' to analyze your Verilog netlist into a 5x format library.
2. Run LOGLVS
2.1 Use CIR commands to load your leaf cell's CDL/SPICE files
2.2 Use NVER to load your 5x library
2.3 Use CON to create the netlist (LVSLOGIC.DAT)
3. Run PDRACULA
4. Run jxrun.com
Make sure you have the latest Dracula release.
- Nir Sever
GigaPixel Corp. Santa Clara, CA
---- ---- ---- ---- ---- ---- ----
From: "Joe Kryzak" <jkryz@rocketchips.com>
John,
We also use Dracula in our flow, and have seen success with direct Verilog
in, bypassing CDL. We've also used EDIF, but had to have a top level CDL,
which was a pain. I would recommend Verilog.
Actually the Verilog input works quite well at the "logic" level that
Cadence refers to. I believe you can't mix EDIF and Verilog however, at
the "logic" level. We are just in the process of a design that we will be
reading into Dracula, but it will contain not only verilog blocks, but
analog devices instantiated in Verilog. The primitives for these analog
blocks are, of course, in CDL. In the last week, we've read in a Verilog
I/O pad ring that contained standard cell IO's, multiple independent powers
and custom analog IO's. The powers were the tricky part, because we needed
VSST, VDDT, VDDD, VSSD, etc as opposed to VCC and GND.
So, my opinion is to blow off CDL altogether, unless your standard cell
primitives are in that format, or you have analog blocks like we do. Our
digital primitives are in spice, although it is almost the same as CDL.
But, for the gate level version of your digital portion, I would recommend
Verilog in at the "logic" level.
- Joe Kryzak
RocketChips, Inc. Minneapolis, MN
( ESNUG 334 Item 6 ) --------------------------------------------- [10/99]
From: [ Curious Minds ]
Subject: What's The Dirt On The Cadence Affirma FormalCheck Model Checker?
Hi John,
Have you ever received any comment/feedback from your users group about the
Affirma FormalCheck model checker from Cadence. I am interested to know how
useful is this tool for control and datapath designs. Is it useful or is it
a waste of time? Anon please.
- [ Curious Minds ]
( ESNUG 334 Item 7 ) --------------------------------------------- [10/99]
From: Edward Arthur <eda@ultranet.com>
Subject: A Few EDA Vendor Links Missing From The DeepChip "EDA JumpZone"
John,
Just a few off the top of my head...
http://www.novassoft.com/
http://www.platform.com/
http://www.transeda.com/
http://www.cynapps.com/
http://www.cast-inc.com/
http://www.ikos.com/
Not affiliated with any of them... Thanks for the service...
- Ed Arthur
( ESNUG 334 Item 8 ) --------------------------------------------- [10/99]
Subject: Five Chip Designers Discuss The Foolishness Of C-Based HW Design
> "I agree with Geir," John Reynolds of Intel quickly replied, "Evaluate
> some of the tools and you will quickly see how restricted you are and the
> things you cannot model. The observation that one engineer had around
> here when discussing the C/C++ vs. HDL argument was that the more you
> restrict C++ by using class templates, etc., the more you shave the
> language so that you can synthesize it, the more funky crap you add into
> the language to simulate concurrency already found in HDLs, the more your
> 'language' approaches a Verilog or VHDL!"
>
> - from "Back To The C++ Future"
From: John Reynolds <jreynold@sedona.ch.intel.com>
Hey John ...
You're making me famous around here ... my "C++ as an HDL language sucks"
editorial that's now in EE Times is the talk of the water cooler here ... :)
I still think it's a dumb idea... I was in a conference call yesterday with
the folks from Synopsys talking about this "SystemC" stuff. Some parts I
like, but others are just too much trouble -- you'd might as well just learn
VHDL or Verilog (so my theory is confirmed, once again :).
I just wish somebody would take VHDL and Verilog and merge them in the
middle. VHDL is "too high level". But I'd miss some constructs from VHDL
in Verilog and thus it seems "a little less high level than it should be."
- John Reynolds
Intel
---- ---- ---- ---- ---- ---- ----
From: "Anders Nordstrom" <andersn@nortelnetworks.com>
John,
Check out what the guys at Co-Design http://www.co-design.com are doing.
They are creating a new language, Superlog, which is essentially an
evolution of Verilog combined with C. The best thing is that it will still
work with either today's Verilog or C so you don't have to start from
scratch with a new language.
Also keep an eye out for the new Verilog standard, Verilog-2000. It is not
C++ but it addresses many of the problems designers have today.
- Anders Nordstrom
Nortel Networks Ottawa, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: "Robert McLellan" <robm@nortelnetworks.com>
Dear John,
Loved your comments about C/C++, internal CAD at large system companies
having already "been there done that", etc. If there's anything that's a
hallmark of the EDA business, it's that in general it's a marketplace that
suffers from a high degree of "amnesia". It also begs the question of why
we persist in looking for the "grand unification theory" approach to all of
this... has anyone clearly identified the "problem" that matches their
simple "solution"?
As a friend once said, people don't want simple answers, they want simple
questions!
Good stuff... keep it up.
- Rob McLellan
Nortel Networks Nepean, Ontario, Canada
---- ---- ---- ---- ---- ---- ----
From: "Gary Greenstein" <greenstein@asic-alliance.com>
John,
Seems to me that there's one big difference: with C/C++ designs, you get
(more or less) free simulation. You just need an underlying event
management library, be it from an industry-wide effort or your own. Just
compile the program, and you have a simulation environment. It also allows
for very fast API access.
- Gary Greenstein
ASIC Alliance Corporation
---- ---- ---- ---- ---- ---- ----
From: "Kanu Emeruwa" <kemeruwa@newbridge.com>
John,
Is there no merit in a push for one standard language for ASIC development?
At Newbridge we currently use VHDL, e (Specman), C/C++ and we can't get away
from Verilog (RAM models, netlists) not to mention scripting languages Tcl,
Perl, csh.
Tcl appears to be gaining some ground with the EDA companies, how about an
HDL? Let's pick just one whether it's back to the future or not. I won't
hold my breath waiting though. Your article probably rightly has the effect
of braking the current excitement.
- Kanu Emeruwa
Newbridge Networks Corp.
( ESNUG 334 Item 9 ) --------------------------------------------- [10/99]
From: Gzim Derti <gderti@intrinsix.com>
Subject: Welcome To My "Translating Dc_shell Scripts To TCL" Horror Story
Hi, John,
I'm trying to translate my current set of dc_shell scripts to their supposed
Tcl equivalents. After talking to some people at Boston SNUG, I decided to
try and give dc-transcript a whirl & see if I got back anything that works.
Welcome to my nightmare...
Headache #1
-----------
Originally in dc_shell, I use the following lines of code to check for a
free license...
echo "Waiting for VHDL-Compiler license!!!"
dc_shell_status = 0
while (dc_shell_status == 0){
get_license VHDL-Compiler >> /dev/null
}
echo "Got a license!!! WILL continue with job!!"
Which dc-transcript converted to the following tcl...
echo {Waiting for VHDL-Compiler license!!!}
set dc_shell_status [ set dc_shell_status 0 ]
while { $dc_shell_status == 0 } {
redirect -append /dev/null { get_license VHDL-Compiler }
}
echo {Got a license!!! WILL continue with job!!}
This sits in an infinite loop due to the fact that the NEW AND WONDERFUL
dc_shell-t DOESN'T have any concept of what dc_shell_status REALLY is and
treats it as a variable made up by yours-truly.
The code that ACTUALLY works looks as follows:
echo {Waiting for VHDL-Compiler license!!!}
set dc_shell_status [ set dc_shell_status 0 ]
while { $dc_shell_status == 0 } {
set dc_shell_status [ get_license VHDL-Compiler ]
}
echo {Got a license!!! WILL continue with job!!}
Note how the new VARIABLE dc_shell_status gets the result of running the
get_license command, and now ALL IS RIGHT WITH THE WORLD.
Headache #2
-----------
If in your current scripts (dc_shell) you use the following:
current_design = <block>
dc-transcript will treat current_design as a NEW VARIABLE and mess your
scripts up. If, however, in dc_shell you use:
current_design <block>
This gets translated correctly. I do both interchangeably since they both
work the way I'd expect in the dc_shell shell.
Headache #3
-----------
I've also noticed that if I define some constants and/or variables in
include files, the dc-transcript doesn't bother to modify the calls to these
variables by preceding them with a "$" character... so I'm left to manually
walk through the results of dc-transcript and fix the variables that it
forgot, or couldn't figure out.
The more I get into this, the LESS I like the tcl shell... Too many of my
OWN MAN-YEARS invested in dc_shell!!!!!
Headache #4
-----------
In dc_shell I do the following like water...
current_design curr_structural
srcpath = ../VHDL/
language = vhdl
langext = .vhd
modules = find(design, "*") #should find all designs in current block
foreach(module, modules) {
do some stuff using the variable modules as a string like...
analyze -f language srcpath + module + langext
elaborate module
write -f db module -o module + ".db.elab"
etcetera, etcetera...
}
Putting the above through dc-transcript I get....
current_design $structural
set srcpath ../VHDL/
set language vhdl
set langext .vhd
set modules [find reference {*}]
foreach_in_collection module $modules {
analyze -f $language [format "%s%s" [format "%s%s" $srcpath [get_object_name $module]] $langext]
elaborate $module
write -f db $module -o [format "%s%s" [get_object_name $module] {.db.elab}]
yadda, yadda, yadda
}
Now, the MAJOR problem with the Tcl above is the need to replace all calls
to $module that you are trying to use as simple names (ala dc_shell) with
the call...
[get_objec_name $module]
Luckily, dc-transcript uses that method once in a while and I noticed it and
tried it as a last gasp. So, the resultant modified lines look as follows:
elaborate [get_object_name $module]
write -f db [get_object_name $module] -o [format "%s%s" [get_object_name $module] {.db.elab}]
Headache #5
-----------
In my dc_shell scripts, I leave places for the user to create a
<blockname>.dscr (designer script) so that they can add some special stuff
to blocks such as set_implementation, set_loads, etc. In dc_shell, if these
files DON'T exist, then dc_shell notes the problem in the log file, but
continues on with the rest of the compile like nothing major happened...
include module + ".dscr"
Is all I had to had to have for things to run along without a problem. BUT,
in tshell I had to use the following to get the TCL parser to get past the
problem:
if { [file exists [format "%s%s" [get_object_name $module] {.dscr}]] } {
source -echo -verbose [format "%s%s" [get_object_name $module] {.dscr}]
}
As if THAT's intuitively obvious...
Headache #6
-----------
If you use:
set_max_fanout DEFAULT_MAX_FANOUT current_design
The equivalent TCL seems to be:
set_max_fanout $DEFAULT_MAX_FANOUT [get_object_name [current_design]]
Headache #7
-----------
I looked for this in the big black TCL book by Welch and didn't find it, but
if you are trying to do a compare of a boolean to true or false, as in an if
statement, here's the syntax...
if {[is_true <boolvar>]} { do stuff here }
if {[is_false <boolvar>]} { do other stuff here }
Note: since we're talking about if statements, if you forget the second
curly bracket at the end of the conditional, you will get an error in the
TCL parser about reaching an unexpected EOF. VERY cryptic, so remember that
if you see EOF in the error_info log, look for mis-matched {}'s.
One basic rule that I figured out: If something doesn't work the way you
expect and you've used dc_shell forever, you probably need to add
[get_object_name $var] to get going.
Hope this is helpful for someone out there. It took me ALOT of hair pulling
to even get ONE of my scripts running. I've pretty much decided that I have
many too many personal man years invested into my scripts, and if Synopsys
ever forces me to go pure TCL I'll jump off a building (or quit the
profession, whichever would make my wife happier at the time ;-)
- Gzim Derti
Intrinsix Corp. Rochester, NY
|
|
