Subject: Re: Some suggestions
From: Jayaram Bhasker (jbhasker@cadence.com)
Date: Tue May 02 2000 - 09:22:07 PDT
Evan:
>> 6) There are no operators for bitwise operations on integers. This
This issue has been discussed in the past in the VHDL Synthesis Packages Working
Group (1076.3). Either Wolfgang or Egbert had presented a proposal
on an integer package (i remember that this presentation occured at a VIUF
Conf in San Diego about five years ago). Unfortunately, there was not enough
feedback/drive/momentum to get the integer package standardized.
We need to get more people who are interested in such a package to participate in the
working group and to contribute towards the development of such a package.
- bhasker
> From owner-stds-vasg@ieee.org Thu Apr 27 06:38 EDT 2000
> Date: Thu, 27 Apr 2000 11:23:21 +0100
> From: Evan Lavelle <eml@riverside-machines.com>
> Organization: Riverside Machines Ltd.
> X-Mailer: Mozilla 4.08 [en] (Win95; I)
> MIME-Version: 1.0
> To: stds-vasg <stds-vasg@ieee.org>
> Subject: Some suggestions
> Content-Transfer-Encoding: 7bit
> Sender: owner-stds-vasg@ieee.org
> Reply-To: stds-vasg@ieee.org
> X-Resent-To: Multiple Recipients <stds-vasg@majordomo.ieee.org>
> X-Listname: stds-vasg
> X-Info: [Un]Subscribe requests to majordomo@majordomo.ieee.org
> X-Moderator-Address: stds-vasg-approval@majordomo.ieee.org
> X-Received: By mailgate2.Cadence.COM as DAA05868 at Thu Apr 27 03:38:19 2000
>
>
> 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 : Tue May 02 2000 - 09:41:10 PDT