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

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".

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

The current situation is this: A block configuration that occurs
immediately within a configuration declaration or immediately within a
component configuration configures the equivalent block corresponding to the
design entity. If the block configuration names an architecture, it
configures the design entity comprising the entity and the architecture.

What's new in the proposal is that, if the block configuration uses the
reserved word "open" instead of an architecture name, the design entity
consists of the entity declaration alone. The block configuration contains
configuration items for the contents of the entity declaration. That may
include component instances and nested blocks.

> * 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.

I'm sorry, I don't understand what it is that you're suggesting. Would you
care to elaborate?

Cheers,

PA

--
Dr. Peter J. Ashenden                        peter@ashenden.com.au
Ashenden Designs Pty. Ltd.                   www.ashenden.com.au
PO Box 640                                   Ph:  +61 8 8339 7532
Stirling, SA 5152                            Fax: +61 8 8339 2616
Australia                                    Mobile: +61 414 70 9106
> -----Original Message-----
> From: tgingold@free.fr [mailto:tgingold@free.fr] 
> Sent: Monday, 20 December 2004 23:42
> To: Peter Ashenden
> Cc: vhdl-200x-ft@eda.org
> Subject: 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.
>