VHDL mode for emacs (Really: Structural VHDL code...) 
Author Message
 VHDL mode for emacs (Really: Structural VHDL code...)


Quote:

>KM> Does anyone have or know where I could get a vhdl-mode.el for GNU
>KM> emacs ? Anyone using one ?
>Yes.  Please find it enclosed herein.

>Oh, it's close enough to the beginning of the month.  Time to report this
>again, especially since there actually _have_ been some bug fixes and
>enhancements....

Hats off to Todd and friends at Honeywell for a great VHDL mode for emacs,
and for keeping it up-to-date!  However, in the "general philosophy" section
of the posting, I have to comment on a statement made:

Quote:
>#############################################################################
>             GENERAL PHILOSOPHY
>#############################################################################

 much info deleted...

Quote:

> Note that VHDL.EL is written primarily for writing behavi{*filter*}VHDL.
> We contend that structural VHDL should be captured with schematics, as
> pictures are worth many several pages of ugly code.  With that in mind,
> you'll notice there is very little support for port declarations, connection,
> etc.  If you want to write them, I will be happy to add them to the mode.

This is an interesting stance.  One of VHDL's (and Verilog's) major
advantages is the fact that you don't have to rely on schematics,
which are generally non-portable and usually vendor-specific.  Perhaps even
more important, schematics are a maintenance-headache.  I liken it to the
C-versus-assembly language dilema:  You can often write more efficient code
in assembly, but God save you if you need to make changes or change processors
down the road...

We believe the answer is to write small, clean architectures for structural
VHDL code and rely on schematic generation tools if we absolutely have to
"look at a picture."  1000-line structural modules are highly frowned upon.
The intent is to minimize the time required to implement and debug systems
while maximizing future flexibility.  This constraint generally requires that
we write VHDL code using the highest-level constructs possible (which may
degenerate to structural VHDL when writing synthesizable code), and only use
schematics as a last resort.

I'm curious how others feel about this topic.

Mike



Sun, 18 Feb 1996 00:55:04 GMT  
 VHDL mode for emacs (Really: Structural VHDL code...)

Quote:

> much info deleted...and more

>This is an interesting stance.  One of VHDL's (and Verilog's) major
>advantages is the fact that you don't have to rely on schematics,
>which are generally non-portable and usually vendor-specific.  Perhaps even
>more important, schematics are a maintenance-headache.  I liken it to the
>C-versus-assembly language dilema:  You can often write more efficient code
>in assembly, but God save you if you need to make changes or change processors
>down the road...

In general I agree, for time=now!

If schematics are seen to be of general help the 'use VHDL' solution
sounds like: use the worse language, because it's portable etc. I think if
it is commonly agreed that schematics are a basic, generally needed language
(or language aspect) the long term solution needs to be the same as VHDL is
for HDL's: a standard has to be defined (and promoted by a strong party such
as DoD was for VHDL). Maybe here we can learn from EDIF - which as far as I
know has a schematic view?

Quote:
>We believe the answer is to write small, clean architectures for structural
>VHDL code and rely on schematic generation tools if we absolutely have to
>"look at a picture."  [rest deleted]

I'd like to know of such a generator based on VHDL input(?). Best would be if
PD :-). Or at least a good layout algorithm which optimizes for readable
presentation aspects. Any hints?

Quote:
>I'm curious how others feel about this topic.

ok, thats my 2 cents.
tom.
--

phone: +49-231 755 6464, FAX: +49-231 755 6555
T. Dettmer, Dortmund University, Computer Science I, 44221 Dortmund, Germany


Sun, 18 Feb 1996 15:41:25 GMT  
 VHDL mode for emacs (Really: Structural VHDL code...)


Quote:

>> much info deleted...and more

>>This is an interesting stance.  One of VHDL's (and Verilog's) major
>>advantages is the fact that you don't have to rely on schematics,
>>which are generally non-portable and usually vendor-specific.  Perhaps even
>>more important, schematics are a maintenance-headache.  I liken it to the
>>C-versus-assembly language dilemma:  You can often write more efficient code
>>in assembly, but God save you if you need to make changes or change processors
>>down the road...

>In general I agree, for time=now!

>If schematics are seen to be of general help the 'use VHDL' solution
>sounds like: use the worse language, because it's portable etc...

Schematics are indeed useful, as they can convey a great deal of information;
However, using schematics as a design entry methodology may not make sense
over the long-term.  Engineers at today's high-tech companies are expected to:

        1) Create new products in the shortest time possible, and,

        2) Plan for the future by encouraging design portability and reuse,
           thereby allowing future leverage off of today's efforts.

Companies that do not adhere to these principles run the risk of losing
in the marketplace to companies that do (with the inevitable long-term
consequences -- layoffs, internal turmoil, etc.).  If a new product is
designed in a non-portable (or reusable) way, the *true* cost of the next
project can be staggering.  This, unfortunately, is usually ignored
because most people think of "costs" as cash outflows, not as an absence
of cash inflow.

What I'm trying to say is this:  Engineers should use the design entry
methodology that makes the most economic sense in the short- and
long-term.  Obviously, if one methodology results in a longer project
cycle time than another, there had better be a good reason to use it.
Likewise, if a methodology hinders or precludes design reuse (as
schematics can do), you've got to evaluate the long-term consequences
of using that methodology.  Using "the worse language because it's
portable..." may indeed be the right thing to do if it is the best solution
over the long-term.

Quote:
>>We believe the answer is to write small, clean architectures for structural
>>VHDL code and rely on schematic generation tools if we absolutely have to
>>"look at a picture."  [rest deleted]

>I'd like to know of such a generator based on VHDL input(?). Best would be if
>PD :-). Or at least a good layout algorithm which optimizes for readable
>presentation aspects. Any hints?

Unfortunately, I do not know of any such program.  Our usual method for
generating schematics includes synthesizing the code into a reasonable
process, then generating schematics from the resulting netlist -- less than
optimum, but functional.

Thanks for the feedback, Tom.

Mike



Mon, 19 Feb 1996 05:12:59 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Structural composition with vhdl-mode in emacs

2. Emacs VHDL editing mode (vhdl-mode.el version 2.74)

3. Emacs VHDL editing mode (vhdl-mode.el version 2.71)

4. Emacs VHDL editing mode (vhdl-mode.el version 2.56.1.1)

5. Emacs VHDL editing mode (vhdl-mode.el version 2.56.1.1)

6. VHDL mode for Emacs (vhdl-mode.el version 2.50)

7. Free VHDL Editor: Emacs VHDL Mode 3.28

8. VHDL-AMS support in Emacs VHDL Mode

9. Xemacs VHDL mode (vhdl.zip file, 83 Kbytes) - vhdl.zip (1/1)

10. New EMACS mode for VHDL/Verilog

11. Auto comments insertion - Emacs VHDL Mode

12. Emacs VHDL Mode 3.32 beta

 

 
Powered by phpBB® Forum Software