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

Hi Peter.

I've thought again about this. I think the
suggestion is equivalent to one of replacing
configurations (optionally, at least) with
assignments of architectures to entities.

Not assignment in the sense of replacement, but
in the sense of association.

Usually, binding is done by referencing the entity
in the architecture declaration, and/or by use of
a configuration spec.

Why not view the entity primarily as a pointer to
an architecture, but a pointer which happens to
have additional functionality?

So, an entity can be declared and instantiated,
just as can be a pointer which has not yet
been assigned:

entity Something_WithPorts is
   (port & generic decs A)
end entity

Where A represents, for example two 16-bit busses,
a clock, and control signals. As opposed to B, where
there are 32-bit busses or something else different.

Suppose I've instantiated Something_WithPorts
this way:

SomethingInst01: Something_WithPorts( port map A here )

Now suppose I have implemented an architecture,
Registered_ALU, which references two 16-bit busses,
a clock, and the same control signals as in A.

architecture Registered_ALU
  is (arithmetical stuff)
end Registered_ALU

NO "of Something_WithPorts" in the architecture dec!
A comment to that effect would be OK, though,
or maybe a default binding indication.

I can then bind Registered_ALU to Something_WithPorts
by an assignment like this:

SomethingInst01 <= Registered_ALU;

The result is not replacement of the VALUE of
"SomethingInst01", but rather a completion of
SomethingInst01 so that the declaration of that
instance now becomes the same as,

entity Something_WithPorts
    instance SomethingInst01 is
   (port & generic decs A)
   Architecture = Registered_ALU
end entity

An assignment likewise could be made to
the entity rather than to one of its instances:

Something_WithPorts <= Registered_ALU;

This would hold in the scope of the assignment.

The result would be equivalent to,

entity Something_WithPorts is
   (port & generic decs A)
   Architecture = Registered_ALU
end entity

Then,
Something02: Something_WithPorts (port map2 to A)
Something03: Something_WithPorts (port map3 to A)
  etc ...

It seems to me that with some such approach, there
would be no need for configurations
any more; and, modifying neither the entity declaration
nor the architecture seems necessary to effect a
reasonable binding. This seems as safe in a version
control sense as the current VHDL configuration
approach.

Also, it is unclear whether component declarations
would be useful any more, either, using the same
associative assignment rationale.

-- 
                          John
                      jwill@AstraGate.net
                      John Michael Williams
Peter Ashenden wrote:
> 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.
>>>>
>>>
>>>
>>>
>