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

John,

I'm afraid I don't fully understand your suggestion. Perhaps a more
elaborate example illustrating the features might be helpful.

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: owner-vhdl-200x-ft@eda.org 
> [mailto:owner-vhdl-200x-ft@eda.org] On Behalf Of John Michael Williams
> Sent: Wednesday, 22 December 2004 01:42
> To: vhdl-200x-ft@eda.org
> Subject: Re: [vhdl-200x-ft] FT27: optional architectures
> 
> 
> Hi All.
> 
> Has anyone considered some operation similar
> to instantiation to bind an architecture?
> 
> So, declaring an entity optionally might allow
> declaring its architecture or not:
> 
> entity xx is
> (generics, ports' names)
> architecture (name)
> end entity
> 
> With no architecture declared, the entity
> still could be instantiated (like a sw
> forward declaration), but only the entity
> functionality (passive procs, etc) would be
> available.  No architecture named = no
> architecture.
> 
> An architecture then could be instantiated
> in an instance of that entity, to provide arbitrary
> binding.  The architecture name could be
> declared anywhere now allowed.  Two architecture
> names in an entity instance would be illegal.
> The functionality of the architecture, as usual,
> would not depend on its name . . ..
> 
> What is the benefit of always separating
> entity and architecture?  If an entity
> always should be binded, then the binding
> optionally should be included in the entity.
> This would be very object-oriented.
> 
> This approach could be completely backward
> compatible with the current one.  I would
> consider obsoleting the present one, but
> that isn't my suggestion here.
> -- 
>                           John
>                       jwill@AstraGate.net
>                       John Michael Williams
> 
> Peter Ashenden wrote:
> > 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.
> >>
> > 
> > 
> > 
>