( ESNUG 334 Item 9 ) --------------------------------------------- [10/28/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
|
|
