Please see my notes below.
Regards,
James Goeke
>
>Peter,
>
>
...
>
>Architectures (or "architecture bodies", as they were originally refered to)
are to entity (interface) declarations as package bodies are to package
declarations. The only significant difference w.r.t. scope and visibility is
that we wanted to allow alternative architectures, whereas one package body was
deemed sufficient. The need to allow multiple architectures led to a
requirement for names on the architectures.
>
++++
The use of multiple/different architectures for a single entity is a very
powerful and useful tool. An example of where we use this frequently is
embedded memory blocks. We will usually have a very high level behavorial model
that we write that is optimized for speed. We will have another architecture
that is the vendor simulation model. Often there is an order of magnitude
difference in simulation speed. Compiling two architectures allows extremely
simple switching between the two, or even simultaneous access for different
simulations.
++++
>
>If the goal was to allow an architecture to have the same name as the
corresponding entity, a much more natural solution would have been to simply
make the architecture name optional:
>
>entity E is ...
>end;
>
>architecture of E is ...
>end;
>
>There is only one name, and it is shared by the entity and the architecture -
which together still constitute a single declarative region.
>
++++
This would appear to me to break the ability to have multiple architectures. If
that is true please do not do it. Removing the capability to use multiple
architectures for name scoping rules is a bad trade off in my opinion.
++++
>
>Regards,
>
>Erich
>
>
Received on Thu Apr 8 03:29:09 2004
This archive was generated by hypermail 2.1.8 : Thu Apr 08 2004 - 03:29:36 PDT