| SPP Frequently Asked Questions | ||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||
|
Q: Why did you write SPP? 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? 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 PerlI 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 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) Notice the last line? The synopsys process is simply spawned and not exec'ed by theplatform="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} "$@" 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:
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.exec ${exec_name} -r ${synopsys_root} "$@" Q: What platforms has it been verified that SPP runs on? 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? Q: I installed everything ok, but it won't run, what should I do? 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:Can't find <filename> in @INC: <path> dc_perl -verbose 8 | ||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||
|
| ||||||||||||||||||||||||||||
