Subject: AW: Some suggestions
From: Wolfgang.Ecker@infineon.com
Date: Sat Apr 29 2000 - 12:00:51 PDT
Hi Evan, Hi all
>>>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.
I don't thinks that's a good idea. The strong typing and size check of
VHDL (compared to VERILOG) helps at elaboration time latest to find out
bugs. What we do in this case is the use of a function for array sizing,
which cuts or fills values to a requested size. Its declared like
function size( p : bit_vector ; s : integer ; f : bit := '0'; a : STD.TEXTIO.align )
(the last type is the same as used for textio, I currently don't remeber the right
name). Such a function would also be quite interesing for the std_logic_1164. If
I remember right, such a function is also part of the 1076.3 synthesis packages.
>>> 2) Generates should have elsif/else clauses. To get around this, you
>>> currently have to repeat the generate with a negated condition.
fully agree
>>> 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.
I fully support this motion. Over that, a 64 bit integer is needed and a
symetric integer range,
>>>
>>>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.
>>>
>>>This request was already rised at the VIUF'98 fall meeting
>>>
>>>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.)
>>>
This is possible in a restrited way by using subroutines with input parameters,
which have a default assignemnt associated with.
>>>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?
A standard PLI with fast(!) integration of funcitonal C Code is in my opinion
currently the most important enhancement for VHDL.
>>>
>>>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
I think this is more a feature of a tool than a feature of the language.
Our VHDL frontend, determines the compile sequence after parsing and before
symbol and type checking, independendly from the name and the sequence of the
files which should be analysed.
What I want most with respect to ADA are generic types.
----------------------------------------------------------------------
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 : Sat Apr 29 2000 - 12:10:24 PDT