( ESNUG 401 Item 9 ) --------------------------------------------- [10/17/02]
Subject: EE Times Censorship & Perl vs. Tcl/Tk vs. Awk vs. Python vs. Ruby
> It's sort of like having a venereal disease. When you do crisis
> intervention consulting (like I do) for chip design projects, you get to
> see everything. And one of the most embarrassing problems I've found at
> client sites is when some of their key engineers on a troubled project
> really don't know Perl. (You may balk and exclaim that this is impossible
> because Perl scripts are the bread and butter of chip design, but that's
> what makes this problem so embarrassing.) Like a doctor treating VD, one
> has to treat this problem very discretely -- which means I give those
> clients my sequential list of recommended reading so they can quickly and
> quietly learn Perl at home.
>
> - from "Monkey See, Monkey Do" (original text)
From: Dave Chapman <dave@goldmountain.com>
Hmmm, John. Learning Perl is sort of like getting the clap. Never actually
thought of it that way. I'll have to consider this one very carefully...
- Dave Chapman
Goldmountain Consulting Sebastopol, CA
---- ---- ---- ---- ---- ---- ----
From: Prasad Sakhamuri <prasad@velio.com>
Hi John,
This is so true and so funny (the first paragraph, I mean) I just couldn't
resist forwarding to the entire engineering community in my company. May
your wittisms go forth and multiply. :-)
- Prasad Sakhamuri
Velio Communications, Inc. Milpitas CA
---- ---- ---- ---- ---- ---- ----
From: Dennis Brophy <dennisb@Model.com>
Hi, John,
WOW! I just read the EE Times print version of your column when I saw your
email with the same title. In the EE Times print version of your column
the editors completely removed your reference to VD!!!???
Now I know how the kids feel when they have me play their rap music in the
car. Just about every other word is censored on the radio and they can't
wait to go out and buy the CD to hear the real thing. Although censorship
can be a bad word, it does drive behavior. In the case of the kids, it
drives them to buy the actual CD. And I'm certain the recording industry
marketing brain trust enjoys that. In your case, it might actually drive
one to only read your email version. I wonder: is that what EE Times wants?
- Dennis Brophy
Mentor / Model Tech Wilsonville, OR
---- ---- ---- ---- ---- ---- ----
> Here again you want to focus on regular expressions & pattern matching in
> chapter 7. Perl's greedy matching is it's biggest strength, but it's also
> the most obtuse part of the language. It's here where you'll get your
> first insights into those occult regex incantations that the UNIX man pages
> so often reference. (For more advanced regex, I recommend "Mastering
> Regular Expressions" by Friedl, but be warned that it's ugly. You should
> also be warned about the "Perl Cookbook" by Christiansen. He likes to
> drift off into UNIX arcana a bit too much for practical use, but on
> occasion he can help.)
From: David Weisgerber <A.Weisgerber@infineon.com>
I don't think so. The Perl Cookbook rules! I own it myself. I think it is
one of the best computer books available because the examples are more
practical than those listed in other books. (Who wants to hardcode car
vendors and models to be stored in arrays and hashes? I use to have a
MySQL Server.)
- David Weisgerber
Infineon
---- ---- ---- ---- ---- ---- ----
From: Billy Vitro <bvitro@cisco.com>
OK, John, that does it!
I've generally agreed with you, especially in your "Industry Gadfly"
columns, but this is the last straw...
You have dissed "The Perl Cookbook". Them's fightin' words where I come
from. That is easily the best Perl book I have ever used. It has clearly
written examples, concisely expressed, which show a depth of knowledge of
Perl that is sorely lacking in all three of the other books you cite.
OK, so I won't really go to the mat with you over this, but I've found it
more and more useful the more I write Perl. Which may be the reason you
wouldn't recommend it for people learning the language - you need to know
more than the average bear about Perl than most newbie's have.
- Billy Vitro
Cisco Systems
---- ---- ---- ---- ---- ---- ----
From: Yaron Kretchmer <yaronkretchmer@hotmail.com>
John, No!
The "Perl Cookbook" is by far the best value-for-money Perl book you can
get. It will give some stuff to help you with your chip design, some stuff
to help you with CGI scripting, and some insights into other Perl aracana
so you can help your wife (my wife actually) with her bioinformatics stuff.
Learn Perl first, then get the cookbook and thrive.
- Yaron Kretchmer
---- ---- ---- ---- ---- ---- ----
From: Tomasz Prokop <prokop@lucent.com>
John,
You forgot to mention the camel book everyone uses: "Programming Perl" by
Larry Wall, Tom Christiansen & Randal L. Schwartz
- Tomasz Prokop
Lucent Technologies
---- ---- ---- ---- ---- ---- ----
From: John Providenza <johnp@probo.com>
John,
Another Perl helper I find invaluable is Swain's "Perl 5 Reference Guide"
that can be downloaded from the web. If you've used Perl as a 'helper',
ie, not your primary language, this cheat-sheet can help you quickly
remember/find some of the obscure variables, etc.
- John Providenza
ProBo
---- ---- ---- ---- ---- ---- ----
From: Eric Hawkins <eric.hawkins@philips.com>
Hi John,
An excellent way to learn Perl, in conjunction with the books you listed,
is to take a good Perl script and add your comments to each line. When I
first started at Motorola I had a DSP verification environment dumped into
my lap and was told to make it run. It was about 1000 lines of Perl that
generated random assembly instructions according to rules defined by the
instruction set architecture. I did not know Perl at the time. I copied
the scripts into a temporary directory, and line-by-line began to comment
the code. I call it "Perl boot camp."
The only book I used was "Programming Perl" by Wall, Christiansen and
Schwartz. Sure enough, I learned Perl!
Caveat: Make sure you start with good quality Perl. The guys over at Perl
Monks have a good handle on things:
http://www.Perlmonks.org/index.pl?node=Code%20Catacombs
Follow their guidelines for programming style and you will not go wrong.
- Eric Hawkins
Philips Semiconductor Duluth, GA
---- ---- ---- ---- ---- ---- ----
From: Sy Wong <sywong@hermix.markv.com>
John,
Are you kidding or serious about "key engineers on a troubled project
really don't know Perl" with the piles of books one must read. If
serious, may be you should say more in ESNUG Posts how Perl is used and
what for. I am a hobbyst IC designer that cannot afford Verilog/VHDL
with the necessary tools and use a simple ISO standard programming
language that is not Perl.
- Sy Wong
MarkV
---- ---- ---- ---- ---- ---- ----
From: Premysl Vaclavik <premysl.vaclavik@analog.com>
Hi, John,
I like the survey of the Perl books you have written, but I do not share
your view about the "bread and butter". I would say there is also awk,
nawk, mawk and gawk. If you program your scripts in shell and awk, you
can do the same for the chip design scripting as when you use Perl. If
you want to filter the data approaching 2G and above, the line oriented
awk is in my opinion better. If you want to program for interactive
processes, you may choose expect. So, in my opinion the most important
thing is the designers ability to write scripts rather than to be fixed
to the syntax of one scripting language.
- Premysl Vaclavik
Analog Devices
---- ---- ---- ---- ---- ---- ----
From: Victor Chen <victor@vitesse.com>
Mr. Cooley,
How about Tcl then? It seems to be a trend now for EDA tools to use Tcl as
their user-interface platform. If I don't mistake, Tcl can also do lots of
wonderful stuff Perl has.
- Victor Chen
Vitesse Semiconductor
---- ---- ---- ---- ---- ---- ----
From: Richard Auletta <rauletta@orci.com>
John,
Learning Tcl/Tk is infinitely better for the engineers in the EDA field.
Reasons are many, best reason is almost every EDA tool is built on Tcl/Tk.
Good chance if they know Tcl/Tk the can skip the Perl script all together by
extending the tool with both simple scripts and complex scripts and GUIs
(and accessing the database extensions of tools like PrimeTime and
First Encounter). As to regexp, Tcl regular expressions are implemented
using the package written by Henry Spencer, based on the 1003.2 spec and
some (not quite all) of the Perl5 extensions (thanks, Henry!).
Perl is really old news, and for the average DA/ASIC/FPGA/SoC engineer, Perl
is probably the worst scripting language they could try to learn, for as
many reasons as Tcl/Tk is the right first language.
I agree with the concept of the article, that the problem is VERY wide
spread, can be largely blamed on Universities that teach what is easy to
teach, not important to learn, but your suggestion of Perl in fact makes
the problem worse by offering a language difficult to learn and impossible
to read and maintain. If C got its name for the grade it received in a
compilers course, then the P in Perl must have come from the Pass/Fail it
received.
- Rich Auletta
ViaWest Boulder, CO
---- ---- ---- ---- ---- ---- ----
From: Randy Findley <Randy_Findley@LayerN.com>
John,
I would still take a hard core Verilog or VHDL coder with Tcl skills over
a Perl guy any day of the week.
Still I admit, Perl is an excellent language.
- Randy Findley
Layer N Networks Austin, TX
---- ---- ---- ---- ---- ---- ----
From: Erich Whitney <ewhitney@axiowave.com>
Hi John,
Really great advice. But I want to pick on one thing you said. I think the
best feature in Perl to exploit second to regexp is associative arrays. If
you're trying to do any sort of data processing in Perl and you're not using
associated arrays, you're working too hard. Spend the extra half hour it
will take you to figure them out and you've just justified all the time you
spent learning Perl.
- Erich Whitney
Axiowave, Inc.
---- ---- ---- ---- ---- ---- ----
From: [ The Gerbil Boy ]
Keep me anon if you're going to post, otherwise its for your consumption
only. We recently got a chip back in the lab. We're still running random
tests on it. I recently noticed that all of the seeds are even! The
random seed algorithm failed to take into account that Perl was only
compiled with 15 "randbits"!
- [ The Gerbil Boy ]
---- ---- ---- ---- ---- ---- ----
From: Jesse Jenkins <Jesse.Jenkins@xilinx.com>
To me, it is a sad thing that you have to know Perl to design chips.
What is the point of CAD?
- Jesse Jenkins
Xilinx
---- ---- ---- ---- ---- ---- ----
From: William Lenihan <wlenihan@raytheon.com>
What is Perl?
I'm an FPGA designer using ModelTech for simulation, Synplify for synthesis,
and Xilinx Alliance for P&R, static timing, floorplanning, etc. Since I see
no 'holes' in my design flow, what, if anything, would Perl do for me? If
it's not applicable in the realm of FPGA design, then what is it about chip
(read "ASIC"?) design that demands it's use?
Is Perl related at all to "Tcl/Tk"?
- William Lenihan
Raytheon
---- ---- ---- ---- ---- ---- ----
From: [ Clifford, the Big Red Dog ]
Hi John,
Perl is fine, but in the FPGA world I hardly ever use it. I learned it when
I was doing ASIC's. Lately, I've used Tcl/Tk to control a simuation, but I
don't know it well. I seem to be the only FPGA designer here that knows
even a little Tcl/Tk, or Perl. We use Xilinx tools.
Question: Is Tcl/Tk worth learning, and why? Or should we use Perl, and
why? What good is either one? Our tools, (including EMACS) seem to have
all the functionality we need. Color me anonymous.
- [ Clifford, the Big Red Dog ]
---- ---- ---- ---- ---- ---- ----
From: Vladimir Orlt <Orlt.V@ems-t.ca>
Hi John,
What do you think of Tcl? It's used by most tools, so it seems more useful.
I don't know the limitations of Perl vs. Tcl.
- Vladimir Orlt
EMS Technologies Ste. Anne de Bellevue, Quebec
---- ---- ---- ---- ---- ---- ----
From: William Liao <wliao@amcc.com>
John,
I think Tcl is as important as Perl, if not more important. I find Tcl
easier and faster to navigate, examine, or modify a design in Design
Compiler or PrimeTime, and one must know Tcl well to do that.
- William Liao
AMCC
---- ---- ---- ---- ---- ---- ----
From: Phil Tomson <ptkwt@aracnet.com>
John,
Perl was my 'language of choice' for many tasks for several years, but
after learning Ruby I find I don't use Perl anymore. It's a bit like how
I never used Awk after learning Perl. Ruby is a sort of cleaned up Perl
which is much more object oriented and more consistent. Some have called
Ruby Perl's younger prettier sister. ;-) Ruby also has all the regular
expression power that Perl has. Check it out:
http://www.ruby-lang.org
http://rubycentral.com (the book "Programming Ruby" is available
free at this site)
http://rubygarden.org
You may not have heard much about Ruby yet, but it is gaining users. I
recently contracted at Intel and discovered that several design groups
there have dumped Perl and are now using Ruby instead.
- Phil Tomson
Aracnet
---- ---- ---- ---- ---- ---- ----
From: Steve Waterbury <waterbug@beeblebrox.gsfc.nasa.gov>
John,
You wrote that "Perl scripts are the bread and butter of chip design."
I didn't know that (but then I'm not a chip designer). My thing is
developing software to support engineers of all shapes and sizes. I'd
be interested to find out if you've ever tried Python ( http://python.org )
and if so, what your opinion is. Languages are a religious topic, of
course, so I would not try to convert you, but I'd be interested in your
view of the pros and cons anyway. I've found Python code to be generally
clearer and easier to maintain than Perl. And Python's built-in O-O
nature appeals to me (but not to everyone! ;^).
- Steve Waterbury
NASA
---- ---- ---- ---- ---- ---- ----
> Ignore the remaining 14 chapters of this book because most chip designers
> won't be dabbling in XML, Java, databases, HTML, object oriented
> programming, associative arrays, nor downloading fancy CPAN packages just
> to clean up some PhysOpt DEF output for Silicon Ensemble to read.
From: Mysore Sriram <mysore.sriram@intel.com>
Hi John,
I'm surprised you club associative arrays into the same category as HTML,
etc. For almost any non-trivial application, associative arrays are
invaluable for making the script efficient (O(N^2) algorithms become
almost linear time, etc.) Perl would be useless to me without them.
- Mysore Sriram
Intel Corp.
---- ---- ---- ---- ---- ---- ----
From: Wilson Li <W.Li@AcceLight.com>
Why do you say chip designers don't need associative arrays? I think this
is one of the most useful Perl constructs. You can easily create a lookup
table on the fly.
- Wilson Li
AcceLight
---- ---- ---- ---- ---- ---- ----
From: Matt Welland <mattwell@us.ibm.com>
John,
I don't have the "Perl for Dummies" book to check exactly what is in the
chapters you are talking about, but did you really mean to imply that
associative arrays are not something Designers necessarily need to master?
I find associative arrays to be almost as indispensable as regexes even for
everyday tasks and I would teach them very early on. So long as you don't
get into complex de-referencing, associative arrays are quite intuitive and
easy to learn and use. The rest of your list of stuff not to learn I'd
agree with.
- Matt Welland
IBM Essex Jct, VT
---- ---- ---- ---- ---- ---- ----
From: Paul Gerlach <paul.m.gerlach@exgate.tek.com>
Hi John,
I'm sure you'll be getting lots of responses of the form, "What? How can you
think chip designers won't be using [insert feature here] in Perl? I use it
all the time!"
Well, here is (possibly) your first: Ignore associative arrays? These are
hashes, right? I use them all the time! One of the best features in Perl
for the things I do as a chip designer are hashes (and it was a great day
when Perl added multi-dimensional data structures). It may not be as
important as regex knowledge, but it sure is important to me.
Interesting, I have never read the books on your list. I guess I'm an old
school camel man.
- Paul Gerlach
Tektronix, Inc. Beaverton, OR
---- ---- ---- ---- ---- ---- ----
From: Richard Gordon <rgordon@terasystems.com>
John,
First, couldn't agree with you more, Perl is a bread-and-butter tool for
chip design. I make sure all my new hires know Perl to some degree. DBs,
HTML, XML, object oriented programming, CPAN, etc. are not requirements.
Couldn't disagree with you more, "most chip designers won't be dabbling
in ... associative arrays ..." I'll take an extreme position: If you
don't know associative arrays you don't know Perl. Associative arrays,
a.k.a. hash tables, is the single most important data type in Perl. I
would even go so far as to say that if you wanted to fully capture every
attribute of a chip using Perl you can do so with little more than a
hash of a hash of a hash.
For example, a simple Perl quiz I give to prospective employees is to
parse a Verilog gate-level netlist and print a count of every type of
gate in a chip. The heart of this function is a hash table and takes
just 1 line of code to be completely general purpose (no need to store
lists of valid gate types or anything like that). To do the same thing
without hashes is many orders of magnitude more complex and virtually
impossible to make general purpose.
- Richard Gordon
Tera Systems
---- ---- ---- ---- ---- ---- ----
From: Chris Gori <cgori@Sanera.net>
John,
I hope _you_ didn't ignore the part on associative arrays. You can make
some pretty kick-ass netlist handling tools using them (can you say "use
instance path to lookup module reference"? -- I built an entire automated
IPO flow out of associative arrays). On the rest of your column, I agree
100%. It is fairly frightening when ASIC-folks shy away from learning one
of the most powerful tools available to them, but your book list
recommendations are solid.
- Chris Gori
Sanera Systems
---- ---- ---- ---- ---- ---- ----
From: Matt Billenstein <mattb@sjs7.lsil.com>
Hi John,
I couldn't agree more. A healthy dose of software in college and on the job
has been the best preparation for my current "hardware" job.
- Matt Billenstein
LSI Logic Milpitas, CA
---- ---- ---- ---- ---- ---- ----
From: Paddy McCarthy <paddy3118@tiscali.co.uk>
You missed out the question of Perl script maintenance.
You really want to impress on those same engineers that most 'one off'
scripts tend to linger or grow into hard to maintain and re-use
monstrosities. Time spent learning how to write clear, maintainable code
is usually time well spent - same as for your HDL.
- Paddy McCarthy UK
---- ---- ---- ---- ---- ---- ----
From: Paul Zimmer <pzimmer@cisco.com>
John,
I LOVED the monkey-see-monkey-do column! That very day I had been trying
to convince one of our engineers to learn Perl, and we had a good laugh
over the column.
- Paul Zimmer
Cisco
---- ---- ---- ---- ---- ---- ----
From: Matt Jones <matt.jones@cox.net>
Hi, John,
I want to thank you for your INDUSTRY GADFLY column in the 8/12 issue of
EE Times titled "Monkey see, monkey do." I'm a circuit designer in a server
chipset group with a BS in computer engineering, and MSE in electrical
engineering, and am a MBA. Know what I do? I write Perl scripts. The
reason? I'm the only one of twelve engineers in our group that knows how!!
And believe me, they'd crash and burn without me. The problem is that they
don't know it because no one really understands that I do. I'm hoping your
column will help. It's posted outside my cube and I will be sending a copy
of it to my boss before my next review. Thanks!
- Matt Jones Chandler, AZ
---- ---- ---- ---- ---- ---- ----
> ... nor downloading fancy CPAN packages just to clean up some PhysOpt DEF
> output for Silicon Ensemble to read.
From: Mike Klein <mike@kleinnet.com>
John,
I really picked up on this point because one of our P&R engineers is trying
to find exactly what to do to make this flow work. I spent an hour
searching for this package but didn't find it. Are you pulling our
collective legs on this one example, or is there really such a package?
- Mike Klein
[ Editor's Note: No, Mike, there aren't any specific CPAN packages that
I know of to clean up DEF for PhysOpt. I was just giving that as an
example of complexity I didn't need. Sorry if it mislead. - John ]
============================================================================
Trying to figure out a Synopsys bug? Want to hear how 14,488 other users
dealt with it? Then join the E-Mail Synopsys Users Group (ESNUG)!
!!! "It's not a BUG, jcooley@TheWorld.com
/o o\ / it's a FEATURE!" (508) 429-4357
( > )
\ - / - John Cooley, EDA & ASIC Design Consultant in Synopsys,
_] [_ Verilog, VHDL and numerous Design Methodologies.
Holliston Poor Farm, P.O. Box 6222, Holliston, MA 01746-6222
Legal Disclaimer: "As always, anything said here is only opinion."
The complete, searchable ESNUG Archive Site is at http://www.DeepChip.com
|
|
