Choosing Perl/Python for my particular niche

[Fred Ma]

Hi, Paddy,

Wow, there's more information coming in than I expected.  Having
a bit of a nonengineering day (at least not at the ground level)
keeping up.  I did ask for it.

Paddy McCarthy wrote:
> 
> Hi Fred,
> If there are particular C/C++ packages of algorithms that you use then
> you might try searching for the package name +python on the web. You
> might find someone who has already turned the library into aPython
> module.

Actually, verilator (does verilog to SystemC, which is a C++ library
that provides HDL simulation capability) is a Perl-based module.

As for the glue functionality I need to modify the my original verilog
source, there's no specific functionality.  I'm still trying to think
of ways in which to modify to code to work around the translation
limitations of verilator.  So the filter will be very much ad-hoc.

> There are several Scientific libraries for Python that have good
> graphing capabilities as well as speed advantages for certain
> operations. - Try installing the Enthought Python distribution for
> windows at: http://www.enthought.com/python/
> 
> Another good page is ScriptEDA:
> http://www-cad.eecs.berkeley.edu/~pinhong/scriptEDA/ - I was using the
> gate-level verilog parser a month ago.

Wow.  The screen shots on for enthought are impressive.  The software at
scriptEDA reminds me that I'm an a newbie in this area.  The level to
which interfacing environments and languages have been brought boggles
the mind.  I think that I need to take a bite of Perl and/or Python
before I even consider looking at the offerings there with any degree
of appreciation.  For the computation engine and post-process/graphing,
I'll stick with C++/matlab for now, due to lack of thesis time, and
because I've got a familiar system (or "idiom"?) setup to use them
together.  As I mentioned in another post, I'll start with Perl as
the starting point, and keep tabs on Python, something that is feasible
because of its readability.

> On Scripting language choice, I find TCL to be in many EDA tools, but
> its datastructures and syntax  make it a language I use when I have
> to, rather than a language of choice.
> 
> Perl IS used a lot in EDA but I like to think of it as being dangerous
> in a lot of hands as great Engineers start scripting larger and larger
> applications in Perl and usually end up with something that is hard to
> maintain and hard to write. Perl does have its sweet spot - I do like
> the `perl -p -i -e` mewthod of making sed like alterations to files
> in-place, butthe languages support for subroutine arguments - compared
> to Pythons; and the need to compute and pass around references to
> lists and hashes for simple nested datastructures - things like that
> shout small programs only to me.

I got the same impression, but there have been other explanations given
in this thread for the unweldiness of big projects, as well as the fact
that this is not universal.  Myself, I will be using "P..." for glue
functionality, so I won't run the risk of creating dangerously
unmaintainable code (finger crossed here).  Besides, it's for the thesis,
which has to be finished soon, so I won't have the problem of looking
back a ways to figure out code written long ago.  By the time I get to
an industrial situation (fingers crossed, since jobs are leaving North
America), I hope to have a bit for breathing time to ramp up on Python.

> Python is my language of choice for a large amount of programming in
> the EDA field (when given the choince :-).
> 
> Perl has a large library, Python has a large library - what you need
> to do is do some web searches for libraries in your field to see which
> is more appropriate -

Well...I did it...verilog to SystemC boils down to verilator unless one
has money to shell out.  Despite its professed limitations, I am still
astounded to read even the help pages.  That degree of sophistication,
for free.  Kind of makes the thesis look like small time, though of
course, the challenges are of a different nature.

> When I have to write an algorithm from scratch then I do it in Python.
> It does get out of the way and allow me to concentrate on the
> algorithm most of the time. (Although I wish it had constrained random
> generation of integers like Vera or Specman :-).
> 
> I hope I've helped,  Paddy.

A great deal.  Thanks.

Fred