Path: usenet.cise.ufl.edu!huron.eel.ufl.edu!usenet.eel.ufl.edu!uky.edu!stdio!209.155.56.21.MISMATCH!pln-e!extra.newsguy.com!lotsanews.com!howland.erols.net!ais.net!news1.chicago.iagnet.net!streamer1.cleveland.iagnet.net!qual.net!iagnet.net!207.99.5.192!nac!nntp.teleport.com!news.teleport.com!not-for-mail
From: "Gary Spivey" <[email protected]>
Newsgroups: comp.lang.perl.announce,comp.lang.perl.modules
Subject: EP3 - The Extensible Perl PreProcessor
Followup-To: comp.lang.perl.modules
Date: 26 Mar 1998 19:18:43 GMT
Organization: Erol's Internet Services
Lines: 68
Sender: [email protected]
Approved: [email protected] (comp.lang.perl.announce)
Message-ID: <[email protected]>
NNTP-Posting-Host: gadget.cscaper.com
X-Disclaimer: The "Approved" header verifies header information for article transmission and does not imply approval of content.
Xref: usenet.cise.ufl.edu comp.lang.perl.announce:29 comp.lang.perl.modules:610

Announcing EP3 - the Extensible Perl PreProcessor.
(Text::EP3)

For those in the perl arena, if you have need of a preprocessor that uses
perl - here is one ...
The unique aspect is its extensibility - every directive is simply a perl
method. As perl blocks can be evaluated within the text being processed, new
directives can be embedded in the code itself (also via outside modules if
desired).

For those in the HDL arena,
 This code was written to provide a preprocessor for verilog (will be
equally as useful for VHDL). Why another preprocessor? I wanted something
that would let me specifiy port lists in one location rather than the 10-15
required in a module and its test bench. By declaring a signal directive, I
was able to define port lists in many different formats and have them
automatically processed in both the test bench and the module file. The
include directive has been modified so that optionally, only specific
portions of code will be included. This is useful for including parameters,
functions, port list specifications, whatever - without the need to cart
around some extra file (functions.v, etc.). Also, all of the evaluations are
done by perl - so an eval directive gives you full use of perl (so logs and
base two thingys can be calcluated in your code - good for bit widths). As
the if structures also use perl, you can do a whole lot more than simply if
A==B, you can do checks to see if files exists for inclusion - like "if -e
file.con" for including constraint files. Comment processing can be turned
on and off so that you don't accidentally blow away something in an embedded
synopsys file.

If you do the test bench and module correctly, you can have modules where
you specify port list is one spot, the behavioral code itself, and the
stimulus in the test bench. Everything else can be autogenerated ... no more
output/input/reg/wire/reset/display/do it again in the test bench/initial
values/  etc. One spot. The way it should be. The new verilog98 should
obviate the need for a little of this, but not enough.

Another nice feature is the ability to embed perl blocks in the code. More
than just a generate. A lot more. I used it to define a hash table for a
fully paramterized wallace tree multiplier. More than I could do with a
generate and/or for loop.

Anyway, for those who might find it useful, it is available on CPAN as

Text::EP3

For the verilog extensions (and a few other verilog directives) you also
need

Text::EP3::Verilog

For those who can't yet navigate CPAN, these can also be found for the time
being at

www.ee.umd.edu/~spivey

Should any VHDL users care to submit VHDL directives, I would be more than
happy to include them in another release. The same goes for any more verilog
directives ...

Cheers,
Gary Spivey
DOD
[email protected]

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.