Component Activation Against Entiation in VHDL

Question

I have experience with Verilog / SystemVerilog, but I'm new to VHDL, and I'm trying to figure out when I should use a component instance or an object instance. By means of a component, I mean an obsolete way to declare object components before creating them. On the other hand, an instance of an object that was entered using VHDL-93 allows you to declare an object directly without specifying a component. Related article

It seems to me that Entity Instantiation is always preferable if you do not have an architecture yet and you just want to define a black box.

This is a related question that I found, but it fully satisfies my doubts. Since for any object you can define both a general map and architecture:

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

What is the added flexibility of instantiating a component? What will be the simplest example showing something that cannot be done with creating an entity, but can be done with an instance of the component ?

Answer 1

I like to think that the component is like an IC socket. You can take this analogy further by comparing compilation (analysis) with the assembly of the circuit board and processing of the assimilation to put the chips in sockets. If you use IC sockets, you can assemble a circuit board even if you have not ordered chips yet; You can delay the installation of chips in the socket until the end. Similarly, if you use components: you can compile the project, even if the entities and architectures corresponding to the components do not yet exist; You can delay the binding until the end, until development.

So why can this be? Why don't they exist yet?

i) This is a big project. Not everyone has completed their block. But you can still easily compile the top level and run simulations on any bit of the design. You can do this by commenting / editing, but using components is simplified.

ii) You have created a specific IP address automatically. This gave you a behavioral model for modeling, but not a synthesized model - the idea is that you combine several automatically generated physical representations of IP in a stream. This is fine for modeling, but how can you compile your project for synthesis, if a little is missing - your generated IP?

iii) You are doing recursive instantiation: you are creating one block within yourself. With direct instantiation, you have an unbreakable situation with chicken and egg (the so-called circular dependence); with direct instantiation, you cannot create an instance of what remains to be compiled, but you cannot compile it because the object instance has not yet been compiled. A component instance can break this circular dependency.

iv) A component instance also allows you to instantiate different objects in one place in your design (under configuration control). @ user1155120 gives an example above: using a component instance (and configuration) allows you to create identical blocks with different subblocks.

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

Answer 2

VHDL was originally a hardware documentation language. Not a simulation or a synthesizer.

I agree that the component instance is painfully verbose, but it is more readable if the object is not declared in the same source file.

In addition, on really large projects. This allows you to separate the compilation of each object. Therefore, changing one object does not mean recompiling the entire project.

And makes it easy to switch with behavioral arches for modeling. That is: DRAM is just a bunch of ports in your fpga. Or you can download the drum model and make sure your code is working properly. You do not need to go back and change the instance every time you mimic something.

Answer 3

One of the things you can do with customization (which depends on creating the component instance) is the use of virtual components.

You can write a description of VHDL that depends on some idealized object (with the name x here) and map it to another 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; 

development and modeling of configuration gives:

When searching for TARG port signals.

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

The understandable complexity associated with configuration was contrasted with portability libraries such as LPM (Library of Parameterized Modules), which add another axis of complexity by using attributes and generics to standardize interface names and reduce the number of library primitives.

Behavioral synthesis is progressing to such an extent that both constructive design methods have fallen to the side.

FPGA vendor support for explicit configuration declarations has also historically lagged. You may notice that IEEE Std 1076.6-2004 (RTL Synthesis, now unchecked) required support for configuration declarations, and implicit configuration provides default binding instructions at design time.