Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   VHDL (http://www.velocityreviews.com/forums/f18-vhdl.html)
-   -   Request for feedback: proposed new Perl modules to aid VHDL projects (http://www.velocityreviews.com/forums/t55862-request-for-feedback-proposed-new-perl-modules-to-aid-vhdl-projects.html)

Michael Attenborough 02-24-2006 02:52 PM

Request for feedback: proposed new Perl modules to aid VHDL projects
 
I have a set of Perl modules that I have developed, originally for my own
needs,
to help build and compile VHDL projects with the ModelSim simulator.
I have posted in comp.lang.perl.modules mainly for feedback on module
naming, and I'm also posting here to check there is a need for these
modules, and that I'm not otherwise wasting my time.

What the module set does (general)
===
* Performs a minimal recompile of a VHDL project using ModelSim, recompiling
only those design units which have changed, and those which depend on them.
No need to write and maintain compilation scripts or Makefiles.
* Feeds source files through a preprocessor if wanted (preprocessors are
selected by the first line of the source file, and are implemented as
pluggable modules).
* References any compiler errors back to the correct source file and line
number.
* Component declarations can be automatically inserted, removing the need to
cut-and-paste each time an entity is changed.
* Compiler options can be set using special commands in comments in the
source files

What the module set does (detail)
===
To use the modules you need to create a "project" object, and tell it the
filenames of the source files that you want it to work with, and locations
of some working directories. To do a project build, the project object
needs to go through two stages, a "generate" stage and a "compile" stage.
The "generate" stage involves finding which of the source files have
changed, by checking modification times, and where needed passing them
through a preprocessor and then splitting the code up into individual files
for each design unit. Component declaration insertions are done as a second
pass (this is not a preprocessor function).
The "compile" stage looks at the ModelSim library data to find dependencies
between design units, and to identify the compiled data file for each design
unit, then it calls the ModelSim compiler to recompile all the out-of-date
design units.

The program design is UI-agnostic: status reports are done via callbacks,
and errors via exceptions (well, it croaks). I started writing a Tk front
end, and this was fine, but in practice I have found it more useful to just
have a perl script to update the source files (add all files from my 'src'
directory) when I need to, and for general development I just hit F7 in my
text editor (I use SciTE) and have that set up to do the "generate and
compile". I can then double-click on any error messages to jump to the
offending line in the source file.

Module structure and proposed names
===
Generally, I'm proposing to put reusable VHDL-language-related components
under Hardware::Vhdl (this hierarchy already exists, and contains the only
VHDL-specific module on CPAN) and the various components of my build tool
under Hardware::Vhdl::Automake.
My development modules are called:
Hardware::Vhdl::Lexer - returns lexical tokens one-by-one from a VHDL
source file. This is needed by my automake tool, but may be useful for
other purposes (like a Hardware::Vhdl::Tidy module that I have in mind)
Hardware::Vhdl::Automake::Project - defines a project class; instances
of this hold information about source files, design units, working
directories and compilation status, using instances of some of the classes
below.
Hardware::Vhdl::Automake::SourceFile - defines a class that stores
information about a source file, and methods do split it into design units,
etc.
Hardware::Vhdl::Automake::DesignUnit - defines a class that stores
information about a design unit, its compiler options and its compilation
state
Hardware::Vhdl::Automake::UnitName - defines a class to store and
manipulate design unit names
Hardware::Vhdl::Automake::PreProcessor - deals with preprocessing files
(calls preprocessor plugins if requested) and returning them line-by-line
Hardware::Vhdl::Automake::PreProcessor::* - preprocessor plugins. I
will include one called Cish[1] that is like the CPP preprocessor, and it
should be possible to write plugins to call m4, Text::CPP, Text::EP3 etc.
Hardware::Vhdl::Automake::CompileTool - base class for compiler plugins
Hardware::Vhdl::Automake::Compiler::ModelSim - a compiler plugin for
ModelSim.
All of these use an OO API. All the classes do provide methods as well as
data storage.

Scope
===
The modules currently only support the ModelSim simulator, because that is
the one that I have, but I've tried to structure things so that one can plug
in modules to support other compilers (or possibly synthesis tools).
The use of Verilog source files is not currently supported: it's mainly the
"generate" stage that would need to be added.

So, any comments, particularly regarding the module names? For example,
should I use something other than Hardware::Vhdl, because the tool may
support Verilog too at some point in the future?

[1] I ended up writing this because Text::CPP doesn't work on Win32, and
Text::EP3 has some important omissions. If it later seems worthwhile to
create Text::CishPP (or whatever I call it) as a generic preprocessor then
Hardware::Vhdl::Automake::PreProcessor::Cish will become just a plugin
interface to it.





Mike Treseler 02-24-2006 04:03 PM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 
Michael Attenborough wrote:
> I have a set of Perl modules that I have developed, originally for my own
> needs,
> to help build and compile VHDL projects with the ModelSim simulator.
> I have posted in comp.lang.perl.modules mainly for feedback on module
> naming, and I'm also posting here to check there is a need for these
> modules, and that I'm not otherwise wasting my time.


Thanks for sharing your work.
Many in this group have expressed interest in preprocessing.
Check the link below for more ideas on
project scope definition, multiple simulator support
and makefile generation.

http://opensource.ethz.ch/emacs/vhdl-mode.html

I use vhdl-mode macros from the command line in my test scripts.
You could borrow a few features from it.

-- Mike Treseler

Allan Herriman 02-24-2006 07:01 PM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 
On Fri, 24 Feb 2006 14:52:58 -0000, "Michael Attenborough"
<michael_aht_brainboxes_doht_com@say.it> wrote:

[snip]
>* Component declarations can be automatically inserted, removing the need to
>cut-and-paste each time an entity is changed.


Do people still use these?

I stopped using component declarations when tools started to support
VHDL-93 properly (in about 2000?).
There are obvious exceptions when you really need to use a component
declaration, e.g. black boxes and some configurations, but these are
/relatively/ uncommon.

Allan

Mike Treseler 02-26-2006 06:35 PM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 
Allan Herriman wrote:

> Do people still use these?


Yes, the average designer gets
training and examples from
brand X and A, who have a vested
interest in black boxes.

The common response I get from
designers I know is,

"Yes, I have heard about direct instances,
but I won't have time to try anything
new until I finish $some_project"

So it goes. Creatively wasting time
is really the only way to ever catch up.

-- Mike Treseler

Allan Herriman 02-26-2006 07:24 PM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 
On Sun, 26 Feb 2006 10:35:36 -0800, Mike Treseler
<mike_treseler@comcast.net> wrote:

>Allan Herriman wrote:
>
>> Do people still use these?

>
>Yes, the average designer gets
>training and examples from
>brand X and A, who have a vested
>interest in black boxes.
>
>The common response I get from
>designers I know is,
>
>"Yes, I have heard about direct instances,
>but I won't have time to try anything
>new until I finish $some_project"
>
>So it goes. Creatively wasting time
>is really the only way to ever catch up.


At the time, I was fortunate enough to be in a reasonably senior
position in a large group of designers in a large company. It was as
simple as testing it out against the set of tools we used, making some
power point presentations and writing it into what passed for a coding
standard.
Direct instantiation was adopted quite quickly, as all designers hated
component declarations.

Actually, this is probably a good reason to avoid all textbooks and
coding guides from the 1990s. (The same applies to Verilog - there
were some significant fixes to the language in the 2001 edition, and
the old documentation doesn't mention them.)

Regards,
Allan

Michael Attenborough 02-27-2006 09:53 AM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 
"Allan Herriman" <allanherriman@hotmail.com> wrote in message
news:bmluv1dqrhj3qi9te7t67tcnufgfqrre46@4ax.com...
> On Fri, 24 Feb 2006 14:52:58 -0000, "Michael Attenborough"
> <michael_aht_brainboxes_doht_com@say.it> wrote:
>
> [snip]
> >* Component declarations can be automatically inserted, removing the need

to
> >cut-and-paste each time an entity is changed.

>
> Do people still use these?
>
> I stopped using component declarations when tools started to support
> VHDL-93 properly (in about 2000?).
> There are obvious exceptions when you really need to use a component
> declaration, e.g. black boxes and some configurations, but these are
> /relatively/ uncommon.


Interesting - I got my training from Esperan in 1999 and I don't think that
direct instantiation was ever mentioned. I only came across it when I was
looking though a VHDL reference guide to research my Perl-based build
system. Perhaps I need some update training - I've read the FAQ entry but I
don't understand it (what does it mean to instantiate an "entity interface"
as opposed to an architecture?).

Anyway, to return to the original point, my Perl modules make it easy to do
component declarations if you want or need them, but they are in no way
obligatory.

Michael A



Michael Attenborough 02-27-2006 10:07 AM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:468p3dFa1s99U1@individual.net...
> Many in this group have expressed interest in preprocessing.
> Check the link below for more ideas on
> project scope definition, multiple simulator support
> and makefile generation.
>
> http://opensource.ethz.ch/emacs/vhdl-mode.html
>
> I use vhdl-mode macros from the command line in my test scripts.
> You could borrow a few features from it.


Thanks, that does look interesting.
It's a shame I can't read Lisp, I'd be interested in the algorithm that
parses out the instantiation tree. I thought I might need to do this (and I
may yet, eventually) but for the moment I am cheating and parsing the
ModelSim _info files instead. This restricts me to using ModelSim (which
this is fine for my needs) but has great advantages in simplicity and
probably also in processing speed. It does work across multiple design
libraries, by the way.
I had to parse the _info files in any case, to get the name of the compiled
binary files for up-to-date-ness checking. I'll have to check that my
parsing works across a good range of ModelSim versions.

Michael A



Martin Thompson 02-27-2006 12:36 PM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 
"Mike Treseler" <mike_treseler@comcast.net> writes:


> http://opensource.ethz.ch/emacs/vhdl-mode.html
>
> I use vhdl-mode macros from the command line in my test scripts.
> You could borrow a few features from it.
>


Hi Mike,

I'm intrigued - what do your test-scripts do that vhdl-mode helps
with?

Thanks!

Martin

--
martin.j.thompson@trw.com
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.trw.com/conekt


Allan Herriman 02-27-2006 03:17 PM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 
On Mon, 27 Feb 2006 09:53:04 -0000, "Michael Attenborough"
<michael_aht_brainboxes_doht_com@say.it> wrote:

>"Allan Herriman" <allanherriman@hotmail.com> wrote in message
>news:bmluv1dqrhj3qi9te7t67tcnufgfqrre46@4ax.com.. .
>> On Fri, 24 Feb 2006 14:52:58 -0000, "Michael Attenborough"
>> <michael_aht_brainboxes_doht_com@say.it> wrote:
>>
>> [snip]
>> >* Component declarations can be automatically inserted, removing the need

>to
>> >cut-and-paste each time an entity is changed.

>>
>> Do people still use these?
>>
>> I stopped using component declarations when tools started to support
>> VHDL-93 properly (in about 2000?).
>> There are obvious exceptions when you really need to use a component
>> declaration, e.g. black boxes and some configurations, but these are
>> /relatively/ uncommon.

>
>Interesting - I got my training from Esperan in 1999 and I don't think that
>direct instantiation was ever mentioned. I only came across it when I was
>looking though a VHDL reference guide to research my Perl-based build
>system. Perhaps I need some update training - I've read the FAQ entry but I
>don't understand it (what does it mean to instantiate an "entity interface"
>as opposed to an architecture?).


The "entity interface" is just the list of ports and generics.

The instantiation in your source code looks pretty much the same.

my_label : entity my_lib.my_entity
port map(...);

or
my_label : entity my_lib.my_entity(my_architecture)
port map(...);

instead of

my_label : my_lib.my_component
port map(...);


Pros:
- You don't need a component declaration.

Cons:
- You can't apply a configuration to this instantiation.
- The entity declaration must already be compiled into the library
prior to compiling the architecture which instantiates the entity.
- It doesn't work with black boxes.


>Anyway, to return to the original point, my Perl modules make it easy to do
>component declarations if you want or need them, but they are in no way
>obligatory.


That's good to know.

Regards,
Allan

Mike Treseler 02-27-2006 05:17 PM

Re: Request for feedback: proposed new Perl modules to aid VHDL projects
 
Michael Attenborough wrote:

> Thanks, that does look interesting.
> It's a shame I can't read Lisp,


I have picked up some just by running commands
then looking at the source code. A simple function
is little more than a list of commands in parens.

> I'd be interested in the algorithm that
> parses out the instantiation tree.


Once I have defined the project directories,
vhdl-mode reparses the tree whenever I save
a file or drill down in the browser (speedbar)
This can take a few seconds the first time,
but it is in cache after that. It also
reports duplicate unit names in the message buffer
-- a good verification for QAing the CVS repository.

> I thought I might need to do this (and I
> may yet, eventually) but for the moment I am cheating and parsing the
> ModelSim _info files instead.


vhdl-mode can infer the work directory unit structure
from the instance tree. This is necessary to generate
a Makefile without first doing a compile manually.
This is a huge advantage for testing a multi-user CVS
repository.

> This restricts me to using ModelSim (which
> this is fine for my needs) but has great advantages in simplicity and
> probably also in processing speed.


If you can just cover one, Modelsim is the logical choice.

> It does work across multiple design
> libraries, by the way.


You score one here.
vhdl-mode covers only one library,
so I have to throw the odd "vmap altera_mf work"
into my scripts to cover vendor library references
other than work. I have to watch the message
buffer for unit name collisions that could result,
but so far, these have all been due to
designers checking in the same entity name twice.

> I had to parse the _info files in any case, to get the name of the compiled
> binary files for up-to-date-ness checking.


vhdl-mode defines these targets when I do a
(vhdl-generate-makefile) but leaves the
date-checking up to make.

-- Mike Treseler


All times are GMT. The time now is 01:18 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.