SPP Frequently Asked Questions
+Why did you write SPP?
+Can Synopsys do anything to help your cause?
+Can Synopsys do anything to help your cause? (Part 2)
+What platforms has it been verified that SPP runs on?
+Why can't Term::ReadLine::Gnu find my libtermcap or libcurses?
+I installed everything ok, but it won't run, what should I do?

Q: Why did you write SPP?
A: People get into heated arguments over which is better, Tcl or Perl. I'm no Perl bigot, although I must admit that I prefer Perl and I've written many more lines of Perl than Tcl. I can certainly understand why Synopsys choose Tcl over Perl. Its interface to C is more straight-forward, it's more easily embeddable and more self-contained.

The problem is that chip designers love Perl! A completely unscientific survey of chip designs (including ones that I've worked on) shows that most chips are held together by vi (or, if I might suggest Vim), Perl, string and paperclips. Chip designers love Perl because they have to run 18 different CAD tools each of which outputs its results in an arbitrary text format and Perl is the only language suitable for gluing them all together. Associative arrays are king. Perl is write-only? You bet!! Why does a script need to be readable if it's going to be less than 50 lines and run only once -- by its author no less!? Who in their right mind would write a 50 line throwaway Tcl script unless they didn't know Perl? No one I know.

Getting back to the question at hand, I wrote SPP to make my life easier. I wanted to characterize all the cells in the chip I've been working on. I noticed that Synopsys had all the information there, but it wasn't very manageable. I remembered hearing about Steve Golson's dc_perl and I downloaded it. From there, I quickly added the Term::ReadLine::Gnu interface and I was off. After about three total re-writes (the original version, like Steve's dc_perl, was based on the dcsh version and only wrapped around dc_shell). Along the way, I used SPP to extract the clocktree from our chip. Using the speedy pt_shell, I was able to turn an hour long job into a 90 second script.

Q: Can Synopsys do anything to help your cause?
A: Yes!!!

As noted on this page, running a tight loop over any kind of channel is time consuming. To really fix the problem, there are two options, both of which require Synopsys' help.

1) Embedding a Tcl interpreter into Perl

I mention this method first because it's the cleaner way to go in my mind, but ultimately less likely to occur. Conceptually, it's very easy to explain. Synopsys creates a libsynopsystcl.so which basically transforms their executable into a loadable share object. From there, we could use an already existing CPAN Tcl module to link Perl into Tcl. This would be really easy.

No chance in hell, right?

Well, maybe. I could understand that Synopsys wouldn't create a libsynopsys.so, exposing their C API, but what about just the Tcl part? Haven't they already created an interface between their C functions and the embedded Tcl interpreter? If they could create a libsynopsystcl.so that exposed the Tcl interface but hid the C interface, maybe they would do it. Dare to dream!

2) Embedding a Perl interpreter into Tcl

A more likely to occur but less clean method would have Synopsys simply upgrade the embedded Tcl they use to 8.0 or later. Tcl8.0 and beyond supports the loading of shared objects themselves. If this were to occur, one could conceive of creating a new Tcl command named perl_go. This new command would never return and would initiate a Perl interpreter and run Perl code. Using the aforementioned CPAN Tcl module, you would then create Perl function calls that would go back into the Tcl world. So isn't this just the same thing as my previous suggestion? I'm not totally sure. If it gives the same visibility as loading a libsynopsystcl.so, then yes, but it might make Synopsys more comfortable because they're only distributing an executable.

The Bottom Line

Either of these solutions will drastically speed up the Perl because it would turn a time consuming pty communication into at most a few function calls.

The bottom line is that these two previous suggestions will probably work, but are really just speculation by me and my officemates. I'd love to hear opinions on whether you think this will/won't work or is a good/bad idea.

Q: What can Synopsys do to help my cause? (Part 2)
A: Starting up SPP is tricky. It's a perl script that creates a pty and forks a synopsys process to communicate with that pty. For everything to work correctly, the synopsys process must be the direct child of the perl script. Unfortunately, because of the way that most synopsys products are written, this isn't the case. Here is the contents of the standard dc_shell script:

platform="sparcOS5"; synopsys_root="/cad/synopsys"; exec_name="/cad/synopsys/sparcOS5/syn/bin/dc_shell_exec"; if [ T"${LD_LIBRARY_PATH}" = T"" ] ; then LD_LIBRARY_PATH=.:${synopsys_root}/${platform}/dcm else LD_LIBRARY_PATH=.:${LD_LIBRARY_PATH}:${synopsys_root}/${platform}/dcm fi export LD_LIBRARY_PATH ${exec_name} -r ${synopsys_root} "$@"
Notice the last line? The synopsys process is simply spawned and not exec'ed by the sh script. This is bad because the sh process will sit in between the perl script and the actual synopsys program. Because of this, SPP must open up the dc_shell script, parse it without executing it, and execute the process directly. This sucks, is fragile and makes me mad. All that Synopys has to do to fix this is change the last line of the script above to this:
exec ${exec_name} -r ${synopsys_root} "$@"
and all my problems will go away. Furthermore, if every script that started Synopsys programs follwed this convention, then all of these programs would work seemlessly with SPP. I say this last point because a number of people have sent emails with questions about running dc_shell from either a perl script or a tcsh script.

Q: What platforms has it been verified that SPP runs on?
A: The following configurations have been verified:

Architecture OS Perl version ReadLine version
Sun Solaris 2.6 5.005_3 4.0
Sun Solaris 2.6 5.004_4 2.2
So far, I've had a terrible time getting SPP to run on either HP or SGI machines. It's had more to do with IO::Pty or Term::ReadLine::Gnu not building correct than SPP, but nonetheless, SPP is stopped cold. If you have a HP, SGI, IBM, or IBM machine and can't get SPP to work, please let me know! I want to make it work! I feel confident that it should work on most flavors of Solaris, but let me know about that too.

Q: Why can't Term::ReadLine::Gnu find my libtermcap or libcurses?
A: The Makefile.PL for Term::ReadLine::Gnu has a bug in it where it won't find your libtermcap or your libcurses if they are shared objects (end in .so) and not static libraries (end in .a). The fix is to edit the Makefile.PL file and explicity assign the variable $TERMCAP_LIB to either -ltermcap or -lcurses depending on which one you have.

Q: I installed everything ok, but it won't run, what should I do?
A: The problem could be that Perl can't find the libraries or that SPP has had an error. Does the error message say?

Can't find <filename> in @INC: <path>
If so, you have a Perl problem and you should talk to your local system administrator. If you think it's a SPP problem, run the following command and send me the output:
dc_perl -verbose 8