Home > Community > Blogs > Digital Implementation > encounter how to writing to reading from a file with tcl
Login with a Cadence account.
Not a member yet?
Create a permanent login account to make interactions with Cadence more conveniennt.

Register | Membership benefits
Get email delivery of the Digital Implementation blog (individual posts).


* Required Fields

Recipients email * (separate multiple addresses with commas)

Your name *

Your email *

Message *

Contact Us

* Required Fields
First Name *

Last Name *

Email *

Company / Institution *

Comments: *

Encounter How To: Writing To/Reading From a File With TCL

Comments(9)Filed under: Digital Implementation, TCL, scripting, EDI system, Encounter digital Implementation system, Foundation Flow Design, Closure

A couple weeks ago, there was a good thread in the Digital Implementation Forums about managing buffering on nets between IOs and registers.  The post touched on a number of interesting topics, but one of the fundamental building blocks I'd like to expand upon in this blog entry is the fundamental task of writing to and reading from a file: File I/O.

It may seem like second nature for folks who use TCL-based tools like Encounter regularly, and it's pretty much straight TCL that we use to write and read, but I hope having concise examples of how to do this within Encounter is a useful reference.

Reading From a File

Say for example you received a list of nets in a file that needed to be routed on upper metal layers.  Here's an example of how you would read from that file and use the "setAttribute" command to apply that routing constraint.  Say your file looked like this:


Here's how we'd do it:

   set infile [open critical.nets "r"]
   while {[gets $infile line] >= 0} {
     setAttribute -net $line -bottom_preferred_routing_layer 5
   close $infile

Writing To A File

Say we wanted to capture a list of all of the nets in the design that are connected to IO pins?  Here's how we could do it:

   set outfile [open io.nets "w"]
   foreach net [dbGet [dbGet -u top.terms.net].name] {
     puts $outfile $net
   close $outfile

Redirecting Command Output To A File

Another scenario that's often useful is when we want to take command output that's echoed to the console and redirect it to a file.  We can use the "redirect" command for this purpose. (Note: The command is not documented. This will be rectified in the next release.)  Say for example you wanted to parse the output of the verifyGeometry command to see whether there were any violations.  Here's one way you could do it:

   redirect verifyGeometry > verifyGeometry.out
   set infile [open verifyGeometry.out "r"]
   while {[gets $infile line] >= 0} {
     if {[string match *Verification* $line]} {
       set nrViols [lindex $line 3]
   close $infile
   puts "verifyGeometry reported $nrViols violation(s)"

Tip: It's much easier to use "dbGet top.markers" to see whether there are violations in the design after running verifyGeometry:
encounter 1> dbGet top.markers

0x2aab94d740 0x2aab94d5f0

Separately, some commands like report_timing support ">" and ">>" redirection.  For example:

   report_timing > timing.report

We're looking to expand this easy ">" mechanism to include other commands in a future release.

I hope these examples are useful. Any related tips you'd like to share?

-Bob Dwyer


By jgentry on February 25, 2010

 I've found redirect to be very useful when you don't want your logfile to be dominated by, what's in my opinion, useless output.  For instance:

 deleteInst *INSTPATTERN*

 ...will give you a "Deleting instance [INSTNAME]" messages for each and every instance that is being deleted.  In some cases, we have thousands of these messages in our logfiles.  To get rid of this:

 redirect -quiet -nolog {

   deleteInst *INSTPATTERN*

 } >& /dev/null

 The several thousand messages gets reduced to none.  Be careful though, if anything when wrong during the commands being executed in the redirect body, you won't know about it.

 Regarding reading/writing files, it is pretty simple to add compression to the mix.  For instance:

 ### To read a file that might be gzipped:

 if {[file extension $fileName] == ".gz"} {

   set inFile [list | gzip -dc $fileName]

 } else {

   set inFile $fileName


 if {[catch {open $inFile r} IN]} {

   ... do any cleanup necessary, then error gracefully.

   error $IN


 ### To gzip an output file (make sure $fileName has .gz at the end):

 set outFile [list | gzip > $fileName]

 if {[catch {open $outFile w} OUT]} {

   ... do any cleanup necessary, then error gracefully.

   error $OUT


 Don't forget to close your file handles using the 'close' command.



By BobD on February 25, 2010
Awesome tips, Jason.  Very useful.
Your use model of redirect will be useful in sharing with R&D how the more advanced options are used in practice.  I'll pass this along to them as it will help improve the documentation when redirect becomes officially supported.

By suhas on September 8, 2010
How do we redirect the given command into a file ??
get_pins -of_objects  CELL_NAME

By BobD on October 14, 2010
Sorry suhas - I missed your comment for some time. Try this:
redirect {query_objects [get_pins -of_objects CELL_NAME]} (greater than) filename.txt

By Khandaker on March 9, 2011
Hi Bob
Can the command output be redirected to a variable?

By BobD on March 10, 2011
Currently, Encounter's redirect command doesn't support redirection to variable. I'll try to get it enhanced so it can do so.
Thanks for asking!

By BobD on March 11, 2011
Good news - in EDI 10.1.USR1 redirect supports redirection to variable. It's not documented yet but here's the syntax:
redirect {command} > &variable_name
For example:
redirect {verifyGeometry} > &verify_geometry_output
puts "$verify_geometry_output"
Hope this helps,

By John on September 7, 2011
Hi Bob,

Thanks for the comment! Great to hear that the redirect works with variables. I've given it a try, and it works on the command line, but not within a procedure (proc). Is there a workaround to use redirect within a proc?



By BobD on September 7, 2011
Hi John,
I see same here. Let me check with R&D and get back to you. Thanks for the comment!

Leave a Comment

E-mail (will not be published)
 I have read and agree to the Terms of use and Community Guidelines.
Community Guidelines
The Cadence Design Communities support Cadence users and technologists interacting to exchange ideas, news, technical information, and best practices to solve problems and get the most from Cadence technology. The community is open to everyone, and to provide the most value, we require participants to follow our Community Guidelines that facilitate a quality exchange of ideas and information. By accessing, contributing, using or downloading any materials from the site, you agree to be bound by the full Community Guidelines.