RE: [vhdl-200x-ft] FT27: optional architectures

Selon Peter Ashenden <peter@ashenden.com.au>:

> Tristan,
> > >
> > > > * One problem with optionnal architecture is that when an
> > > > architecture is obsoleted, you don't really know wether
> > you should
> > > > elaborate without architecture or fail to elaborate. The same
> > > > problem already exists with the package body.
> > >
> > > You use the reserved word "open" to indicate that no
> > architecture be
> > > included. Thus, if an architecture is obsoleted, you replace all
> > > references to it in binding indications with "open".
> > Ok, I was not clear enough.
> > Suppose you are using default bindings and default
> > configurations. Suppose the only architecture of an entity
> > (which is instantiated) is obsoleted. How your design will
> > elaborate: fails or without architecture for the instantiated entity.
>
> Thanks for clarifying the question. My suggested change to the default
> binding rules includes not binding any architecture if the is no
> architecture in the library. Under this scheme, the behavior when an
> architecture becomes obsolete depends on whether you leave the architecture
> in the library or not.
Unfortunatly, according to the LRM, you cannot remove a design unit from
a library. Therefore, once you have written an architecture, you cannot
forget it. Maybe the LRM have to be updated on this point.

> Presumably, the architecture becomes obsolete by virtue of changing the
> entity. Since the architecture depends on the entity, after the entity is
> re-analyzed, the architecture would have to be re-analyzed to be included in
> the design.
>
> If the change to the entity means the architecture is no longer needed, but
> the architecture is left in the library, elaboration would fail.
>
> Once the architecture is removed from the library, elaboration can proceed,
> and the default binding rule will cause the entity alone to be bound into
> the design.
No, an architecture may becom obsolete because of a package.
And here, default binding rules become really a trap:
* suppose you modify a package which was used only by architectures (maybe
 a common case).
* all architecture using this package become obsoleted.
* suppose your tool remove the obsoleted architecture from the library.
* you can elaborate an almost empty design without any error !

[...]
> > Furthermore, the label of a component
> > instantiation (C.I.) in an entity can be the same as a label
> > of a C.I. in an architecture. How do you address this issue ?
>
> In VHDL-2002, the block structure of design entities was changed, so that an
> architecture body was logically nested within an entity declaration. Under
> that scheme, a component instance in the architecture could have the same
> label as that of a component instance of the entity declaration, since the
> label of the inner instance (in the architecture body) would hide the label
> of the outer instance (in the entity).
>
> In VHDL-200x, however, it is proposed to revert to the previous block
> structure for design entities, namely, having the declarative region of an
> architecture body extend that of the corresponding entity declaration. In
> other words, the entity declarative region and the architecture declarative
> region would jointly form the declarative region of the design entity. In
> that case, you could not have the same label for a component instance in the
> entity and a component instance in the architecture, since they labels would
> be homographs in the same declarative region.
I was not aware of this revertion. I should read it.
Doing and undoing is always work... Anyway.

Note that the VHDL-2002 block structure had at least an advantage: you
couldn't declare a body in an architecture of a subprogram specified in the
entity. I really think this restriction should be kept.

[...]
> Thanks - I see what you mean now. That makes good sense. Rather than just
> relying on the default binding rule to bind in the most-recently analyzed
> architecture, you could defer the choice of architecture to a configuration
> declaration.
>
> I'd suggest you put in an enhancement request on the VASG web page at
> www.eda.org/vasg/. That way, we can track the proposal for the next
> revision.
Ok, I will do it.

Tristan.
Received on Wed Dec 22 00:43:13 2004