I am wondering what is the difference between component an entity. I would like to know in which cases is better to use components instead of entities. Thank you so much.
-
1Please, could anyone create a tag call 'vs'. Thank you. – Peterstone Jul 12 '11 at 06:48
-
7You mean "vs" like in the title? Hm, not a good idea, methinks. – stevenvh Jul 12 '11 at 07:21
-
2Not everyone here uses Visual Studio....oh wait...you meant the other "vs" right? ;-) – cbmeeks Jan 28 '16 at 19:06
4 Answers
Here's an analogy which helps some people (especially those from a physical electronics background):
A component
tells the compiler "there's going to be something with these sorts of pins on it called this at some point, but don't worry for now". It sort of defines a "socket". You can go on to describe what "wires up" to that "socket" etc.
An entity
is something specific with a name and a set of pins, which the compiler can then "plug in" to that "socket" (and hence be connected to the "wires").
Note that you don't need a component
you can do "direct instantiation" which means the compiler already knows about an entity so the "socket" doesn't need to be defined separately. In fact, that would be my recommended approach, as otherwise the component
is an extra level to be kept in sync.
You need to use components if you are mixing Verilog and VHDL and need to use a Verilog block within the VHDL. Then the component
is the socket and not until much later on can the compiler/elaborator plug the Verilog into the socket.

- 8,439
- 1
- 23
- 44
-
Component is like the DIP package. You could use the same 8-pin op-amp a dozen times in a circuit, and it's always 8 pins. They are separate components, even though they're the same type of op amp. Entity is like the pinout on the datasheet; all of the separate op-amps have the same pinout. – ajs410 Jul 12 '11 at 18:08
An entity is a real interface to a design unit which can have multiple architectures. An entity defines how stuff gets in and out, while the architecture defines how the design unit operates. So you could have multiple ways of implementing the same function, which would be described by the same entity.
A component is an ideal or "virtual" design unit. When you are doing a top down design (i.e. you are putting together top level before the lower level blocks are designed) you can use a component to describe the type of interface you are expecting for your design units. You can think of this as a place holder or black box for a future real implementation.
Using configurations you can bind a specific component instance to an entity definition. Here you can map out which port should connect to which port. This maps how the component that was defined in the ideal sense maps to the entity that was actually implemented.
In practice, I have found that components are typically unnecessary and create another level of abstraction that is typically not used. You can skip the use (and need) for components by directly instantiating the entity and referencing which architecture to use for that instance of the entity.
For example:
MyDesignUnit : entity library_name.entity_name(architecture_name)
port map(
...

- 368
- 2
- 13
-
An [example](https://blogs.plymouth.ac.uk/embedded-systems/fpga-and-vhdl/test-benches/part-2-multiple-architectures/) of how to implement an entity with multiple architectures. They use the implicit `work` library (so that would be your `library_name` in this case). – chick3n0x07CC Jun 05 '23 at 12:10
From [1] below:
There is an important distinction between an entity, a component, and a component instance in VHDL. The entity describes a design interface, the component describes the interface of an entity that will be used as an instance (or a sub-block), and the component instance is a distinct copy of the component that has been connected to other parts and signals. To compare these with the process of bread board design with off-the-self parts. The entity and architecture is like the data book describing the interface and schematics of how the part works. The component is like the short pin listing that comes with the part to describe how it should be connected. The component instance is the actual part itself, of which you may have many that each operate independently.
See [1] for context and more detail.
There are numerous VHDL tutorials on line eg [2][3] ... Book (84 page PDF) [4] Looks good [5] Mainly for links [6]
- [1] http://www.gmvhdl.com/connect.htm
- [2] http://www.seas.upenn.edu/~ese171/vhdl/vhdl_primer.html
- [3] http://www.gmvhdl.com/VHDL.html
- [4] http://lslwww.epfl.ch/pages/teaching/cours_lsl/sl_info/vhdl-tutorial.pdf
- [5] http://www.doulos.com/knowhow/vhdl_designers_guide/
- [6] http://instruct1.cit.cornell.edu/Courses/ee475/tutorial/VHDLTut.htm

- 147,325
- 18
- 210
- 386
-
1you seem to favor links in endnotes, but that's how it's done in print, and doesn't use hyperlinking like it's meant to be used. You could have written "See [this link](http://www.gmvhdl.com/connect.htm) for context and more detail". Much more user-friendly, AFAIC. Just a suggestion. – stevenvh Jul 12 '11 at 11:30
-
2Old brain :-). I lean towards maximum information (as you will have noticed :-)) and the endnote method allows readers to see where the link is from and whether some are on the same site - as sometimes happens. For very long links I'd tend towards using bit.ly / j.mp with a meaningful name. I've also seen users reticent about clicking on a link (even though these can be copied and pasted for checking (extra work)). BUT point noted and I'll consider each as options in future. – Russell McMahon Jul 12 '11 at 12:02
An entity is a design unit whose input-output ports are specified. Entity just defines the external ports while the internal functioning is specified by the corresponding architecture. A component is the complete design unit composing of both entity and architecture. The first step is the component declaration( specifying its name and ports) and then component instantiation ( port mapping).

- 1
- 1