Subject: Some suggestions
From: Evan Lavelle (eml@riverside-machines.com)
Date: Thu Apr 27 2000 - 03:23:21 PDT
Here are some more gripes/suggestions. My apologies if any of this
covers old ground; I don't know what exactly has been covered in the
recent LRM revision (could someone post a summary?)
Category 1: save some unnecessary typing
----------------------------------------
1) Hex bit string literals aren't particularly useful since they can
only be assigned to 4n-bit objects. This makes it difficult to
quickly assign a hex value to an arbitrary-length vector; you
instead have to specify the bits individually, use an aggregate, a
conversion function with an integer (which isn't static), and so
on. The problem isn't just assignment -
constant X : SLVn := X"AB"; -- illegal for non-8bit X
target <= '1' when X"AB"; -- ditto for selector, etc.
It would be a lot better if the analyser was allowed to
left-truncate or zero-extend octal or hex bit string literals as
required.
2) Generates should have elsif/else clauses. To get around this, you
currently have to repeat the generate with a negated condition.
3) Buffer mode ports need fixing.
4) A significant amount of my code involves creating temporary
signals, doing some simple combinatorial assignment to them, and
then using them as actuals in a port map. The problem here is that
although you can use an expression as an actual for a formal
signal, the expression has to be globally static, and so you can't
do something simple like:
U1 : COMP port map (
A => SIGA and SIGB, -- illegal
B => "00" & SIGC); -- illegal
Why does the expression have to be static? Removing this
restriction would make it more difficult to identify drivers, but
surely there's very little extra complexity here.
5) Anonymous arrays. For example, this declaration is illegal:
signal SIG: array (7 downto 0) of X;
Why? This is apparently legal in Ada.
Category 2: useful operators
----------------------------
6) There are no operators for bitwise operations on integers. This
looks like a major omission. I have to overload the logical and
shift operators for integers myself, in a non-standard way. I don't
do this for synthesis, but there's a good chance that a synthesiser
wouldn't implement my code efficiently. It would also be useful to
have increment/decrement operators on integers.
Category 3: useful additions
----------------------------
7) A standard preprocessor. You can do some of what is required using
constants, aliases, subtype ranges, and so on, but none of these is
an adequate substitute for a standard text-replacement
preprocessor. Ok, you can preprocess yourself if you want to, but
it complicates the flow, leads to non-standard source code, and
also cuts out the FPGA users with simple/cheap tools who prefer a
GUI-driven environment. Manifest constants would also be useful -
you could find out if your code was running on tool X or tool Y,
and code appropriately. This is particularly relevant to synthesis
where so many different language subsets are supported.
8) One of the most glaring problems in the language: TextIO is totally
inadequate. The problem isn't just the lack of useful file I/O
operations, but everything else you might need/expect. What users
need is a VHDL version of the C library; these routines are
universally known. But, of course, we can't port the C library as
it stands at the moment; see below.
Category 4: major surgery
-------------------------
9) Variable-length parameter lists. This could be restricted to
variable and constant-class objects, for subprograms only (any of
you tried to implement printf/scanf? It's a nightmare.)
10) Pointers are greatly restricted by the fact that you can't take
the address of an existing object. Is there a good reason for this
restriction? Generalising pointers would make a great difference
to the general usability of the language. There would need to be
restrictions to make sure that the simulation network remained
static, ie. that you couldn't create and dereference signal
pointers at runtime, but I wouldn't have thought that this would
be too difficult to specify. We'd also need sizeof and malloc, or
equivalents.
11) A standard PLI - how is this getting on?
Category 5: Ada 95
------------------
I don't know Ada, but it seems likely that the 95 changes could be
relevant to 200x. I've reproduced below a recent post on
comp.lang.vhdl, about how analysis order dependencies have been
removed in Ada 95.
12) Analysis order dependencies
----------------------------------------------------------------------
From: Paul Graham, Cadence (pgraham@cadence.com)
> Moreover, a package to be used must first be analyzed. It is not
> reanalyzed each time it is used. In contrast, the contents of an
> include file are compiled each time they are substituted.
This rule comes from Ada-83. In Ada-95 the rule was changed to allow
reanalysis of a used unit as needed. The GNU Ada Translator (GNAT)
does this. This C-like model actually results in easier compilation
and fewer recompilations.
For suppose that file p.vhdl contains package p, and file e.vhdl
contains entity e which uses package p. Using the traditional
Ada-83/VHDL model, the user (or makefile) must know to analyze p.vhdl
first, e.vhdl. When the number of vhdl files grows large, you need a
special tool just to figure out this ordering!
And then suppose that you reanalyze p.vhdl. This forces reanalysis of
e.vhdl, even if nothing has changed in the package interface.
On the other hand, with the Ada-95/GNAT method, it is not necessary to
analyze files in any particular order. Package files can be
reanalyzed without rendering using uints out-of-date.
The only restrictions that GNAT makes are that each file contain one
unit, and that the file be named to correspond with the unit. (GNAT
comes with a utility to break up files which do not follow this
convention.) A neat feature of this naming convention is that GNAT
can inline a subprogram body which is defined in a package body.
Compare this with C++, which requires public inline functions to be
declared in header files.
The GNAT compiler (including source code) is available at
www.gnat.com.
Paul
----------------------------------------------------------------------
This archive was generated by hypermail 2b28 : Thu Apr 27 2000 - 03:38:45 PDT