VHDL language is out of date! Why? I will explain.

[psihodelia@googlemail.com]

Just look at its syntax. It is so archaic that anyone who had any deal
with Python will just laugh. Try, say, to create a simple VGA
controller, which is simply readable.

VHDL's Ada syntax is also very error prone. Instead of having all this
archaic constructions and surplus operators, it would be much more
productive just to start thinking about to create another hi-level HDL
that has absolutely another conceptual design and simple syntax.

Any good language should be so simple as possible and any program in
this language should be short and clear. Such language should support
associative arrays, that should help designing large FSMs; should
support simple mechanism of type conversions and so on...

Conceptually VHDL is not bad at all, it supports a lot of things, well
in theory. But in praxis ...

And don't forget about future FPGAs, about future SoCs, which will
have integrated MEMS arrays, and other stuff. Try to understand how
much complexer they are to be designed in so unproductive way using so
primitive languages.

 

[KJ]

On Nov 16, 1:27 pm, "psihode...@googlemail.com"
<psihode...@googlemail.com> wrote:

Just look at its syntax. It is so archaic that anyone who had any deal
with Python will just laugh. Try, say, to create a simple VGA
controller, which is simply readable.

VHDL's Ada syntax is also very error prone. Instead of having all this
archaic constructions and surplus operators, it would be much more
productive just to start thinking about to create another hi-level HDL
that has absolutely another conceptual design and simple syntax.

Any good language should be so simple as possible and any program in
this language should be short and clear. Such language should support
associative arrays, that should help designing large FSMs; should
support simple mechanism of type conversions and so on...

Conceptually VHDL is not bad at all, it supports a lot of things, well
in theory. But in praxis ...

And don't forget about future FPGAs, about future SoCs, which will
have integrated MEMS arrays, and other stuff. Try to understand how
much complexer they are to be designed in so unproductive way using so
primitive languages.

So I guess you'll be designing all your stuff in another language and
dropping out of this newsgroup...

KJ

 

On Nov 16, 1:27 pm, "psihode...@googlemail.com"
<psihode...@googlemail.com> wrote:

VHDL's Ada syntax is also very error prone. Instead of having all this
archaic constructions and surplus operators, it would be much more
productive just to start thinking about to create another hi-level HDL
that has absolutely another conceptual design and simple syntax.

Ever heard of verilog ?

It's a bit more like c - you can write very concise code, or you can
make a real mess...

 

[HT-Lab]

<psihodelia@googlemail.com> wrote in message
news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com...

Just look at its syntax. It is so archaic that anyone who had any deal
with Python will just laugh. Try, say, to create a simple VGA
controller, which is simply readable.

Ok, in that case start writing your VGA controller in Python, then go to
http://myhdl.jandecaluwe.com/doku.php/start synthesize it, download it on an
FPGA prototype board and report back to us how incredible simple and quick
it was....

Conceptually VHDL is not bad at all, it supports a lot of things, well
in theory. But in praxis ...

Praxis....isn't that a DIY store in Holland?

Hans
www.ht-lab.com

VHDL's Ada syntax is also very error prone. Instead of having all this
archaic constructions and surplus operators, it would be much more
productive just to start thinking about to create another hi-level HDL
that has absolutely another conceptual design and simple syntax.

Any good language should be so simple as possible and any program in
this language should be short and clear. Such language should support
associative arrays, that should help designing large FSMs; should
support simple mechanism of type conversions and so on...

Conceptually VHDL is not bad at all, it supports a lot of things, well
in theory. But in praxis ...

And don't forget about future FPGAs, about future SoCs, which will
have integrated MEMS arrays, and other stuff. Try to understand how
much complexer they are to be designed in so unproductive way using so
primitive languages.

 

[Colin Paul Gloster]

In
news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com
timestamped Fri, 16 Nov 2007 10:27:59 -0800 (PST),
"psihodelia@googlemail.com" <psihodelia@googlemail.com> posted:
|-----------------------------------------------------------------------|
|"Just look at its syntax. It is so archaic that anyone who had any deal|
|with Python will just laugh. [..]" |
|-----------------------------------------------------------------------|

Nonsense.

|-----------------------------------------------------------------------|
|VHDL's Ada syntax is also very error prone. Instead of having all this |
|archaic constructions and surplus operators," |
|-----------------------------------------------------------------------|

I disagree that any of VHDL and Ada has error-prone syntax. Please
provide examples.

|-----------------------------------------------------------------------|
|" it would be much more |
|productive just to start thinking about to create another hi-level HDL |
|that has absolutely another conceptual design and simple syntax." |
|-----------------------------------------------------------------------|

Does reFLect not fit your needs. What about Lava or Hawk or APL or
Confluence or Verischemelog or any of the other supposedly high-level
terse languages which have been proposed for hardware (not that APL
had originally been proposed for hardware, but at least one paper for
hardware with APL had been published).


|---------------------------------------------------------------------|
|"Any good language should be so simple as possible and any program in|
|this language should be short and clear. Such language should [..] |
|should help designing large FSMs; [..] |
| |
|[..]" |
|---------------------------------------------------------------------|

So despite your claim that VHDL is out of date and your mention of
Python earlier, should your advocacy of state machines be construed as
evidence that you oppose object orientation?

 

[Thomas Rouam]

Any good language should be so simple as possible and any program in
this language should be short and clear.

A reminder : VHDL is not a programming language, thus implying you do
not write a program with VHDL.

 

[Mike Treseler]

psihodelia@googlemail.com wrote:

Conceptually VHDL is not bad at all, it supports a lot of things, well
in theory. But in praxis ...

Here's my workaround using the thunderbird news reader:
1. Click on the OP's posting.
2. Message, Create Filter from Message, OK, Close.

-- Mike Treseler

 

[Filip Miletic]

Mike Treseler wrote:

Here's my workaround using the thunderbird news reader:
1. Click on the OP's posting.
2. Message, Create Filter from Message, OK, Close.

Oh, that's how it is done! *plonk*
To the rest: please don't feed the trolls.

f

 

[Jan Decaluwe]

HT-Lab wrote:

psihodelia@googlemail.com> wrote in message
news:c143798e-856e-4be4-8384-15c3a4e79573@b32g2000hsa.googlegroups.com...

Just look at its syntax. It is so archaic that anyone who had any deal
with Python will just laugh. Try, say, to create a simple VGA
controller, which is simply readable.


Ok, in that case start writing your VGA controller in Python, then go to
http://myhdl.jandecaluwe.com/doku.php/start synthesize it, download it on an
FPGA prototype board and report back to us how incredible simple and quick
it was....

I hope some one will take the project (You'll need a development
version for VHDL conversion.) Here's what to expect.

The synthesizable RTL subset is what it is. Conceptually, there's little
to be gained from using MyHDL or whatever instead of VHDL for this.
There are good and bad ways to do it, but it will all be fairly "low level".
I'm not sure the OP understands that. It's not a syntax issue.

Having said that, MyHDL RTL has interesting features. In particular,
it has a "hardware designer's dream type" (or at least my dream):
a constrainable integer type like in VHDL (but not restricted to
32 bits ...), with an indexing and slicing interface for bit access.
All issues with signed/unsigned, resizing, casting, std_logic_arith
versus numeric_std, ... simply go away. The integer-like MyHDL type
simply works as integers do, and the convertor takes care of all
those low-level issues.

I'm still puzzled why nobody had this idea before (and why I'm not
getting more praise ), but in any case, it's not a matter
of syntax. I put it in, and I could specify how to do it in any
other language.

If you like dynamic languages (not everybody does), you'll enjoy
using MyHDL/python especially during verification. There you can
use the full power of python, which is in my opinion invariably
useful. Combined with a unit test framework such as py.test,
verification almost becomes fun

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com

 

[psihodelia@googlemail.com]

MyHDL looks really nice!
Is it possible to have in a FSM one procedure-or-function for each
state? It should make the program code easy to read. It will be also
better to have an array of functions and call them according FSM state
number. Do you have any idea how to implement this in MyHDL?
Here is a vivid wishful pseudo-Python example of what I mean:

def read(args):
do smth.
def write(args):
do smth.
...
function = [1:read, 2:write, 3:sleep, 4:wake]
next_state = [1:3, 2:3, 3:3, 4:1]
def FSM_states_switch:
state = next_state[state]
def FSM_output_function:
function[state](args)

 

[Paul Taylor]

On Sat, 17 Nov 2007 20:52:59 +0100, Jan Decaluwe wrote:

The synthesizable RTL subset is what it is. Conceptually, there's little
to be gained from using MyHDL or whatever instead of VHDL for this.

I think that there is something to be gained from using 'whatever', but it
depends - if you are full-time vhdler working on small or large FPGA
designs then fine; if you are an electronics engineer who on a reasonably
regular basis has an FPGA that needs to be designed/verified then vhdl is
(IMO of course) too complex, and, for test benches in particular, too
cumbersome.

Here is an example of my solution:

# @title Dual UART Tx FPGA
# @description FPGA design with two UART tranamitters that
# continuously transmit data taken from one-hot counters
# @port clk 10MHz clock
# @port nARst Active low reset
# @port txA UART transmit channel A
# @port txB UART transmit channel B
# @marked nARst Use aRst
use berry.if.serial.*;
use berry.util.*;

module DualUartTx() {
inport clk, marked nARst;
outport txA, txB;

reg stateMachine[] = {
async 0 when aRst;
: uartA.wr = 1; uartB.wr = 1; next;
: 0 when uartA.ready & uartB.ready;
}

UartTransmitter uartA(), uartB();
connect uartA aRst, baudClk(clk115.out), data(cntA), tx(txA);
connect uartB aRst, baudClk(clk96.out), data(cntB), tx(txB);
PulseGen clk115(DIV = 10e6 / 115200), clk96(DIV = 10e6 / 9600);

onehot reg cntA[%8] = {async 0 when aRst; next when uartA.wr;}
onehot reg cntB[%8] = {async 7 when aRst; prev when uartB.wr;}

connect SyncARst() in(! marked nARst), out(node aRst);
DualUartTxConstraints();
}



and here is another example:

# @title Stopwatch
# @description A stopwatch with tenths, seconds, and tens of seconds.
# @port tenths Tenths of seconds, inverted one-hot encoded
# @port ones Seconds encoded to drive a seven segment display
# @port tens Tens of seconds encoded to drive a seven segment display

module StopWatch() {
inport clk, aRst, clk100ms; startStop;
outport tens[%7], ones[%7], tenths[%10];

reg stateMachine[] = {
async 0 when aRst;
: next when startStop;
: tenthsCnt.inc = 1 when clk100ms; next when !startStop;
: tenthsCnt.inc = 1 when clk100ms; next when startStop;
: 0 when !startStop;
}

onesCnt.inc = tenthsCnt.rollover = 1 when tenthsCnt.inc & tenthsCnt == 9;
tensCnt.inc = onesCnt.rollover = 1 when onesCnt.inc & onesCnt == 9;
tensCnt.rollover = 1 when tensCnt.inc & onesCnt == 5;

reg tenthsCnt[%4], onesCnt[%4], tensCnt[%3] = {
node rollover, inc; async 0 when aRst; 0 when rollover; next when inc;
}

const SEVEN_SEG_DECODE[10] = { 0x79, 0x24, 0x30, 0x19, 0x12, 0x02, 0x78,
0x00, 0x10, 0x08 };
tens = SEVEN_SEG_DECODE[0 .. 5] when tenthsCnt == 0 .. 5; ones =
SEVEN_SEG_DECODE[0 .. 9] when onesCnt == 0 .. 9;
node tenthsDec[%10] = 1 << 0 .. 9 when tenthsCnt == 0 .. 9;
tenths = !tenthsDec;
}

If you like dynamic languages (not everybody does), you'll enjoy
using MyHDL/python especially during verification. There you can
use the full power of python, which is in my opinion invariably
useful. Combined with a unit test framework such as py.test,
verification almost becomes fun

I would agree with that idea - unit testing + general purpose scripting
language as a basis for verification. I would also like a nice editor
with auto compile (as in eclipse), oh, and with auto-completion too

Regards,

Paul.

 

[Jan Decaluwe]

psihodelia@googlemail.com wrote:

MyHDL looks really nice!
Is it possible to have in a FSM one procedure-or-function for each
state? It should make the program code easy to read. It will be also
better to have an array of functions and call them according FSM state
number. Do you have any idea how to implement this in MyHDL?

Depends on what "implement" means.

For pure modelling with MyHDL, you can use python's full power.

For code intended for conversion to Verilog/VHDL, there are very
severe restrictions, similar to those for synthesizable RTL code.
(Conversion support is intended to provide a path to hardware
implementation.) Such code will look similar to RTL code in other
languages.

Jan

--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Kaboutermansstraat 97, B-3000 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com

 

[mk]

On Sun, 18 Nov 2007 11:54:41 -0800 (PST), "psihodelia@googlemail.com"
<psihodelia@googlemail.com> wrote:

For pure modelling with MyHDL, you can use python's full power.

For code intended for conversion to Verilog/VHDL, there are very
severe restrictions, similar to those for synthesizable RTL code.
(Conversion support is intended to provide a path to hardware
implementation.) Such code will look similar to RTL code in other
languages.

Jan


I did imagine MyHDL to be more powerful.

That's exactly the problem. The difficulty is with converting those
powerful semantics to RTL which is called behavioral synthesis which
is still an open research topic in most instances. Some top eda
companies have tried and failed in the past and now C synthesis is
being tried again with limited success. You can't expect myhdl to
include a top notch behavioral synthesis feature; yet hopefully.

 

[psihodelia@googlemail.com]

For pure modelling with MyHDL, you can use python's full power.

For code intended for conversion to Verilog/VHDL, there are very
severe restrictions, similar to those for synthesizable RTL code.
(Conversion support is intended to provide a path to hardware
implementation.) Such code will look similar to RTL code in other
languages.

Jan

Hmm... It is very serious restriction. I did imagine MyHDL to be more
powerful. MyHDL is just a wrapper?

 

[xenix]

you should learn Rossetta as Well. pretty cool attempt. I am looking
to hire MyHDL designers ..hehehe

 

[Colin Paul Gloster]

On Sat, 17 Nov 2007, Filip Miletic wrote:

|--------------------------------------------|
|"To the rest: please don't feed the trolls."|
|--------------------------------------------|

Refuting can be useful.

I apologize for provoking the original poster of this thread without
being able to remain to participate in future parts of the thread. Some
contributors to these newsgroups who had emailed me before this season
had been aware of circumstances which deprive me of much opportunity
to contribute to Usenet often. Hopefully I will be more active on Usenet
late in Spring 2008, but I can not be sure now what the circumstances
shall be at that time.

I quote from an article of the ACCU UK Python Users Group entitled
""The sound of one coconut shell clopping"" by Paul Brian in the
August 2002, Volume 14, Number 4 issue of "CVu" ( WWW.ACCU.org ) on
Page 28:
"[..]
Where are the type declarations? Well, Python discovers type at run-time,
[..]
[..]"

I quote from "Using Python's Dynamic Features to Encapsulate Relational
Database Queries" by Richard Taylor in the December 2002 issue of "CVu"
from Page 27:
"[..]
[..] Python's dynamic type system means that you can be unsure of the type
of the variable [..]
[..]"

One of the main goals of static strong typing such as in VHDL and Ada
is to detect mistakes early, especially when attempting to compile
instead of when running (and hence crashing). Instead, in a dynamic,
object-oriented language such as Lisp, mistakes which are trivial for
a VHDL compiler to find crash a program at runtime. E.g. perform the
following experiment: compile the Common Lisp program for theorem
proving called Prototype Verification System (PVS) (e.g. if I recall
correctly, in 2007 it took a CMU CL compiler approximately 40 minutes).
To satisfy yourself that it is how it should be, run PVS and invoke one of
the functions for pretty printing. Quit PVS and change only one lexical
token in PVS's source code: change something in one of the functions for
pretty printing such that a typing error occurs. Recompile (if I recall
correctly, it took approximately 10 minutes for me). Run your modified
PVS and do some things with it. Note how the error has not been detected
yet. Invoke the function you changed, then it crashes. This is an extremely
good advertisement against dynamic typing. I remember someone boasted
on news:comp.lang.lisp that the advanced debugging features provided
by a Lisp implementation in a fielded application were retained which
made on-site debugging easy. For work of interest to me, being able
to maintain a deployed system is of importance, but that is not a
valid excuse for allowing errors to be present when launching
a system into the field. I quote from "Using Python's Dynamic Features
to Encapsulate Relational Database Queries" by Richard Taylor in the
December 2002 issue of "CVu" from Page 29:
"[..]
This article has demonstrated how features such as dynamic attribute
lookup and class definitions as first class objects can be used to build
flexible abstractions in Python. I have used such techniques extensively in
the applications on which I have worked. However, I have also learned
through bitter experience that such techniques can cause faults that, because
Python has little compile time checking, only become apparent at run time
and can prove very hard to find. These problems can be alleviated with
judicious use of pre- and post-conditions on methods along with careful
use of exception handlers to recover from runtime errors.
[..] tripped
up by a built-in method that you have overloaded by accident. [..]"

For Python; Eiffel; and Lisp, whitespace is significant which can
cause trouble if a text editor which forces a particular layout (e.g.
Pico; Nano; some of the modes of Emacs; Microsoft Edit.com; Vim if
ai (autoindent) is set; and a text editor for VMS Notes) is used and
a change forced by a text editor goes unnoticed.

Python with the Stratus hardware description language has not
displaced VHDL yet. Nor has Python with MyHDL.

The following have been claimed to be terser than VHDL for a
number of hardware uses: C++; Verilog; Verischemelog (I may
have misspelt that name earlier in this thread); APL; Lava;
Confluence; and HDCaml. How could Python even possibly
compete with APL for terseness?

I do not agree that conciseness is a good thing. If one sees
an asterisk, which of Kleene closure; multiplication;
convolution; footnote; and adjoint is denoted by the * in
this instance? How would one check? Adobe Acrobat's search
function can be extraordinarily slow when searching through
a strict subset of Synopsys's documentation on a quadcore
workstation; grep can also accept an asterisk but many
search engines will ignore an asterisk (and just about
every other character which is not alphanumeric). Can you
remember which of the intervals [1,5) and (1,5] includes the
number five? The command
Copy Source.txt Dest.txt
will behave differently on VMS if a file named Dest.txt
already exists than the lexically identical command on
MS DOS. Please find someone who knows neither MS DOS nor
VMS and tell me if this person will correctly say without
prompting all the possible outcomes of entering
Copy Source.txt Dest.txt. Are you fond of the way numbers
instead of words spelt with letters are used to select
different integration methods in SPICE? Would you risk
adjusting this setting without checking which numbers
correspond to which methods?

Please search for an old post by myself in news:comp.arch.embedded
in which I asked a Lint user how he would prevent accidentally
adding a value of a datatype for counting apples to a value of a
datatype for counting oranges. How should these situations be
handled in a better HDL to replace VHDL?

 

To the rest: please don't feed the trolls.

Yes, I think I preferred reading about MI5 persecution.

 

[Paul Taylor]

On Wed, 21 Nov 2007 15:55:46 +0100, Colin Paul Gloster wrote:

One of the main goals of static strong typing such as in VHDL and Ada
is to detect mistakes early... <snip

Compiling a small program that you want to change/run is a pain, so
dynamic/scripting languages are great here. But then for larger programs,
scripting languages are a pain for the reasons you state. Others
like/advocate them for writing large programs but I can't understand that.
So I'm with you here.

Python with the Stratus hardware description language has not
displaced VHDL yet. Nor has Python with MyHDL.

Probably nothing will displace vhdl/verilog. Just like nothing has
and probably won't replace C for embedded programming, for example. That's
been around for years as well.

I do not agree that conciseness is a good thing ... <snip

Of course clarity is more important than terseness - e.g some perl, yuk. A
state machine in my other post in this thread I like - it's terse and it's
clear and it's easy to maintain. Lets say I want to change it by adding a
state or two, I don't need to mess around adding constants to an
enumeration type, and changing constants around in a case statement.

Also I don't explicitly connect clocks to registers/modules - that's done
automatically for me, if there is a clk node in the module. I can override
this but mostly that's what I want.

Conciseness can be very good (if clarity and the ability to scale are not
compromised), the language can be easier to use, and so allowing you to
concentrate more on the problem you're trying to solve.

Please search for an old post by myself in news:comp.arch.embedded
in which I asked a Lint user how he would prevent accidentally
adding a value of a datatype for counting apples to a value of a
datatype for counting oranges.

orangesDb.add(anApple) ?

Ok, I know that's a contrived example, and nobody would write a line of
code like that. But Java didn't have generics until version 5. Before
version 5 I don't recall having an issue with the sort of problem you are
describing. I now use generics, but not because I'm particularly concerned
about storing the wrong type (I use sensible variable names ), it's
just that it's easier to use generics than not because otherwise you end
up doing a lot of casting.

I'm not against putting safeguards in a language. You have to ask what it
is you are protecting yourself against, and consider what the cost is (too
much red tape is bad). When writing vhdl I find the most common error I
make is that when assigning to a bit vector, I sometimes get the length
wrong, especially when slices and concatenations are involved. VHDL finds
that problem of coarse, which is great. The language that I am developing
has that safeguard too. I also have a marked keyword, which is a safeguard
because sometimes I stupidly use the wrong variable, e.g. an
unsynchronised signal instead of one that I have synchronised for use
(especially when I come back to change some code). I also have asserts on
compile-time config, so when I instantiate a module I find config
parameter errors too. A contrived example:

module ACounter(DIR = UP; SIZE = 16) {
assert DIR {UP, DOWN, UPDOWN};
assert SIZE > 0;

inport clk, rst;
outport count[%SIZE];

reg cnt[%SIZE];
count = cnt;

config DIR == UP {
inport inc;
cnt = {0 when rst; next when inc;}
}
config DIR == DOWN {
inport dec;
cnt = {0 when rst; prev when dec;}
}
config DIR == UPDOWN {
inport inc, dec;
cnt = {0 when rst; next when inc; prev when dec;}
}
}

I would be interested to know what mistakes others commonly make, that are
found by the VHDL compiler.

Regards,

Paul Taylor.

 

[Wolfgang Grafen]

In <47449ab1$1_4@mk-nntp-2.news.uk.tiscali.com> Paul Taylor wrote:

On Wed, 21 Nov 2007 15:55:46 +0100, Colin Paul Gloster wrote:

One of the main goals of static strong typing such as in VHDL and Ada
is to detect mistakes early... <snip

Compiling a small program that you want to change/run is a pain, so
dynamic/scripting languages are great here.
Think about that producing code means 80% or more testing effort. Compiling

VHDL is really not the problem for a simulation but testing. A dynamic language
allows you also a kind of "dynamic testing" which would speed up the overall
process dramatically.

You could test a function or process written in the architecture from one or
more separate test programs with a Python like HDL language, with life inspection!
There is nothing close to that useability in VHDL. And the code would be at
least as readable as VHDL.

But then for larger programs,
scripting languages are a pain for the reasons you state. Others
like/advocate them for writing large programs but I can't understand that.
So I'm with you here.
Large programs mainly benefit from a clean concept. If you don't have a clean

concept you will fail both in a dynamic and static programming language. This
is the main difference between small and large programs.

If we neglect peformance issues a modern scripting language is as least as good
as a static language. If you did all the regression tests properly you will not
experience any surprises with e.g. Python.

Python with the Stratus hardware description language has not
displaced VHDL yet. Nor has Python with MyHDL.
MyHDL is a one man show. I doubt that Python is the ideal language based for

hardware description. I believe it is possible to design a very concise dynamic
language for hardware design. But this will significantly more than one person
to bring it up. My impression is MyHDL is not very suitable for large projects now.

Probably nothing will displace vhdl/verilog. Just like nothing has
and probably won't replace C for embedded programming, for example. That's
been around for years as well.
Of course there will come something, no doubt. Hopefully it will be better...

SNIP
Paul Taylor.

Regards

Wolfgang Grafen

 

[Mike Treseler]

Paul Taylor wrote:

...
I also have a marked keyword, which is a safeguard
because sometimes I stupidly use the wrong variable, e.g. an
unsynchronised signal instead of one that I have synchronised for use
(especially when I come back to change some code).

Interesting.
I now handle this manually by using annoying
identifiers for the unsynch nodes.
Maybe "run_glitchy" vs "run".

I would be interested to know what mistakes others commonly make, that are
found by the VHDL compiler.

OK here's mine.
I get automated mistake-finding at the
editor, analysis, and elaboration level
of each library unit.

1. Emacs vhdl-mode completes keywords
and identifiers, matches most parens
and prompts for clauses in a keyword statement.
This prevents most syntax errors from happening.

2. I run simulation analysis
vcom -c mydesign.vhd
from an editor function key every few lines of code.
This step finds the most errors
but puts the cursor right on each one
and tells me what's wrong.

I would estimate:
90% syntax punctuation: missing or excess : ; ) etc.
10% static mismatch of code with local or library subtypes.
Length, range etc.
10% signature mismatch of code and local or library subprograms

At the top level, Emacs vhdl-make automatically finds
units with multiple declarations in the project path, like this:
WARNING: Architecture declared twice (used 1.): "synth" of "cnt_decode"
1. in "~/vhdl/play/cnt__decode.vhd" (line 18)
2. in "~/vhdl/play/cnt_decode.vhd" (line 18)

3. elaboration:
vsim -c mydesign
will find most runtime mismatches
and give a pretty good description of what's wrong.
Some messages are more cryptic hints at infinite loops,like
** Fatal: Write failure in vlm process (32,-1)

That leaves the functional errors to simulation
viewers and assertions, but I have no automated
method for this.

-- Mike Treseler