Architecture Generic

Proposal Details

  • Who Updates: LarsJensen
  • Date Proposed: 2013-02-15
  • Date Last Updated: 2013-02-15
  • Priority:
  • Complexity:
  • Focus:

Current Situation

Today, configuration is cumbersome of a component containing a replaceable part that makes the component usefull in many different applications.


Make VHDL support architecture generics.

Implementation details

The architecture of a component c1 residing in another component c2 should be able to be specified as a generic on component c2.

Code Examples

In library lib1:

entity e1 is
port (
    t1 : out std_logic);

In library lib2:

architecture a2 of lib1.e1 is
end architecture a2;

In library lib3:

entity e3 is
generic (
    architecture a of lib1.e1);
port (
    t3 : out std_logic);
end entity e3;

architecture a3 of e3 is
    entity_i: entity lib1.e1(a)
        port map (
            t1 => t3);

end architecture a3;

In library lib4:

entity e4 is
port (
    t4 : out std_logic);
end entity e4;

architecture a4 of e4 is
    entity_i: entity lib3.e3(a3)
        generic map (
            a => lib1.e1(lib2.a2));
        port map (
            t3 => t4);
end architecture a4;

Use Cases

Say, you have a global repository of standard components with a replacable part, you do not want to change the standard component every time someone wants to adapt it to a new type of application. If the architecture of the replacable part can be specified through a generic, the standard component do not have to have any knowledge of all the possible implementations.

An example could be a sorting engine of a generic type. The sorting engine could have several architectures implementing different sorting algorithms (bubble sort, quick sort, ...). The sorting algorithms require a compare function for every generic types. The compare function should be implemented as a component since some types require more than a simple function call (i.e. floating point, records, ...). Currently, there is good way to inject the compare component into the sorting engine. This could easily be done by extending the VHDL syntax with an architecture generic:

entity sorting_engine is

generic (

 architecture compare_architecture of compare_entity;

 type data_type;


port (

 clk : in std_logic;

 data_in : in data_type;

 sort_start : IN std_logic;

 data_out : out data_type;

 sort_done : out std_logic);

Arguments FOR

An architecture generic would make it possible to make a standard component containing a replaceable part that can be configured to many different application without changing any of the standard component code. The design pattern is known as object composition.

Arguments AGAINST

-- ErnstChristen - 2015-01-27

Superficially this appears similar to generic subprograms, but I question the ROI given that configuration declarations are available. Supporting this would likely be more complex than generic subprograms given that architectures are secondary design units, so the visibility aspects are quite different.

General Comments

-- DavidKoontz - 2013-02-16

You're trying to get something for free. To illustrate a fragment of a configuration declaration for an encryption design:

configuration behave_config of des is
    for behave
        for DSLICE0: dslice
            use entity work.dslice(behave); 
            for behave
                for S1: sbox
                    use entity work.sbox1(behave);
              end for;
                for S2: sbox
                    use entity work.sbox2(behave);
               end for;
          end for;
     end for;
-- other three quarters eliminated for brevity
end behave_config;

The verbosity involved in configuration declarations or block specifications compartmentalizes name space for behave. Granted you're limiting the depth to one level, instead of the two shown in the configuration. At the bottom level the configuration example still has two behave names. (There are actually eight, there are four dslices and eight sboxes).

In your scheme the identifier ( a ) would have to be unique across all architectures specified in that generic's scope or would have to be handled by overload resolution which would fail in this case for ambiguity.

It doesn't seem that you could get by with less than a configuration specification with a binding indication.

The distinction between a configuration declaration and a configuration specification as a block declarative item in an architecture declarative part or as a generic element isn't that much and can take advantage of configuration hierarchy for reducing immediate complexity. Notice the configuration only shows these dslices when there are other instantiated components not requiring configuration beyond last architecture analyzed.

You'd think configuration declarations would be a natural for an implementation to generate upon the first succesful elaboration. It could be modified and subsequently analyzed.

-- LarsJensen - 2013-02-18

I have thought about the ambiguity of the identifier ( a ), so instead of writing

generic map (
            a => lib2.a2);

You could write:

generic map (
            a => lib1.e1(lib2.a2));

I do not agree that the difference between a configuration declaration and a generic declaration of an architecture is small: If you use configuration declaration, you do not have the freedom to change the hierarchy or naming of your core component without breaking all the configuration declarations. To me that is a major disadvantage - The users of a core component should not need to know anything about the architecture of the core component, only the interface (the entity).


Add your signature here to indicate your support for the proposal

-- KevinJennings - 2013-04-05

-- PatrickLehmann - 2016-02-19

Topic revision: r10 - 2020-02-17 - 15:34:26 - JimLewis
Copyright © 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback