The goal of creating more than one architecture?

Question

I participate in learning VHDL and I try to just learn from examples, syntax guides and experiments.

One thing that I don't quite understand is why you ever wanted to provide more than one architecture. For example, this sample MUX code :

architecture behv1 of Mux is begin process(I3,I2,I1,I0,S) begin -- use case statement case S is when "00" => O <= I0; when "01" => O <= I1; when "10" => O <= I2; when "11" => O <= I3; when others => O <= "ZZZ"; end case; end process; end behv1; architecture behv2 of Mux is begin -- use when.. else statement O <= I0 when S="00" else I1 when S="01" else I2 when S="10" else I3 when S="11" else "ZZZ"; end behv2; 

Is there a purpose for this, or is it, for example, sake?

Also, not sure if it belongs here or Electronics.SE, so I decided to try again.

Answer 1

Although this specific example seems to be valid for example only, there are several reasons why you need different architectures for some projects.

One thing that is usually done is to provide IP design black box models for performance reasons when you try to simulate another (unrelated) part of the entire SoC project.

Or you may have a higher model of the IP level, which allows you to speed up the simulation time, as well as a model designed for synthesis. Higher-level models are often used for processor cores, since simulation of the entire core is usually not required when checking the rest of the design.

Another possible reason is selective behavior in the design of IP, so that several unique versions can be created when IP is integrated into the SoC project. For example, one architecture may be designed to work with one clock domain, while the other may have synchronization between two different clock domains.

Answer 2

As a real-life example, I have a universal arbiter module implemented with several architectures. I can create an arbitrator instance with the required number of inputs and select the appropriate internal logic for the task. In some cases, I use a simple circular architecture that considers one signal per cycle (slow but low gate counter). In other cases, I need more complex functions, such as priority weighting or higher speed (i.e., viewing 4 or 8 signals per cycle). They require more logic than a simple circular motion design, but may be required in some cases.

Having each separate implementation as a separate architecture in the same module, it is easy to choose the right one for the task or switch between them as needed.

Answer 3

Architectures can be used by designers in different ways.

For me:

• An entity is associated with a particular functionality.
• The architecture describes implementation details for this particular function. Therefore, if you need to describe the same function in different ways (for some reason many of them are already mentioned by others), then you can have several architectures.

I shy away from using architectures to implement various functions that will require the same I / O. That is, when using an entity, I expect that the entity will behave functionally the same regardless of the architecture that I choose (I say functionally, because there may be temporary differences, perhaps if one architecture models placement on a chip, for example). The choice of architecture is based more on which "target" you choose (simulation, synthesis, etc.).