Inference vs Instantiation of components in an FPGA

When implementing components within an FPGA we have two main options which are inference and instantiation which we will discuss below.

Component Inference

Inferring a component refers to writing generic HDL for a desired resource such as a Shift Register Lookup table, SRL. With this approach the synthesis tool will attempt to deduce the intended resource based on the written HDL.

Shown below is an example of VHDL code used to infer an SRL with the schematic also shown to verify it was correctly inferred.

SRL16 Inference
Synthesized SRL Design

The main advantage of inference is code portability. In a project setting one can imagine a collection of many components written this way to promote both portability to easily handle multiple vendors as well as reusability by virtue of them being components.

The main disadvantage is that inference is not always possible, more complicated resources such as an Ethernet MAC block will not be inferable by the synthesis tool and must be created via instantiation.

Component Instantiation

Instantiating a component refers to using a predefined instantiation template provided by Vendor documentation or creation via a GUI wizard to implement the resource such as Block RAM.

We can use the GUI wizard for the RAM based shift register IP for example to instantiate an SRL16:

RAM-based Shift Register IP Wizard
SRL16 instantiation

Note in the above the std_logic_vector(0 downto 0) type being used for the D and Q ports which enforces either internal signals of this type to be used which then map to the external ports or needing to modify the ports at the entity level.

Synthesized SRL Design

In the above underneath all of the component hierarchy we can see the same synthesized design as the inferred design.

The main advantage of instantiating components is that you will get the exact variant of the resource you request.

This main disadvantage of instantiating components is that you are locked into working within the vendor defined interfaces which is not a portable approach.

Rule of Thumb

Use inference whenever possible and always check the synthesized design for correctness to maximize code portability to save yourself extra work down the track when needing to use a given resource with a different vendor. Only when inference cannot be used should the path of instantiation be taken.