VHDL SUCKS REAL BAD
Anuj Chandra
VHDL is the crazyist thing that ever happened to Computer
architecture. How can serious engineers trust a foolish
package like VHDL.
A piece of advice to all out there: Forget VHDL, and you will
be ALOT happier
Digusted
anuj
Alan D. Cabrera
Let me guess, you left your workstation unattended.
---
Alan Cabrera internet: a...@tardis.cl.msu.edu
Computer Laboratory phone: (517) 353-3027
Michigan State University fax: (517) 353-9847
514 Computer Center bitnet: CABRERA@MSU
East Lansing, MI 48824
The Universal Hacker
As a hardware designer, I second your notion. As a language designer (yes, I
have had the good fortune of being both) VHDL is quite a fantastic package.
--
rama...@pumpkin.ece.uc.edu home: 513 281 9870
rman...@uceng.uc.edu office: 513 556 3025
mand...@ucunix.san.uc.edu ham: KB8GKL
George Lippincott
>In article <1993Feb19.1...@wuecl.wustl.edu> an...@wucs1.wustl.edu (Anuj Chandra) writes:
>>
>>VHDL is the crazyist thing that ever happened to Computer
>>architecture. How can serious engineers trust a foolish
>>package like VHDL.
>>
>>A piece of advice to all out there: Forget VHDL, and you will
>>be ALOT happier
>>
>As a hardware designer, I second your notion. As a language designer (yes, I
>have had the good fortune of being both) VHDL is quite a fantastic package.
I'm not sure what you mean by "language designer" but from the language
point of view VHDL doesn't seem that great to me. It's grammer is context
sensitive which makes parsing less efficient and imposes the requirement
that design units be compiled in a particular order. The syntax has several
inconsistencies which seem to finally be getting cleared up in VHDL 92.
There are constructs such as component definitions which needlessly complicate
the language and create more potential for errors (because they require that the
same information be specified more than once).
VHDL has a lot of good points (and I actually do like it) but the language
specification isn't one of them.
---------------------------------------------------------------------------
George Lippincott | UUCP: uunet!ole!george
Cascade Design Automation Corp. | Internet: geo...@ole.cdac.com
3650 131st Ave SE, #650 | TEL: (206)-649-7661
Bellevue, WA 98006 | FAX: (206)-649-7600
Daniel R. Kegel
>[VHDL requires] that design units be compiled in a particular order. ...
>There are constructs such as component definitions which needlessly complicate
>the language and create more potential for errors (because they require that the
>same information be specified more than once).
>VHDL has a lot of good points (and I actually do like it) but the language
>specification isn't one of them.
C imposes some of the same requirements!
In C, you must compile design units in particular order, i.e. you have
to #include forward declarations of objects before you can use them.
It's just that in Ada, instead of #including them, you compile them
separately, in the same order. While I agree that this sucks,
some VHDL vendors (e.g. Model Technology) provide a utility that creates
a Makefile that compiles your library in the proper order. I think
something like this should be part of the standard.
Also, the component definitions are analogous to the forward declarations
normally present in C in .h files; in fact, VHDL packages are roughly analogous
to C .h files.
I am just learning VHDL, but am starting to appreciate it. I am making
a real effort to see if I can use it as-is before I start demanding new
features from the standards comittee!-)
- Dan Kegel (da...@blacks.jpl.nasa.gov)
George Lippincott
>C imposes some of the same requirements!
>In C, you must compile design units in particular order, i.e. you have
>to #include forward declarations of objects before you can use them.
>It's just that in Ada, instead of #including them, you compile them
>separately, in the same order. While I agree that this sucks,
>some VHDL vendors (e.g. Model Technology) provide a utility that creates
>a Makefile that compiles your library in the proper order. I think
>something like this should be part of the standard.
Vantage actually goes a step further and stores a copy of the source code
for each design unit which it can then recompile when it detects that
it is out of date. It would be nice if this wasn't even necessary though.
>Also, the component definitions are analogous to the forward declarations
>normally present in C in .h files; in fact, VHDL packages are roughly analogous
>to C .h files.
Component definitions are completely unnecessary because there is a requirement
that the entity declaration be analyzed before the component declaration. If
the database doesn't already contain the entity declaration when the analyzer
comes across a component, it will be necessary to recompile in the future. Why
not just use the entity itself to get the port and generic information?
Every time I show this to a new user, they think it is ridiculous that they have
to cut and paste the entity declaration, change the word entity to component, delete
the "is" and change the label after the end to "component". I have to agree
and fortunately in VHDL 92 I believe it will be possible to directly instantiate
an entity without jumping through this hoop.
Kirk Anderson
> Vantage actually goes a step further and stores a copy of the source code
> for each design unit which it can then recompile when it detects that
> it is out of date. It would be nice if this wasn't even necessary though.
While using the Vantage tools, I actually found this "feature" to be a
hinderance. It is quite easy to modify several different source files in
trying to fix a single bug. If I do this just before lunch, return after
lunch, and then recompile the files I changed - if I happen to forget to
recompile one of the modified source files, I'll be running with an out-of-
date simulation kernel because they would have just recompiled their own
local copy.
My feeling is that there ALWAYS has to be a direct and unbroken link back to
the original source code (i.e. NO extra copies floating around). After all,
that's what configuration management and the Make utility are all about.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Kirk Anderson INTERNET: ande...@tamara.crd.ge.com
TopDown Design Solutions +1 518 387 6709 (temp office)
Nashua, NH +1 603 888 8811 (real office)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Janick Bergeron
>Component definitions are completely unnecessary because there is a requirement
>that the entity declaration be analyzed before the component declaration. If
>the database doesn't already contain the entity declaration when the analyzer
>comes across a component, it will be necessary to recompile in the future. Why
>not just use the entity itself to get the port and generic information?
Only if you configure the component to a specific entiry/architecture
in the same library unit.
The component/entity decoupling is necessary if you use external configurations
or want to write technology-indenpendent netlists. You can define
a "2-input AND gate" component then later bind it to a TI TGB1000 AN210
entity/architecture or a LSI 100k AD2 entity/architecture.
Granted, this decoupling is cumbersome when doing high-level modeling
but, as you say, a simple cut-and-paste usually does the job.
Simple to write an EMACS macro that will turn an entity declaration into
a component declaration. We also have one that turns a package specification
into an outline for a package body. Something that creates a testbench
structure from an entity declaration is also very useful.
Do not confuse power of expression with ease of capture, readability,
and documentation. That's why I hope there'll never be a preprocessor
for VHDL (most of the problem I encounter with public software in C
is knowing which PP symbol to define to what).
--
Janick Bergeron Bell-Northern Research, Ltd Ph.: (613) 763-5457
System Timing P.O. Box 3511, Station C, Stop 049 Fax: (613) 763-7241
Verification Ottawa, Ontario, Canada, K1Y 4H7 email: jan...@bnr.ca
library quote; use quote.funny; use std.disclaimer.all;
George Lippincott
>In article <1993Feb23....@ole.cdac.com> geo...@ole.cdac.com (George Lippincott) writes:
>>Component definitions are completely unnecessary because there is a requirement
>>that the entity declaration be analyzed before the component declaration. If
>>the database doesn't already contain the entity declaration when the analyzer
>>comes across a component, it will be necessary to recompile in the future. Why
>>not just use the entity itself to get the port and generic information?
>Only if you configure the component to a specific entiry/architecture
>in the same library unit.
If you configure it to be bound to an entity in another library unit, I
believe that entity must still have been compiled first.
>The component/entity decoupling is necessary if you use external configurations
>or want to write technology-indenpendent netlists. You can define
>a "2-input AND gate" component then later bind it to a TI TGB1000 AN210
>entity/architecture or a LSI 100k AD2 entity/architecture.
It isn't really necessary. This could be done by simply writing an architecture
for the "2-input AND gate" which had one child -- the TI TGB1000 AN210 or the
LSI 100k AD2. In many ways this is an easier way to implement technology-
independent netlists.
>Granted, this decoupling is cumbersome when doing high-level modeling
>but, as you say, a simple cut-and-paste usually does the job.
>Simple to write an EMACS macro that will turn an entity declaration into
>a component declaration. We also have one that turns a package specification
>into an outline for a package body. Something that creates a testbench
>structure from an entity declaration is also very useful.
>Do not confuse power of expression with ease of capture, readability,
>and documentation. That's why I hope there'll never be a preprocessor
>for VHDL (most of the problem I encounter with public software in C
>is knowing which PP symbol to define to what).
The one good thing about component declarations and configurations is the
ability to use them for back-annotation of delays -- but then this turns
out to be illegal in VHDL-87 (even though some VHDL vendors allowed it).
In my opinion, their ability to be used for specifying technology
independent netlists doesn't compensate for the confusion they create.
Sometimes designers will make a change to the entity and forget to change
the component everywhere else it is declared. This doesn't always result
in an error. It would be better if declarations occured in only one place.
Pieter Schoenmakers
(George Lippincott) writes:
>>As a language designer (yes, I
>>have had the good fortune of being both) VHDL is quite a fantastic
>>package.
> I'm not sure what you mean by "language designer" but from the language
> point of view VHDL doesn't seem that great to me.
That's putting it midly, isn't it? Writing a compiler for VHDL is as much
fun as having brain surgery performed upon you a dozen times a day.
--Tiggr
Janick Bergeron
>jan...@bnr.ca (Janick Bergeron) writes:
>
>>In article <1993Feb23....@ole.cdac.com> geo...@ole.cdac.com (George Lippincott) writes:
>>>Component definitions are completely unnecessary because there is a requirement
>>>that the entity declaration be analyzed before the component declaration. If
>>>the database doesn't already contain the entity declaration when the analyzer
>>>comes across a component, it will be necessary to recompile in the future. Why
>>>not just use the entity itself to get the port and generic information?
>
>>Only if you configure the component to a specific entiry/architecture
>>in the same library unit.
>
>If you configure it to be bound to an entity in another library unit, I
>believe that entity must still have been compiled first.
Re-reading my own sentence, I think I wasn't too clear. You need to have
the entity compiled only when the configuration statement configuring the
component(s) is compiled. If that configuration statement appears next
to your component declaration as in:
component FOO
...
end component;
for all:FOO use entity BAR(BEH);
then the entity has to be compiled before this library unit can be compiled.
On the other hand, if an external configuration specification is used,
the entity need only be compiled before the configuration specification
is compiled, not this library unit.
>>The component/entity decoupling is necessary if you use external configurations
>>or want to write technology-indenpendent netlists.
>It isn't really necessary. This could be done by simply writing an architecture
>for the "2-input AND gate" which had one child -- the TI TGB1000 AN210 or the
>LSI 100k AD2. In many ways this is an easier way to implement technology-
>independent netlists.
I'm sorry but I don't follow your here...
>The one good thing about component declarations and configurations is the
>ability to use them for back-annotation of delays -- but then this turns
>out to be illegal in VHDL-87 (even though some VHDL vendors allowed it).
Generics could be set when instantiating the entity directly (if VHDL
were to use the structural description you propose). Decoupling is not
needed for that at all. I'm not sure what you are saying is illegal
in VHDL-1076 (there is no such thing as VHDL-87)... Anyway, using
generics to pass back-annotation values is not very practical in
my opinion, not counting on the fact that a popular VHDL vendor does
not properly handle the setting of generics at run-time... At that level,
I'd rathe ruse a conventional gate-level simulator.
>In my opinion, their ability to be used for specifying technology
>independent netlists doesn't compensate for the confusion they create.
If you use the default configuration mechanism (last architecture
analyzed for an entity with the same name as the component) the confusion
can be minimized. As a previous poster pointed out, they become analogous
to forward function declarations in .h files.
>Sometimes designers will make a change to the entity and forget to change
>the component everywhere else it is declared. This doesn't always result
>in an error.
That is the most cumbersome part. But they can be minimized by using default
values for in ports, unconnected out ports and conversion functioons
in the configuration statement. If the changes to the entity were that
significant, you will have to change all the instantiation statements
anyway, so changing the component declaration is not that much more
work. If you put your component declaration in a package, you can
minimize the amount of changes and effectively create a .h file for
your entity.
Paul J Menchini -- Personal Account
>
>Component definitions are completely unnecessary because there is a requirement
>that the entity declaration be analyzed before the component declaration. If
>the database doesn't already contain the entity declaration when the analyzer
>comes across a component, it will be necessary to recompile in the future. Why
>not just use the entity itself to get the port and generic information?
George, where do you derive this? I believe that this statement (entity must
be analyzed before component) is wrong if you're referring to a component which
represents an entity.
Component declarations exist in VHDL because of two requirements: (1) the need
to support top-down design (where you can use a subcomponent prior to designing
it) and (2) the need to support strong type checking across interfaces. Since
in top-down design, the entity declaration need not exist, you create a
component declaration to describe the essentials of the component you're using.
This extra level leads to a two-step instancing (i.e., you first instance a
component, then bind that component instance to an entity-architecture pair).
These two steps may seem to be a nuisance, but they're to support another VHDL
requirement: life-cycle support. It's very common among our brethern in the
military (and in commercial companies that support the military) to support
equipment that's 25 or more years old. Imagine trying to buy vacuum tubes!
(For those of you engineers that don't remember these, they work somewhat like
FETs ;-) Hence, one of VHDL's requirments was to support the insertion of
new technology for old. In VHDL (unlike any other HDL), you can plug in a
486 (design entity) into a socket (component instance) intended for an 8086
without rewriting the instancing architecture.
"But," you say to yourself, "that's all well and good, but I'll *never* need
such a facility, so all this power just gets in my way." Yes, we realize this,
so in VHDL 92, you can directly instance a design entity (entity+architecture)
or even a configuration declaration. Viola, no more two-step binding (and the
flexibility it gives. Note that this is applicable to only bottom-up designs,
however. Now, the instanced entity interface *must* have been analyzed prior
to the analyisis of the instancing architecture.
>Every time I show this to a new user, they think it is ridiculous that they have
>to cut and paste the entity declaration, change the word entity to component, delete
>the "is" and change the label after the end to "component". I have to agree
>and fortunately in VHDL 92 I believe it will be possible to directly instantiate
>an entity without jumping through this hoop.
Without context, nearly everything we all do is ridiculous. (If you think I'm
overstating my case, go to a cocktail party or some other function where they
think engineers drive trains and try to explain to someone what it is that you
do for a living.)
Anyway, remember that in 80 years, none of this'll matter!
--P
-------------------------------------------------------------------------------
Paul Menchini Voice: 919-990-9506
2 Davis Drive Fax: 919-990-8561
P.O. Box 13036 Internet: me...@rock.concert.net
Research Triangle Park, NC 27709-3036
"If an undetectable error occurs, the processor continues as if no error had
occurred." -- IBM System/360 Principles of Operation
"The base type of a type mark is, by definition, the base type of the type or
subtype denoted by the type mark." -- IEEE Std 1076-1987
"In particular, a type is closely related to itself."
-- IEEE Std 1076-1992/A
"Elaboration of a private type declaration creates a private type."
-- IEEE Std 1076-1992/A
"I am not a number, I am a free man!"
-- Number 6
-------------------------------------------------------------------------------
--
-------------------------------------------------------------------------------
Paul Menchini Voice: 919-990-9506
2 Davis Drive Fax: 919-990-8561
George Lippincott
>In article <1993Feb23....@ole.cdac.com> geo...@ole.cdac.com (George Lippincott) writes:
>>
>> ...
>>
>>Component definitions are completely unnecessary because there is a requirement
>>that the entity declaration be analyzed before the component declaration. If
>>the database doesn't already contain the entity declaration when the analyzer
>>comes across a component, it will be necessary to recompile in the future. Why
>>not just use the entity itself to get the port and generic information?
>George, where do you derive this? I believe that this statement (entity must
>be analyzed before component) is wrong if you're referring to a component which
>represents an entity.
I was wrong on this. The entity must be there before the configuration is
analyzed. Most people I've seen use components that match the entity so that
they can rely on the default configuration. In this context the component
must be newer than the entity. At least the VHDL simulator I use seems to
enforce this rule. If this is not true I would like to know because it is
an annoying part of using VHDL.
I once tried putting all my component definitions in one package and ended
up with a situation where no matter what order I analyzed the files, something
would be out of date. I had to split the components into two different
packages to solve the problem.
>Component declarations exist in VHDL because of two requirements: (1) the need
>to support top-down design (where you can use a subcomponent prior to designing
>it) and (2) the need to support strong type checking across interfaces. Since
>in top-down design, the entity declaration need not exist, you create a
>component declaration to describe the essentials of the component you're using.
>This extra level leads to a two-step instancing (i.e., you first instance a
>component, then bind that component instance to an entity-architecture pair).
>These two steps may seem to be a nuisance, but they're to support another VHDL
>requirement: life-cycle support. It's very common among our brethern in the
>military (and in commercial companies that support the military) to support
>equipment that's 25 or more years old. Imagine trying to buy vacuum tubes!
>(For those of you engineers that don't remember these, they work somewhat like
>FETs ;-) Hence, one of VHDL's requirments was to support the insertion of
>new technology for old. In VHDL (unlike any other HDL), you can plug in a
>486 (design entity) into a socket (component instance) intended for an 8086
>without rewriting the instancing architecture.
>"But," you say to yourself, "that's all well and good, but I'll *never* need
>such a facility, so all this power just gets in my way." Yes, we realize this,
>so in VHDL 92, you can directly instance a design entity (entity+architecture)
>or even a configuration declaration. Viola, no more two-step binding (and the
>flexibility it gives. Note that this is applicable to only bottom-up designs,
>however. Now, the instanced entity interface *must* have been analyzed prior
>to the analyisis of the instancing architecture.
Actually, If I wanted to stick a 486 in a 8086 socket, I would probably
write an 8086 architecture which had the appropriate code to do this. It
would be easier to see what was happening in a VHDL debugger and would be
better documentation. Reconnecting ports in a configuration seems like
a very poor design style to me. Using a configuration to select an
architecture is one thing, but this ability to change the port connections
seems like something that should be used about as often as the GOTO statement
in C.
Janick Bergeron
>I was wrong on this. The entity must be there before the configuration is
>analyzed. Most people I've seen use components that match the entity so that
>they can rely on the default configuration. In this context the component
>must be newer than the entity. At least the VHDL simulator I use seems to
>enforce this rule. If this is not true I would like to know because it is
>an annoying part of using VHDL.
It is a restriction imposed by your VHDL toolset (could it be Synopsys?).
We still use the old Intermetrics tools and they impose no such restrictions.
You should see the generated C code for the configuration stuff: pretty
ugly. It is one of the most difficult portion of VHDL to implement
(because of the three types of config: internal, external and default).
Does your simulator handle configuration specifications that cover many
levels of hierarchy ? or does it require explicit configuration (either
to an entity/architecture pair or to a configuration specification) in
the architecture instantiating the components ? and if not will
immediately assume a default binding ?
If that is the case, your tool is not implementing VHDL quite right.
You should be able to write a n-level structural description that does
not contain a single confugration statement, compile each entity/archi-
tecture pair in arbitrary order then link everything using a SINGLE
configuration specification (which MUST be analyzed last).
George Lippincott
David Barton wrote:
>
>Mr. Lippincott, I include the following which I intended to post;
>however, it is longer than our posting limits, so did not make it. I
>email it for your consideration, if you like.
> language point of view VHDL doesn't seem that great to me. It's
> grammer is context sensitive which makes parsing less efficient and
> particular order. The syntax has several inconsistencies which
> constructs such as component definitions which needlessly
> complicate the language and create more potential for errors
> (because they require that the same information be specified more
> than once).
>
>want to pontificate about the "language point of view" you should
>learn the terms. VHDL is not "context sensitive"; a context sensitive
>language includes productions like "aBc -> addefg", where there is
>context surrounding the non-terminal on the left side of the
>production. VHDL does not have such productions. What I *think* you
>mean is that lexical analysis of VHDL requires a certain amount of
>syntactic and semantic analysis; the lexical constructs include things
>like "TYPE_name" which requires semantic analysis before the lexical
>unit can be determined. I call this "type-dependent", but it has no
>generally recognized name of which I am aware.
I apologize if I have used the term incorrectly. I don't quite follow
what you are trying to say in your example. I think you are right about
what I meant, however. Basically my opinion is that if this language is
to be a standard it should have a grammer that is easy to write applications
for yet powerful. With a few minor changes, it could have been possible
to write a YACC grammer for VHDL. The ambiguity between function calls
and indexed names is one example. If the square brackets were used for
indexed names (as they are in many other languages) there would be no such
ambiguity in the grammer. Furthermore, this wouldn't have restricted the
language in any way. There are a lot of rules where a type-mark is required.
The syntax for these constructs could have been changed slightly to remove
such ambiguities without taking away any useful feature of the language.
I would even go so far as to say that the LRM should have specified the
grammer using YACC and LEX. This would not have been a big task yet it
would have made the language much easier to implement and I think we would
be seeing more VHDL tools available today. We would definately be seeing
better quality VHDL tools and some of the companies (such as Mentor Graphics)
who only support a subset of the language in their simulators would probably
at least be supporting a larger subset. It would also make the language
much more usable for university research and internal CAD departments of
large companies.
Paul J Menchini -- Personal Account
>write an 8086 architecture which had the appropriate code to do this. It
>would be easier to see what was happening in a VHDL debugger and would be
>better documentation. Reconnecting ports in a configuration seems like
>a very poor design style to me. Using a configuration to select an
>architecture is one thing, but this ability to change the port connections
>seems like something that should be used about as often as the GOTO statement
>in C.
This is certainly possible, but your statement that it is "better" is a
value judgement. The ability to use design entities that don't have quite
the correct form factor, pinouts, etc. was felt to be important. It doesn't
have to be used, although in VHDL87 it causes unavoidable ramifications. We've
removed these ramifications in VHDL92.
Perhaps you're right, this facility should be seldom used. But if it's not
there, it can *never* be used. Hopefully in VHDL 92 we've struck the right
balance between ease of use and power. But remember, you can only use the
one-step binding when you're going (at least somewhat) bottom-up: design the
entity, then instance it. (Of course, the architecture doesn't need to exist
until you're ready to execute....)
It hasn't come up yet in this discussion, so let me just point out that there
are a set of default binding rules, that let you *almost* ignore the fact that
there are two steps to binding. If your component has the same name as the
entity you wish to bind and all the port names, types and modes (in, out, etc.)
match, then you don't have to write a configuration. You *do* still have to
write the component however, at least until VHDL 1992 tools become available.
Oh well....
--P
-------------------------------------------------------------------------------
Paul Menchini Voice: 919-990-9506
2 Davis Drive Fax: 919-990-8561
P.O. Box 13036 Internet: me...@rock.concert.net
Research Triangle Park, NC 27709-3036
"I reserve the right to become smarter in the future."
The Universal Hacker
Well, that depends on what your interpretation of a "language designer" is.
I definitely did not mean "writing a compiler" as being the same as
"language designer". Implementing a language and defining a language are two
distinct aspects though one is normally expected to both in tandem.
Dave Rich; x6337
|>
|> Anyway, remember that in 80 years, none of this'll matter!
|>
Paul,
It's nice to see that someone has the right perspective on life.
--
____________________________________________________________
Dave Rich tele 1-508-934-0337 email dav...@cadence.com
Cadence Design, 2 Lowell Research Ctr., Lowell MA 01852-4995
____________________________________________________________
John Messenger
> geo...@ole.cdac.com (George Lippincott) writes:
>
> Component definitions are completely unnecessary because there is a requirement
> that the entity declaration be analyzed before the component declaration. If
> the database doesn't already contain the entity declaration when the analyzer
> comes across a component, it will be necessary to recompile in the future.
This is not correct for VHDL in general. This is explained in the
Standards Interpretations in Issue Report 5.
Component declarations are particularly useful as wiring-up tools.
The analogy of plugging an IC into a socket is a good way to think
about them. The question of when the instantiated component's entity
needs to be analysed is an implementation issue (ceratinly for
1076-1987) but one which ought to be clarified and fixed.
Unfortunately different vendors do this in such different ways that
it is difficult to see how they could agree on a common approach.
The interpretations seem to favour a SOFT approach, where most of
this sorting out happens at elaboration time. I don't know of an
implementation of this approach.
-- John
--
John Messenger (jmess...@cix.compulink.co.uk) Tel: +44 904 692700
Paul J Menchini -- Personal Account
>
>I would even go so far as to say that the LRM should have specified the
>grammer using YACC and LEX. This would not have been a big task yet it
>would have made the language much easier to implement and I think we would
>be seeing more VHDL tools available today. We would definately be seeing
>better quality VHDL tools and some of the companies (such as Mentor Graphics)
>who only support a subset of the language in their simulators would probably
>at least be supporting a larger subset. It would also make the language
>much more usable for university research and internal CAD departments of
>large companies.
I must disagree here. The purpose of the LRM grammar is expositional, not
for tool processing. I headed the team that designed and wrote one particular
1076-1987 tool, one which processes the entire language. We used a LALR(1)
grammar generator, and it took me just a few weeks of work to develop a
suitable grammar from the presentation grammar. (For those of you who aren't
context-free grammar experts, the tool I used is equivalent to YACC and LEX
in its processing power.)
So, if company X doesn't have a full implementation, I don't believe it's
because they haven't been able to parse the language....
--Paul
Daniel S. Barclay
Slow down. Understand the purpose of VHDL constructs before criticizing them.
Then you all can focus your criticism and effort on fixing the problems right.
> ... It's grammer [sic] is context
> sensitive which makes parsing less efficient and imposes the requirement
> that design units be compiled in a particular order. ...
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* How does the grammar's being context sensitive relate to compilation order?
Are you misusing the lexing/parsing term of "context sensitive"?
(BTW, does anyone recall if the grammar actuallyis context sensitive
or not?)
* There are some requirements in the compilation order, but I wonder if you
think they are stronger than there actually are. I don't know if your
impressions and knowledge come from the language or from a particular
implementation. A poor implementation might require more recompilation
than the language itself requires.
Naturally, you have to analyze a package declaration before any design
unit using the package. But you can change the package body (to change
function definitions or the values of deferred constants) without re-
analyzing anything else. Also naturally, if you analyze an entity
declaration, you must re-analyze any architecture bodies of that
entity. But you don't necessarly have to re-analyze architectures (of
other entities) that instantiate the re-analyzed entity.
> There are constructs such as component definitions which needlessly complicate
^^^^^^^^^^^^^^^^^^^^^
> the language and create more potential for errors (because they require that the
> same information be specified more than once).
* VHDL component instantiations don't needlessly complicate the language. They
have a function: they support top-down design.
One can define the assumed interface of a subcomponent (in a component
declaration) and instantiate it (in a component instantiation
statement) before defining the final interface of the component
(in an entity declaration's entity header). The component might be
designed with extra ports or generics not originally envisoned. With
component declarations that are separate from entity declarations, the
instantiating architecture does not have to be edited and reanalyzed.
A separately analyzed configuration declaration can rename the
component and the ports and generics, and connect additional ports and
generics.
BY THE WAY: VHDL "1992" was modified to address your (implicit) complaint that
FOR BOTTOM-UP DESIGN, separate component declarations are inconvenient
and error-prone.
In VHDL 1992, a component instantiation statement may instantiate an
entity directly, without any component declaration. This allows those
doing bottom-up design to avoid the inconvenience and duplicated data
(and risk of errors) of syntactic constructs necessary to support top-
down design.
--
------------------------------------------------------------------------------
Daniel S. Barclay --who's still searching for a good
CAD Language Systems, Inc. signature, not liking any of his recent
Suite 101, 5457 Twin Knolls Rd. feeble attempts to improve on the whiny:
Columbia, MD 21045 USA Why can't _I_ think of a good signature?
Victor Berman; x6276
portion of the total effort involved in implementing a VHDL tool
set. Publishing a grammar suitable for an automatic parser generator
would not make a single additional full language tool set available
and in fact several such grammars have been made available. The
bnf productions given in the VHDL LRM are meant to be explanatory
and aimed at human readability, not tool implementation.
Your dislike for VHDL is certainly your own choice, however your
insistence that the language world revolve around YACC and LEX
forces me to question your taste in these matters.
Victor
Paul J Menchini -- Personal Account
> (BTW, does anyone recall if the grammar actuallyis context sensitive
> or not?)
It depends on what you man by "grammar." If we look at conventional LALR(1)
compiler-compiler tools (such as yacc and lex), or even conventional top-down
recursive-descent parsers, there are usually two grammars, a lexical grammar
and a syntactic grammar. If we make this conventional distinction, then the
syntactic grammar is not context-sensitive (which is fortunate, else you
couldn't use yacc or similar), but the lexical grammar is (consider
encountering the sequence of characters "'B'": it could either be the
character literal 'B', or the middle of the attribute name "A'B'C"; it depends
on what came before (and after)). However, context-sensitive lexical grammars
are not unusual and easy to process (at least with some tools). Failing that,
hand-crafted lexers are easy to write, even when context sensitivity is needed;
typically, they're as fast or faster than their automatically generated
bretheren, as well.
-------------------------------------------------------------------------------
Paul Menchini Voice: 919-990-9506
2 Davis Drive Fax: 919-990-8561
P.O. Box 13036 Internet: me...@rock.concert.net
Research Triangle Park, NC 27709-3036
"Pay no attention to that man behind the curtain!"
-- The Wizard of Oz
-------------------------------------------------------------------------------
George Lippincott
impression that I think "VHDL sucks real bad").
dan...@clsi.COM (Daniel S. Barclay) writes:
>geo...@ole.cdac.com (George Lippincott) writes:
>* There are some requirements in the compilation order, but I wonder if you
> think they are stronger than there actually are. I don't know if your
> impressions and knowledge come from the language or from a particular
> implementation. A poor implementation might require more recompilation
> than the language itself requires.
This was the case. My impressions were based on a particular simulator which
has the requirement that component definitions be compiled after the entity
which they are configured to. Fortunately, it was simply a faulty implementation
which apparently has been corrected in their latest release. I am glad that
this isn't a language requirement after all, since it caused a lot of frustration.
>* VHDL component instantiations don't needlessly complicate the language. They
> have a function: they support top-down design.
> One can define the assumed interface of a subcomponent (in a component
> declaration) and instantiate it (in a component instantiation
> statement) before defining the final interface of the component
> (in an entity declaration's entity header). The component might be
> designed with extra ports or generics not originally envisoned. With
> component declarations that are separate from entity declarations, the
> instantiating architecture does not have to be edited and reanalyzed.
> A separately analyzed configuration declaration can rename the
> component and the ports and generics, and connect additional ports and
> generics.
> In VHDL 1992, a component instantiation statement may instantiate an
> entity directly, without any component declaration. This allows those
> doing bottom-up design to avoid the inconvenience and duplicated data
> (and risk of errors) of syntactic constructs necessary to support top-
> down design.
I guess I just don't understand why component intantiations and duplicated data
are necessary for top-down design. Why can't you just declare an entity and
instantiate it before it's architecture is written? Isn't this top-down design?
It seems to me that the main feature of VHDL that supports top-down design is it's
ability to manage multiple architectures for a given entity.
As far as changing port maps inside of a configuration, this doesn't seem
like a good design practice to me. Rearranging ports inside of a configuration,
is like adding another level to the design hierarchy. I prefer to do this using
an entity and architecture. The example came up before of using a 486 in a design
that previously had an 8086. Instead of using a configuration to do this, I think
it makes more sense to write an architecture for the 8086 that instantiates the 486
and contains the appropriate code to connect the ports and supply defaults to unused
inputs. This would seem to me to be a little more clear and easier to debug.
Is there any advantage in using a configuration to do port mapping rather than using
another entity and architecture?
Michael Chapman
>If we make this conventional distinction, then the
>syntactic grammar is not context-sensitive (which is fortunate, else you
>couldn't use yacc or similar), but the lexical grammar is (consider
>encountering the sequence of characters "'B'": it could either be the
>character literal 'B', or the middle of the attribute name "A'B'C"; it depends
>on what came before (and after)).
VHDL (the language not the syntax description) is context sensitive. For example:
X := F(1);
Is F(1) an 'indexed_name' or a 'function_call'?
You cannot actually parse this correctly (whatever kind of parser you use)
without using the context. In particular is necessary to know whether
F is 'visible' as an array or as a function name in this context.
It is also not possible to resolve this by making the lexical analyser
look up each symbol and deliver a symbol qualifying the type as this
doesn't work in such circumstances as association_lists where you
do not know what the context for the identifiers are until you have parsed
it.
eg F( G(A) => H(3) )
Where G is a function_name and A is the formal_name.
This kind of dependency really makes it hard to parse. The only solution
I have seen is to use a LALR parser (or LR1 it makes no difference) to make
an approximate parse of the langauge (where almost anything like F(....) is
parsed as name_with_parameters) and then a context dependent top down fix
up parse of these tricky bits. Its not trivial to verify that one is still
parsing the same lanaguage.
There are lots of context dependencies in parsing names. I don't really
believe that they are all necessary or bring any advantages to the language
although I disagree strongly with someone else who suggested that
functions should be called with F(X) and arrays indexed with F[X].
(If I write an array on the right hand side of an assignment for example
then it delivers a value associated with the index. Whether this is an
array or a function an irrelevant implementation detail for me. Ie
both should be written the same way).
Once you have got that sorted out, then the fun with overload resolution
starts. (Its not too bad actually).
I *DO* belive that we would have had many more vhdl tools if the grammar had
been simpler. For example the largest part of the effort to write a
simulator is in actually compiling the language. For an interpretive
simulator the parsing part then represents a signifcant part of the effort.
Mike
Paul J Menchini -- Personal Account
>
>This was the case. My impressions were based on a particular simulator which
>has the requirement that component definitions be compiled after the entity
>which they are configured to. Fortunately, it was simply a faulty implementation
>which apparently has been corrected in their latest release. I am glad that
>this isn't a language requirement after all, since it caused a lot of frustration.
Ah. That statement clears things up enormously....
>I guess I just don't understand why component intantiations and duplicated data
>are necessary for top-down design. Why can't you just declare an entity and
>instantiate it before it's architecture is written? Isn't this top-down design?
Strictly speaking, they are not. One could conceptually write the entity
interface, then directly instantiate it (and in fact, one can in VHDL 92).
However, there's always a tension between features and complexity. For
one thing, having component declarations was felt to give multi-design group
designs more flexibility in partitioning the work. And remember, there's the
requirement for "component substitution," the prime purpose for having two-step
binding. Since there's a requirement for two-step binding, it was felt that it
was not too onerous to require people to use component declarations even when
they're not interested. We've somewhat reversed ourselves in 92.
However, there's one very important reason for having component declarations.
If you're using direct instantiation and the entity interface changes for any
reason, it must be re-analyzed, which forces re-analysis of the instantiating
unit. But with a separate component declaration, no such re-analysis is
required. For big designs, this might be a major productivity win.
>It seems to me that the main feature of VHDL that supports top-down design is it's
>ability to manage multiple architectures for a given entity.
You say "toe-may-toe", I say "toe-mah-toe" ....
>As far as changing port maps inside of a configuration, this doesn't seem
>like a good design practice to me. Rearranging ports inside of a configuration,
>is like adding another level to the design hierarchy. I prefer to do this using
>an entity and architecture. The example came up before of using a 486 in a design
>that previously had an 8086. Instead of using a configuration to do this, I think
>it makes more sense to write an architecture for the 8086 that instantiates the 486
>and contains the appropriate code to connect the ports and supply defaults to unused
>inputs. This would seem to me to be a little more clear and easier to debug.
(Don't forget that you can change types and resolution functions across the
interface as well as defaulting unused ports....)
Again, this is your preference. One of the guiding principles behind VHDL was
to not enforce exactly one way of doing things, but to give people a number of
flexible mechanisms which could be exploited in a variety of manners. You
have pointed out that there are multiple ways to solve the problem. Your
preferred method does not exploit one particular feature of the language.
However, not every one thinks as you do. You might consider the effect of
using your component substitution methodology on a much smaller component, such
as a NAND gate, that is instantiated many times in a design. Your method
might have unacceptable overhead....
In any case, you can do exactly what you want, and the particular bit of
--
-------------------------------------------------------------------------------
Paul Menchini 2 Davis Drive P.O. Box 13036 RTP, NC 27709-3036
me...@rock.concert.net Voice: 919-990-9506 Fax: 919-990-8561
Paul J Menchini -- Personal Account
>VHDL (the language not the syntax description) is context sensitive. For example:
Yes, that's true. I spoke a bit too casually. I meant to say that it is
possible to (with a few weeks of work in my case) come up with a context-free
syntactic grammar (by, as you point out, using unification to combine
irresolvable productions which are later sorted out).
But, by your strict criterion, every language I've ever encountered is context-
sensitive.
>
> X := F(1);
>
>Is F(1) an 'indexed_name' or a 'function_call'?
>You cannot actually parse this correctly (whatever kind of parser you use)
>without using the context. In particular is necessary to know whether
>F is 'visible' as an array or as a function name in this context.
BTW, you can't even really understand this example until after detailed
type analysis and overload resolution: The RHS of this assignment might
be BOTH a function call (of no arguments, returning a 1-D array) AND an
index name (indexing the returned array value).
>I *DO* belive that we would have had many more vhdl tools if the grammar had
>been simpler. For example the largest part of the effort to write a
>simulator is in actually compiling the language. For an interpretive
>simulator the parsing part then represents a signifcant part of the effort.
I agree that compiling the language is a significant fraction of the total
effort in processing a description. However, generating a parser is 5% of the
effort of compiling the language, so a simpler grammar may not make much
difference. And, there are compilers for the language that you can buy, so
you may not need to write your own....
--
-------------------------------------------------------------------------------
Paul Menchini 2 Davis Drive P.O. Box 13036 RTP, NC 27709-3036
me...@rock.concert.net Voice: 919-990-9506 Fax: 919-990-8561
Larry Augustin
>In article 10...@rock.concert.net, me...@rock.concert.net (Paul J Menchini -- Personal Account) writes:
>>If we make this conventional distinction, then the
>>syntactic grammar is not context-sensitive (which is fortunate, else you
>>couldn't use yacc or similar), but the lexical grammar is (consider
>>encountering the sequence of characters "'B'": it could either be the
>>character literal 'B', or the middle of the attribute name "A'B'C"; it depends
>>on what came before (and after)).
VHDL inherited this lexical oddity from Ada. A similar lexical
problem arises in parsing Ada.
>VHDL (the language not the syntax description) is context sensitive. For example:
> X := F(1);
>Is F(1) an 'indexed_name' or a 'function_call'?
>You cannot actually parse this correctly (whatever kind of parser you use)
>without using the context.
>In particular is necessary to know whether
>F is 'visible' as an array or as a function name in this context.
>It is also not possible to resolve this by making the lexical analyser
>look up each symbol and deliver a symbol qualifying the type as this
>doesn't work in such circumstances as association_lists where you
>do not know what the context for the identifiers are until you have parsed
>it.
> eg F( G(A) => H(3) )
>Where G is a function_name and A is the formal_name.
>This kind of dependency really makes it hard to parse. The only solution
>I have seen is to use a LALR parser (or LR1 it makes no difference) to make
>an approximate parse of the langauge (where almost anything like F(....) is
>parsed as name_with_parameters) and then a context dependent top down fix
>up parse of these tricky bits. Its not trivial to verify that one is still
>parsing the same lanaguage.
I think that you are expecting far too much of parsing. People have
become spoiled by C where you are able to tell a function call by the
syntax. The abstract syntax tree built by the parser can then
directly build function call nodes, instead of building some more
generic abstract representation, and later resolving it through
semantic analysis. In this particular example, VHDL borrows from Ada
in that "indexing" is a specialized function. We've been dealing with
this sort of thing in Ada compilers for years.
We do exactly what you describe: parse this as a generic "name with
parameters" syntax, and then in the semantic analysis pass assign
attributes indicating the kind of parameterized name. But some people
have been doing this for years for other languages already, so it's not
such a big deal to them.
>There are lots of context dependencies in parsing names. I don't really
>believe that they are all necessary or bring any advantages to the language
>although I disagree strongly with someone else who suggested that
>functions should be called with F(X) and arrays indexed with F[X].
>(If I write an array on the right hand side of an assignment for example
>then it delivers a value associated with the index. Whether this is an
>array or a function an irrelevant implementation detail for me. Ie
>both should be written the same way).
But of course if I'm later modifying that code, the F[X] syntax gives
me a visual clue to how F is implemented, so that I could use F on the
left hand side of an assignment in modifying the code. Thus whether F
is an array or function is very relevant to me as a person maintaining
a piece of code.
>Once you have got that sorted out, then the fun with overload resolution
>starts. (Its not too bad actually).
>I *DO* belive that we would have had many more vhdl tools if the grammar had
>been simpler. For example the largest part of the effort to write a
>simulator is in actually compiling the language. For an interpretive
>simulator the parsing part then represents a signifcant part of the effort.
>Mike
Yes that's true, and it's particularly relevant in the academic
communities. Why do a project using VHDL when 90% of the effort will
have to go into a VHDL front-end?
Larry
Paul J Menchini -- Personal Account
>VHDL inherited this lexical oddity from Ada. A similar lexical
>problem arises in parsing Ada.
Actually, VHDL is harder to lex than Ada, since Ada has on single-character
attributes!
>Yes that's true, and it's particularly relevant in the academic
>communities. Why do a project using VHDL when 90% of the effort will
>have to go into a VHDL front-end?
Most companies who sell VHDL analysis tools have special deals for academics.
Rather than writing your own, you might check a few of them out....
--
-------------------------------------------------------------------------------
Paul Menchini 2 Davis Drive P.O. Box 13036 RTP, NC 27709-3036
me...@rock.concert.net Voice: 919-990-9506 Fax: 919-990-8561
Sunder Singhani
F (G(A) => H(3))
Because ADA doesn't have subelement associations! In which case,
you are sure that G(A) can't be an indexed name (doesn't help parsing
though :-( ). Actually, this whole concept of subelement associations
makes the task of analysis that much harder. Remember that you can
use subelement associations and conversion functions together. eg.
F ( K(G(B)) => H(3) )
where K is a function name, G is a formal name of array type, and B
a constant.
BTW, in one case C lexical analyzer also uses symbol table to determine
the token. This is for declarations using a different type name
than the regular types. eg.
typedef int my_int;
my_int int_var;
The C lexical analyzer returns a typename token for my_int after looking
up the symbol table. This explains the syntax error that C compilers
give if the typedef is missing.
>We do exactly what you describe: parse this as a generic "name with
>parameters" syntax, and then in the semantic analysis pass assign
>attributes indicating the kind of parameterized name.
Another way of doing/describing the above is - parser builds parse tree,
name resolver resolves names and does tree transformations to build
abstract syntax tree, and overload resolution phase prunes the AST.
>>I *DO* belive that we would have had many more vhdl tools if the grammar had
>>been simpler. For example the largest part of the effort to write a
>>simulator is in actually compiling the language. For an interpretive
>>simulator the parsing part then represents a signifcant part of the effort.
>>
>>Mike
>
>Yes that's true, and it's particularly relevant in the academic
>communities. Why do a project using VHDL when 90% of the effort will
>have to go into a VHDL front-end?
>
>Larry
VHDL is a complex language to compile. After going through the task
of implementing a VHDL analyser myself, I wouldn't want anyone to suffer
this torture. IMHO, people wanting to use VHDL as a front end
to their system (for simulation, synthesis, verification etc) should
just use the Intermediate Representation and Procedural Interface to
it. No, I am not asking for another standard (which could be nice).
Ask your favorite vendor to give this facility.
--
Sunder Singhani
Viewlogic Systems,
ssin...@viewlogic.com
Hansjoerg Toepfer
>In article 10...@rock.concert.net, me...@rock.concert.net (Paul J Menchini -- Personal Account) writes:
>>If we make this conventional distinction, then the
>>syntactic grammar is not context-sensitive (which is fortunate, else you
>>couldn't use yacc or similar), but the lexical grammar is (consider
>>encountering the sequence of characters "'B'": it could either be the
>>character literal 'B', or the middle of the attribute name "A'B'C"; it depends
>>on what came before (and after)).
>VHDL (the language not the syntax description) is context sensitive. For example:
> X := F(1);
^^^^^^^^^^
You should distinguish (simple) parsing from semantic checks !
In my YACC grammar 'function_call' is part of 'indexed_name'.
The correct semantic is then checked by an suboutine.
>Mike
--------------------------------------------------------------------------------
__ __ _________ Hansjoerg Toepfer Tel.: +49-203-3792583
/ / / / /__ ___/ University of Duisburg FAX : +49-203-370439
/ /_/ / / / FB 9 / DV (Data Processing)
/ __ / / / Bismarckstr. 81
/ / / / / / D-4100 Duisburg 1, Germany
/_/ /_/ /_/ e-mail: toe...@du9ds4.fb9dv.uni-duisburg.de
--------------------------------------------------------------------------------
David Barton
Chapman) writes:
In article 10...@rock.concert.net, me...@rock.concert.net (Paul J
Menchini -- Personal Account) writes:
>If we make this conventional distinction, then the syntactic
>grammar is not context-sensitive (which is fortunate, else you
>couldn't use yacc or similar), but the lexical grammar is
>(consider encountering the sequence of characters "'B'": it could
>either be the character literal 'B', or the middle of the
>attribute name "A'B'C"; it depends on what came before (and
>after)).
VHDL (the language not the syntax description) is context
sensitive. For example:
X := F(1);
Is F(1) an 'indexed_name' or a 'function_call'? You cannot
actually parse this correctly (whatever kind of parser you use)
without using the context. In particular is necessary to know
whether F is 'visible' as an array or as a function name in this
context.
I can't quite believe that this discussion has been going on so long.
We do have come compilation theorists here; Paul, in particular,
should have known better. (Sorry, Paul, but you really should have.
Too many aimless discussions in VASG meeting have damaged your
language lawyer skills :-)).
A language is context sensitive if it includes productions like:
xBy -> xabcdefy
i.e., whether the *production* is valid depends on the symbols around
it. The VHDL grammar (lexical and syntactic) has no such productions.
Therefore, neither is context sensitive. This definition is not hard
to find. It is in any elementary text on languages and compilation.
Theoretical results concerning context sensitive grammars do not apply
to VHDL.
VHDL is somewhat hard to parse (although I disagree with some of the
statements made here). In most cases, this was a trade-off that was
made with knowledge. Parsing difficulties are resolved by changing
the language to distinguish ambiguities syntactically, at the expense
of writing ease and readability. These issues were discussed in the
original VASG meetings, and a fairly wide ranging decision in favor of
writing ease was made early on. The language reflects this.
Dave Barton
d...@hudson.wash.inmet.com
George Lippincott
>to not enforce exactly one way of doing things, but to give people a number of
>flexible mechanisms which could be exploited in a variety of manners. You
>have pointed out that there are multiple ways to solve the problem. Your
>preferred method does not exploit one particular feature of the language.
>However, not every one thinks as you do. You might consider the effect of
>using your component substitution methodology on a much smaller component, such
>as a NAND gate, that is instantiated many times in a design. Your method
>might have unacceptable overhead....
Lets say I have a design with a gate that I call nand2 which is used throughout
the design. I now want to retarget the design to another vendor where the gate
is called, say ND2 and the port names are different. There are two ways to do this.
I can write an architecture for my NAND2 entity which maps it to the ND2 or I can
use a configuration to map all of the NAND2 components to ND2.
Correct me if I'm wrong, (you mentioned that not everyone thinks like I do about
this methodology and I am just trying to understand what advantage someone would
see in using the configurations in this context) but it seems to me that using the
configuration method for technology-independent design has more overhead for these
reasons:
* Using architectures you can continue to use default configurations and the
mapping is done in one place.
* Using configurations I believe the mapping must be done once for each
instance in the hierarchy that is being configured. The configuration
statement is complex and must match the hierarchy of the design. If the
design hierarchy is later modified, the configuration might also need to be
modified.
* Neither method requires anything to be re-analyzed, although the new
architecture and the new configuration will have to be analyzed of course.
If there is something I'm not considering I would be interested in knowing what
it is.
Stephen J Bevan
David Barton wrote:
>production. VHDL does not have such productions. What I *think* you
>mean is that lexical analysis of VHDL requires a certain amount of
>syntactic and semantic analysis; the lexical constructs include things
>like "TYPE_name" which requires semantic analysis before the lexical
>unit can be determined. I call this "type-dependent", but it has no
>generally recognized name of which I am aware.
The term I prefer, since it is reasonably standard, is "inherently
ambiguous" as defined around page 48 of Gries' book on compiler
design.
I would even go so far as to say that the LRM should have specified the
grammer using YACC and LEX. This would not have been a big task yet it
would have made the language much easier to implement and I think we would
be seeing more VHDL tools available today. We would definately be seeing
better quality VHDL tools and some of the companies (such as Mentor Graphics)
who only support a subset of the language in their simulators would probably
at least be supporting a larger subset. It would also make the language
much more usable for university research and internal CAD departments of
large companies.
1. A language designer should have a damn good reason for defining a
language with an inherently ambiguous grammar. In the case of VHDL
it seems to me it just inherited the awkward bits from Ada.
2. It is generally not too difficult to deal with the "broken"
grammars that designers come up with. There are a number of
different techniques and they are documented in compiler textbooks.
(Though I'll repeat, if at all possible making the grammar
unambiguous it makes life much easier all round.)
3. The syntax of a language is only a _small_ part, though the one
that the user sees most often, of a language. There are _many_
more problems for the unwary once you try to deal with the context
conditions and semantics of a language. These are the issues that
generally make producing a high quality tool difficult, not the
syntax.
4. If you want a notation to standardise on, I'd suggest Wirth's EBNF.
all with a big IMHO of course,
bevan
Daniel S. Barclay
> >* ... I don't know if your
> > impressions and knowledge come from the language or from a particular
> > implementation. A poor implementation might require more recompilation
> > than the language itself requires.
>
> This was the case. My impressions were based on a particular simulator which
> has the requirement that component definitions be compiled after the entity
> which they are configured to. Fortunately, it was simply a faulty implementation
> ...
Gross! Yeah, that would make VHDL a lot harder to use than it should be.
> >* VHDL component instantiations don't needlessly complicate the language. They
> > have a function: they support top-down design.
> > ...
>
Warning for my following responses: I'm about at the limit of my knowledge of which
style(s) of top-down design the language tries to support. I'm a "language lawyer" and
tool builder, so I have little experience actually modeling with VHDL. I'm defending
the language's support of various methodologies, not arguing that you should use this
version of top-down design.
> I guess I just don't understand why component intantiations and duplicated data
> are necessary for top-down design.
You're right; they aren't necessary for all top-down design styles. (Read on.)
> Why can't you just declare an entity and
> instantiate it before it's architecture is written? Isn't this top-down design?
Yes it is one style of top-down design. I think VHDL tries to support a different style
too. (I don't know if anyone uses it, or how good or bad a style it is.)
Let's say you think you need to partition one level of your design into blocks. You
determine the necessary interface (ports and generics) and then declare and instantiate
a component. Next there are have (at least) two case. In the first case, you must
design the component, starting by declaring an identical entity declaration (with the
duplicated data). However, the second case is when there is a cell or chip (or board,
etc.) that already exists and will serve the function, but doesn't exactly have the same
ports, generics, or even data types. VHDL lets you adjust for those differences using
configuration constructs without forcing you to use an additional entity/architecture
pair.
> It seems to me that the main feature of VHDL that supports top-down design is it's
> ability to manage multiple architectures for a given entity.
No argument.
> As far as changing port maps inside of a configuration, this doesn't seem
> like a good design practice to me. Rearranging ports inside of a configuration,
> is like adding another level to the design hierarchy. I prefer to do this using
> an entity and architecture. The example came up before of using a 486 in a design
> that previously had an 8086. Instead of using a configuration to do this, I think
> it makes more sense to write an architecture for the 8086 that instantiates the 486
> and contains the appropriate code to connect the ports and supply defaults to unused
> inputs. This would seem to me to be a little more clear and easier to debug.
Just to make sure, you are aware that port rearranging can be done inside an architecture
with a configuration specification, in addition to inside a configuration declaration
with a component configuration, right?
This all may also depend on the magnitude of the rearrangement. For sticking a 486 in
place of a 8086, I'd probably do it your way with an entity/architecture because the pair
could represents a board holding a 486 and plugging into a 8086 socket (if this example
is valid enough). For smaller rearrangement, say mapping component declaration ports of
type BIT to entity declaration ports of type std_logic, I'd use a configuration
specification or a component configuration.
Note also that configuration declarations let you stitch together a design and make
adjustments without editing (and reanalyzing) your architectures. This has good and
bad points.
> Is there any advantage in using a configuration to do port mapping rather than using
> another entity and architecture?
For port mapping of limited magnitude, I think that using configuration constructs to
do configuration is probably clearer that creating a separate entity/architecture that
appears to be a model but really just reconfigures ports.
Sunder Singhani
>
>I can't quite believe that this discussion has been going on so long.
>We do have come compilation theorists here; Paul, in particular,
>should have known better. (Sorry, Paul, but you really should have.
>Too many aimless discussions in VASG meeting have damaged your
>language lawyer skills :-)).
>
>A language is context sensitive if it includes productions like:
>
> xBy -> xabcdefy
>
>i.e., whether the *production* is valid depends on the symbols around
>it. The VHDL grammar (lexical and syntactic) has no such productions.
>Therefore, neither is context sensitive. This definition is not hard
>to find. It is in any elementary text on languages and compilation.
>Theoretical results concerning context sensitive grammars do not apply
>to VHDL.
I think you are forgetting the Chomsky hierarchy shown in an elementary
text on language theory. A context free language is also a context
sensitive language! The set of CFLs is a proper subset of set of CSLs.
This is how a CSL is defined in a standard text -
A -> B
where B is at least as long as A. What you have defined above is a normal
form for representing CSLs.
If the semantic rules of a language are combined with the syntax, you
would surely get a CSL. To simplify the task of compilation, a CFG
is specified for writing a parser. But, that doesn't make the language
a CFL. What Mike had described in an earlier posting was just a valid
example of a semantic rule which makes the language context sensitive.
The visibility rules, overloading rules, type checking rules etc
would surely make a language context sensitive.
IMHO this discussion should be taken to comp.compilers in the future.
Why bore newsgroup readers with these esoteric details ;-)
-Sunder
Michael Chapman
>A language is context sensitive if it includes productions like:
>
> xBy -> xabcdefy
>
>i.e., whether the *production* is valid depends on the symbols around
>it. The VHDL grammar (lexical and syntactic) has no such productions.
>Therefore, neither is context sensitive. This definition is not hard
>to find. It is in any elementary text on languages and compilation.
>Theoretical results concerning context sensitive grammars do not apply
>to VHDL.
We must distinuish between a context free grammar, and a context
free language.
VHDL has a context free grammar (which means exactly what you describe
above) but the language which is described by this grammar is context
sensitive.
Take for example the following context free grammar
S -> X
S -> Y
X -> a
Y -> a
where a is the only terminal. The only valid program in this language is
'a'. You cannot tell how it was generated from S. Ie the lanugage is
ambiguous to parse. If the semantics associated with the productions X and
Y are different, then the meaning of a program in this language can be
ambiguous.
A language is context sensitive if more than one parse tree can derive
a given program and that other information must be used to decide which
is the correct parse tree. If it is not possible to decide among the
parse trees then the language is ambiguous.
VHDL *is* definitely context sensitive.
I take it that the designers of the language
did their homework and ensured that it was not ambiguous.
So in the original example of
x := F(1);
you can only reconstruct the steps which where taken to derive this sequence
of terminals from the start symbol in the grammar (design_file) by using the
context of the definition of F. There are (at least) three parse trees for this
simple example all of which can be derived for variable_assignment_statement
and in all of which F(1) is derived from primary. (I had only considered
the first two in my original article as only the first two apply in ADA).
primary -> function_call -> name ( actual_parameters) -> ..... F(1)
Ie call to a function F with parameter 1
primary -> name -> indexed_name -> prefix ( expression ) ->
name ( expression ) ->
simple_name ( expression ) ..... -> F(1)
Ie element 1 of array F
or
primary -> name -> indexed_Name -> prefix (expression ) ->
function_call ( expression ) -> ...
Ie element 1 of the array which is the result of the parameterless function F.
IE it is not possible to construct a parse tree using the grammar given in the
VHDL standard without using some context.
VHDL would be a considerably simple language without any significant reduction
in expressive power if for overload resolution only the types of the parameters
for subprograms or operators where considered and not the result types as well.
This makes it possible to understand which subprogram is being called by simply
looking at the types of its operands without having to consider the context
in which this subprogram is being called. This would also correspond better to
how most people think than the present language. (What a subprogram does then
depends exclusively on what you give it and not what you want from it in
a certain context!!).
Everything said here (except for the parameterless function) applies equally to
ADA.
Mike
David Barton
(Sunder Singhani) writes:
I think you are forgetting the Chomsky hierarchy shown in an
elementary text on language theory. A context free language is also
a context sensitive language! The set of CFLs is a proper subset of
set of CSLs. This is how a CSL is defined in a standard text -
A -> B
where B is at least as long as A. What you have defined above is a
normal form for representing CSLs.
Come, come. In discussions such as this, where we are discussing the
merits of various languages from the point of view of parsing
difficulty, the use of the term refers to the full generality of
context senstive grammars, not subsets such as context free grammars,
regular languages, and finite state automata. In particular, results
concerning the intrinsic difficulty of parsing general CSLs, including
their NP-completeness, do not apply to subsets such as context free
grammars. And I thought I was being pedantic!
If the semantic rules of a language are combined with the syntax,
you would surely get a CSL. To simplify the task of compilation, a
CFG is specified for writing a parser. But, that doesn't make the
language a CFL. What Mike had described in an earlier posting was
just a valid example of a semantic rule which makes the language
context sensitive. The visibility rules, overloading rules, type
checking rules etc would surely make a language context sensitive.
Context sensitive grammars are not sufficient to check semantics
rules; you must convey state in some form, such as is done in
attribute grammars and the like. A semantic rule does not "make the
language context sensitive" in any sense that I can decipher. A
sentence in the language is a sentence in the language. The fact that
many grammars are deliberately complicated to make the use of semantic
rules easier (this occurs in yacc grammars frequently) does not make
them "context sensitive"; the semantic rules are not part of the
language. Games played by compiler writers do not change this.
IMHO this discussion should be taken to comp.compilers in the
future. Why bore newsgroup readers with these esoteric details ;-)
Because claims have been made about the context sensitivity of VHDL,
which invokes general results such as the NP-completeness of parsing
algorithms. These should be corrected.
Dave Barton
d...@hudson.wash.inmet.com