Purpose to providing more than one architecture?

I'm in the process of learning VHDL and I'm trying just learning from examples, syntax guides, and experiments.

One thing I don't quite understand is why you'd ever want to provide more than one architecture. For instance, this example 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 <= "ZZ开发者_开发百科Z";
    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 it, or is it just for example sake?

Also, not sure if this belongs here or Electronics.SE, so figured I'd try here first.

While that particular example seems to be just for an example's sake, there are several reasons why you'd want different architectures for some designs.

One thing that is commonly done is to provide black box models of IP designs for performance reasons, when you are trying to simulate another (unrelated) part of the whole SoC design.

Or, you might have a higher level model of the IP that allows faster simulation times, as well as the model intended for synthesis. Higher level models are often used for processor cores, since simulating the entire core is usually not necessary when verifying the rest of the design.

Another possible reason is to selectively have different behavior in an IP design so that slightly different versions can be instantiated when the IP is integrated into a SoC design. For example, one architecture might be intended for one-clock-domain operation while another might have synchronization between two different clock domains.

As a real-world example, I have a generic arbiter module implemented with multiple architectures. I can instantiate the arbiter with the desired number of inputs, and select appropriate back-end logic for the task at hand. In some cases, I use a simple round-robin architecture that looks at one signal per clock (slow, but low gate-count). Other times, I need more complex features such as weighting by priority, or higher speed (ie: look at 4 or 8 signals per clock). These require more logic than the simple round-robin design, but may be required in some instances.

By having each different implementation as a separate architecture in the same module, it is easy to select the appropriate one for the task, or switch between them as required.

Architectures can be used by designers in different ways.

For me:

• An entity is associated with a particular functionality required.
• An architecture describes the implementation detail for that specific functionality. So if you you need to describe the same function in different ways (for any reason, many mentioned by others already), then you can have multiple architectures.

I shy away from using architectures to implement different functionalities which would require the same I/O. That is, when using an entity, I expect the entity to behave functionally in the same way regardless of which architecture that I choose (I say functionally because there could be timing differences perhaps if one architecture models placement on a chip, for example). The architecture choice is based more on what "target" you are choosing (simulation, synthesis, etc).