Component Instantiation vs Entity Instantiation in VHDL

June 2020 ยท 5 minute read

I have experience with Verilog/SystemVerilog but I am new to VHDL and I am trying to figure out when I should use component instantiation or entity instantiation. By component instantiation I mean the legacy way of declaring components of an entity before instantiating them. On the other hand, entity instantiation, which has been introduced with VHDL-93, allows you to declare an entity directly without specifying the component. Related Article

It seems to me that Entity Instantiation is always preferable unless you don't have an architecture implemented yet and you just want to define a black box.

This is a Related Question that I've found but it does fully address my doubts. Since it is possible to define both the generic map and the architecture for any entity:

entity work.MyEntity_E(ARCH) generic map( ...) port map( ... ); 

what is the additional flexibility of doing component instantiation? What would be the simplest example showing something that can not be done with entity instantiation but can be done with component instantiation?

3

3 Answers

I like to think of a component as being like an IC socket. You can take that analogy further by likening compilation (analysis) to assembling the PCB and likening elaboration to putting the chips in the sockets. If you use IC sockets, you can assemble the PCB even if you haven't ordered the chips yet; you can defer putting the chips in the socket till later. Likewise if you use components: you can compile the design if even if the entities and architectures corresponding to the components don't yet exist; you can defer binding till later, till elaboration.

So, why might that be? Why might they not yet exist?

i) It's a big project. Not every one has finished their block yet. But you can still easily compile the top-level and run simulations on either bits of the design. You could do this by commenting-out/editing, but using components makes it easier.

ii) You've generated some IP automatically. This has given you a behavioural model for simulation, but no synthesisable model - the idea is that you combine some auto-generated physical view of the IP later in the flow. This is OK for simulation, but how can you compile your design for synthesis if there's a bit missing - your generated IP?

iii) You're doing recursive instantiation: you're instantiating one block inside itself. With direct instantiation, you've got an unbreakable chicken-and-egg situation (aka a circular dependency); with direct instantiation, you cannot instantiate something that has yet to be compiled, yet you cannot compile it, because the instantiated entity has not yet been compiled. Component instantiation can break this circular dependency.

iv) Component instantiation also enables you to instantiate different entities in the same place in your design (under the control of a configuration). @user1155120 gives an example of that above: using component instantiation (and a configuration) enables you to create identical blocks with differing sub-blocks.

Here's an example comparing the two on EDA Playground - https://www.edaplayground.com/x/2QrS.

3

One of the things you can accomplish with configuration (which depends on component instantiation) is the use of virtual components.

You can write a VHDL description that depends on some idealized entity (named x here) and map it to different component with different port signal names:

entity a is port ( in1: in bit; in2: in bit; out1: out bit ); end entity; architecture fum of a is begin out1 <= in1 xor in2; end architecture; entity b is end entity; architecture foo of b is component x is port ( a: in bit; b: in bit; c: out bit ); end component; signal a, b, c: bit; begin TARG: x port map ( a => a, b => b, c => c ); STIMULI: process begin wait for 2 ns; a <= '1'; wait for 2 ns; b <= '1'; wait for 2 ns; a <= '0'; wait for 2 ns; b <= '0'; wait for 2 ns; a <= '1'; wait for 2 ns; wait; end process; end architecture; configuration fum of b is for foo for TARG: x use entity work.a port map ( in1 => a, in2 => b, out1 => c ); end for; end for; end configuration fum; 

elaborating and simulating the configuration gives:

fum.png

When looking a TARG's port signals.

This ability was intended to be used to map primitives from different vendor libraries to a standard component declaration.

The perceived complexity involved in configuration was countered with portability libraries such as LPM (Library of Parameterized Modules) which add a different axis of complexity via he use of attributes and generics while standardizing interface names and reducing the number of library primitives.

Behavioral synthesis has advance to the point both methods of structural design specification have fallen the way side.

FPGA vendor support for explicit configuration declarations has also historically lagged. You could note that IEEE Std 1076.6-2004 (RTL Synthesis, now withdrawn) required support for configuration declarations and implicit configuration provides default binding indications during elaboration.

1

VHDL was originally a hardware documentation language. Not a simulation nor a synthesising one.

I agree that component instantiation is painfully verbose, but it's more readable in case the entity is not declared on the same source file.

Also, on really big projects. It allows to separate the compilation of each entity. So changing one entity doesn't mean recompiling the whole project.

And allows to easily swap with behavioral archs for simulation. Ie: a DRAM will just be a bunch of ports of your fpga. Or you may download a dram model and verify that your code is working as expected. You don't need to go back and change the instantiation each time you simulate something.

6

ncG1vNJzZmirpJawrLvVnqmfpJ%2Bse6S7zGiorp2jqbawutJoam9qYm6Ad4SOnKamqJ%2Bjsq%2FAjKKlrKyRo8GqrdOipqdlpqh6prrToquyZZmjwLWtza2gmqyZpLtutc1mraGcnA%3D%3D