( ESNUG 317 Item 7 ) --------------------------------------------- [5/13/99]
From: [ Erich of Synopsys ]
Subject: A Follow-up To The User Tcl Tutorial Questions From SNUG'99
Hi John,
I was the Synopsys CAE at SNUG who gave the Tcl tutorial. To find it, go
to http://www.snug-universal.org for the slides. What follows below is a
write-up on the user questions I had at the end of my talk. Please do not
post my email address. I am not the CAE responsible for supporting Tcl and
I don't want to get flooded with email.
- [ Erich of Synopsys ]
---------------
Q: How do I configure my .synopsys_dc.setup to use both DC Shell (DCSH)
and DC-Tcl?
A: The recommended way to support both shells is to convert your home and
local .synopsys_dc.setup files into Tcl subset. This can either be done
manually or automatically with the dc-transcript program provided with
DC99.05.
If a particular user or project is going to stay in DCSH mode, then
their home and local setup files can stay in DCSH format. Likewise, if a
particular user or project is going to stay in DC-Tcl mode, then their
home and local setup files can stay in Tcl format. It's only when a
particular user or project must switch between DCSH mode and DC-Tcl mode
that things can get complicated. In this case, if the home and local
setup files are converted over to Tcl-subset then either shell can be
used.
Q: If I only want to use DCSH, do I have to re-write any of my scripts?
A: No. dc_shell will function the same it did before. You only have to
worry about converting scripts if you want to use Tcl.
Q: How can I tell which dc_shell mode is being used from within a script?
A: There is a read-only variable available in both dc_shell and dc_shell-t.
This variable is called "dc_shell_mode" and it will either contain the
value of "default" if you're using DCSH mode or it will contain the
value of "tcl" if you're using DC-Tcl mode. You can use it like this:
# This comment is required at the top of the .synopsys file
# in order for it to be recognized as DC-Tcl instead of DCSH
#
if {$dc_shell_mode == "default"} {
echo "You invoked dc_shell in DCSH mode"
} else {
echo "You invoked dc_shell in Tcl mode"
}
NOTE: You MUST use Tcl-subset for your .synopsys_dc.setup file if you
want to use both shells. This means that even if you have DCSH commands
that you only want to source if you're using DCSH mode, you MUST convert
them to Tcl-subset. There is no way around this. One of the most common
things that people want to do is use "alias" in their setup files. This
will still work and you can use the above if-else to define different
aliases depending on which shell you're using.
/*
* THIS WILL NOT WORK
*/
if (dc_shell_mode = "default") {
include a_dcsh_script
} else {
source a_tcl_script
}
# NEITHER WILL THIS
#
if {$dc_shell_mode == "default"} {
include a_dcsh_script
} else {
source a_tcl_script
}
In both cases, the syntax is incorrect.
# BUT THIS WILL WORK
#
if {$dc_shell_mode == "default"} {
source a_translated_dcsh_script
} else {
source a_tcl_script
}
Q: What's a Tcl collection?
A: I got the sense from the comments that I heard that users wanted to
better understand collections. I hope the following helps to give some
background and better understanding.
The collection concept comes from OOP (Object Oriented Programming).
Rather than treating all data as simple variable types like integers,
strings, or floats OOP treats data as objects. Objects can be made up of
primative things like strings and numbers, but they can also be other
things as well. Design Compiler objects include ports, pins, designs,
cells, nets, etc...
Additionally, OOP combines objects with functions and procedures to make
them more powerful and useful. This idea of coupling data (objects) with
the functions and procedures that know how to manipulate that data is
fundamental to OOP. You don't necessarily need a special programming
language to have OOP. OOP is a programming concept.
If you have been using Design Compiler, you have been using these
concepts all along, you probably just didn't think about it. In DC, you
create design objects by synthesizing RTL to gates. HDL compiler
transforms your RTL into a generic representation of your design
using GTECH cells, nets, ports, etc... DC then takes your constraints and
transforms these objects into your mapped design using library cells.
When you wanted to operate on your design in dc_shell, you could use
commands such as "find(cell)" or "find(pin)" and you would get back
either a string or a list of strings which would hold the requested
data. It was always rather ambiguous whether a given string was holding
a port name, net name, cell name, or a pin name. This may have been
handy at times, depending on the sorts of things you might do in your
scripts, but it is also very prone to errors.
Think of a collection as a place to hold things. Let's say you want to
manage 4 sheep named Larry, Moe, Curly and Shemp. You could just keep
referring to them by their names, but that means that every time you
wanted to bring them up in conversation, you'd have to say, "Larry, Moe,
Curly and Shemp". An easier way to deal with the sheep would be refer to
the herd, eg "MyHerd". So now rather then having to call each of
the sheep out, you can just say, "MyHerd". MyHerd is a symbolic reference
to the sheep, Larry, Moe, Curly and Shemp.
This is how collections work in Tcl. Once you create a collection of
objects, you need only refer to it by it's reference. As it happens this
reference is called a handle. It is easier to keep track of this single
handle than it is to keep passing around the individual names of the sheep.
In real life, manipulating either a herd or four individual sheep is the
same, but in the software world there is a difference.
That said, collection is a group of objects referenced by a string
identifier. There is a set of commands to create and manipulate
collections.
Creating collection commands:
find, all_inputs, all_outputs, etc., get_cells, get_nets, etc...
Manipulating collection commands:
sizeof_collection, foreach_collection, add_to_collection,
remove_from_collection, copy_collection, query_object
Q: How do you convert a collection to a list?
A: We recognize that users will want to do this to get their old scripts
working. Please understand that when you're using collections correctly,
there should be no reason to go back and forth between lists and
collections. However, if you find a real compelling reason, here's how
to do it.
This is an updated version of the collection_to_list procedure that I
gave in the tutorial slides. There was a typo in the version that got
printed and for that I most humbly apologize. Please use this instead.
# PROCEDURE: collection_to_list
# ABSTRACT: Converts a collection of objects to a list of
# string object names.
# RETURNS: a list of object names (strings)
# empty list if it can not get_object_name
# in each member of the given collection.
# SYNTAX: collection_to_list a_handle
proc collection_to_list { args } {
# This is an example of how to process arguments
parse_proc_arguments -args $args result_array
# Iterate through the collection, building up the return list
set var [list ]
foreach_in_collection a $result_array(handle) {
set name [get_object_name $a]
lappend var $name
}
return $var;
}
#
# Define the arguments, command information and usage
#
define_proc_attributes collection_to_list \
-info "Create a list from collection" \
-define_args {
{handle "A collection" handle string required} \
}
Q: How do you convert a list into a collection?
A: Basically, you can add lists of things to a collection once the
collection has been created. Since collections need to know the object
type, you cannot assign arbitrary lists of strings to a collection
directly. The easiest way to create a collection is with the get_
commands. Then you can add lists of objects to the collection:
set a_collection [get_ports {a b c}]
set a_collection [add_to_collection $a_collection {d e f}]
Q: How do you combine two collections into one?
A: Someone asked me how to combine two collections into one. I apologize
for not getting back to you directly but I couldn't find you again in
the crowd at SNUG. Here's an example using ports:
set collection_a [get_ports A*]
set collection_b [get_ports B*]
set combined_collection [add_to_collection $collection_a $collection_b]
Yes, you can also just type:
set combined_collections [add_to_collection [get_ports A*] [get_ports B*]]
Q: Can I use Tcl/Tk from within my DC-Tcl scripts?
A: No. The Tcl that is compiled in as part of DC-Tcl does NOT include Tk.
There's nothing to prevent you from writing scripts in Tk external to
DC. If you come up with something that you absolutely have to do in Tk
that you want to work with DC-Tcl, there's nothing preventing you from
creating an external Tk program and communicating with DC-Tcl via the
standard Tcl communications functions (like Sockets, for example).
|
|
