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

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

> Folks,
>
> Proposal FT27 specifies that architecture bodies be optional for design
> entities, and that entities can include arbitrary block declarations and
> statements. However, the proposal does not say how to revise configuration
> declarations to take account of the changes to entities and architectures.
>
> Currently, a configuration declaration includes block configurations that
> name architecture bodies. Such a block configuration represents the
> external block denoted by a design entity, either one identified by the
> configuration declaration or one bound to a component instance.
>
> With the proposed change, an external block may be denoted by an entity
> alone. We need to provide a way of specifying in a binding indication that
> no architecture body be used (even if there is one available), and a way of
> specifying a block configuration for the denoted external block.
>
> My suggestion is to use the reserved word "open" in place of an architecture
> name. Thus, the syntax rule for block_specification in page 13 would be
> revised to:
>
> block_specification ::=
> architecture_name
> | open
> | block_statement_label
> | generate_statement_label [ ( index_specification ) ]
>
> Also, the syntax rule for entity_aspect on page 81 would be revised to:
>
> entity_aspect ::=
> entity entity_name [ ( architecture_identifier | open ) ]
> | configuration configuration_name
> | open
>
> I'd also suggest revising the default binding rules to specify that the
> architecture to use is the most recently analyzed, if one exists, or none
> otherwise; and that the rule specifying that it be an error if no
> architecture exists be deleted.
>
> Comments?
First (this may enlight my comments), I really don't like the concept of
optionnal architecture. This complexifies the LRM, add absolutly no
features and break the concept of external/internal views.

The comments:
* 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.

* The second problem is how do you configure the entity ? Since the entity
can have component instantiation, you should be able to configure them.

* Finally, as a proposal too, we should be able to configure the architecture
of a design entity instantiation. Currently, it is not possible to do that.

Tristan.
Received on Mon Dec 20 05:11:53 2004