Subject: RE: [vhdl-200x] Language bloat
From: Jayaram Bhasker (JBhasker@eSilicon.com)
Date: Mon Jul 21 2003 - 11:10:54 PDT
On the issue of whether we should expand VHDL's capability or go with another
language, my experience has shown that users who know VHDL will gladly try
new features in the same language rather than learn a completely new language.
On the issue of how to implement fifos, I urge Andy and Scott and others to attend the WG
meetings and provide alternative solutions. There are other companies as well
such as Avery Design that offer packages to implement FIFOs. Whether you should implement
a fifo using a package or using a predetermined type is still up for discussion.
There is a proposal made at present. Alternate proposals are welcome.
- bhasker
------
J. Bhasker, eSilicon Corp
1605 N. Cedar Crest Blvd, Ste 615, Allentown, PA 18104
jbhasker@esilicon.com, 610.439.6831, 610.770.9634(fax)
-----Original Message-----
From: Andy D Jones [mailto:andy.d.jones@lmco.com]
Sent: Monday, July 21, 2003 10:11 AM
To: Scott Thibault
Cc: vhdl-200x-tbv@eda.org; vhdl-200x@eda.org
Subject: Re: [vhdl-200x] Language bloat
I couldn't agree more. Rather than providing point solutions to
problems, we should concentrate on issues that preclude useful solutions
in the present language. In the FIFO example, the main problem is one
of data types. In the current VHDL, one can create a parameterizable
FIFO of any dimension, with paramerizable flags, etc., but it must be of
a pre-determined type of storage. If we were to borrow the type-based
genericity from ada, as has been proposed before by others, we would
have a powerful tool to create such useful, flexible solutions to common
problems without extending the language for each solution.
Andy Jones
Lockheed Martin Missiles & Fire Control
Dallas TX
Scott Thibault wrote:
>Hello everyone,
>
>There seems to be a substantial list of features that are being considered
>for inclusion in the next VHDL, and I wonder if it would not be a good idea
>to check ourselves on this issue of language bloat. I've spent a good
>amount of time studying domain-specific languages, and would like to share
>some of my thoughts about this issue. I think they apply to our work as a
>whole but specifically there are a number of things in the TBV group that
>should be considered, such as fifos.
>
>The primary distinction between a general-purpose language and a
>domain-specific language, is that general-purpose languages strive to
>provide powerful abstraction mechanisms (e.g., the ability to create classes
>or functions), where as a domain-specific language attempts to provide the
>right set of predefined abstractions for a given domain (e.g., built-in
>primitives/types specific to the domain). I consider VHDL to be kind of in
>between, what I call a domain-oriented language. It is general purpose in
>the sense that you can write virtually any program in VHDL (i.e. the design
>space is huge), but yet it has domain specific features that make it
>particularly useful for a certain domain of applications (i.e. event-driven
>simulation, which is still a large domain). Our current effort will push
>VHDL even more towards the general purpose of the spectrum by trying to
>enlarge the design space to include testbench and system level design.
>
>Because VHDL tries to address multiple and large domains, I think it would
>be unwise to attempt to provide predefined abstractions that will be
>necessary for those domains, but rather focus on providing the powerful
>abstraction mechanisms that will enable us to create the VHDL packages
>needed for the various domains we are trying to address. For example,
>rather than adding a predefined notion of a fifo in VHDL, why not provide
>some kind of parameterized types that would allow us to build a verification
>package that would allow users a convenient way to create fifos?
>
>VHDL is already a large language, so these are some things to think about.
>
>Regards,
>--Scott Thibault
>Green Mountain
>Computing Systems, Inc.
>http://www.gmvhdl.com
>
>
>
This archive was generated by hypermail 2b28 : Mon Jul 21 2003 - 11:14:17 PDT