VHDL component versus entity

[biosbob]

still learning VHDL, but i've definitely discovered some redunancy between the component specifications found neorv32_package.vhd and the entity specifications within individual units containing a corresponding implementation....

some people suggest that component really is redundant in many cases, being one more set of sources that need to remain consistent.... in lieu of component, instantiations can instead reference a specific implementation instead as (say) entity neorv32.neorv32_boot_rom....

at the same time, it has been mentioned that component is definitely needed when mixing VHDL and verilog, so the former has a "black-box" interface to the latter....

question: is this redundancy between component and entity really necessary??? can we just have entity specs???? or maybe there is a way to have an architecture implement a 'component' spec????

[stnolting]

I am no expert when it comes to the syntactic rules of VHDL (I just accept them the way they are 😅). The VHDL gitter channel might be the right place to get more (helpful) information: https://app.gitter.im/#/room/#vhdl_General:gitter.im

[biosbob]

the general consensus in the world is to prefer entity over component, due to this redundancy; component should only be used in certain advanced cases (such as when mixing VHDL+Verilog or importing some "black-box" IP)....

i've discovered (at least with the GHDL compiler) that the ORDER of the source files matters.... by (redundantly!!!) declaring component interfaces in neorv32_package.vhd, we can simply list the core source files alphabetically.... this "works" because neorv32_package.vhd has a component declaration that matches some entity declaration (where the latter is being instantiated); and neorv32_package.vhd is seen before any of the neorv32_<entity>.vhd sources....

were we to simply list the source files in a "bottom-up" order (beginning with neorv32_fifo.vhd and ending with neorv32_cpu.vhd and neorv32_top.vhd, we can remove the component declarations altogether.... instantiating a module would now read as follows:

    neorv32_cpu_inst:  entity neorv32.neorv32_cpu ...

as i'm starting to play with some modifications in module interfaces, my own branch has taken this approach.... unless there is a "circular" reference between modules (which is a BAD design, IMHO), this approach will always work.... if the modules are NOT ordered bottom-up, compiler errors about "undefined entities" will help you get things in order 😉

[umarcor]

@biosbob as you concluded, components are mostly to be used for black-boxes or for configurations. Otherwise, direct entity instantiation is less verbose. Direct instantiation was introduced in VHDL 1993, so it did not exist "since the beginning" (the first revision of the language was in 1987).

See:

• https://insights.sigasi.com/tech/four-and-half-ways-write-vhdl-instantiations/
• https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/104
• https://gitlab.com/IEEE-P1076/VHDL-Issues/-/issues/292

[stnolting]

https://insights.sigasi.com/tech/four-and-half-ways-write-vhdl-instantiations/

Thanks for the excellent resources! 👍

I think there is no reason why we should stick to old-school component instantiation. Therefore, we'll switch to entity instantiation in #637.