Thursday, August 28, 2025

FPGA critical aspects

 

FPGA

 

During the micro-architecture or detailed design phase FPGA resource requirements shall be estimated. Module designers shall have “detailed view” of the design down to function/majorcomponent level for near-accurate estimates. At the end of this phase, exact FPGA part to be used shall be finalized from the chosen family.

Following are critical aspects that need to be considered during this phase:

1.      FPGA device Architecture: Detailed investigation and understanding of FPGA device architecture/capabilities including logic cells, RAMs, multipliers, DLL/PLL and IOs

2.      Module boundaries: All modules interfaces shall be on register boundary.

3.      Internal bus structure: A well defined internal point-to-point bus structure is preferred than routing all signals back and forth.

4.      Clocks: Clock multiplexing and gating shall be avoided and if required shall be done based on device capabilities

5.      Resets: Number of resets in the system shall be optimized based on dedicated reset routingresources available

6.      Register file: Instead of creating one common register file and routing register values to all modules; it is better to have registers wherever they are used. If needed even registers may be duplicated. It should be noted that though write path may be of multi-cycle path, but read path may not be. Also registers shall be implemented in RAM wherever possible

7.      Selection of memories/multipliers: The memory size requirement shall decide whether to use hard-macros or to build with logic. For small size memories, it is not at all preferred to map to large memory hard-macros, though it might take additional logic resources. The primary reason for this is hard-macro memory locations are fixed and placing driving/receiving logic next to memories is not always possible. Similarly, it is not advantageous to map small multiplier (such as 3x3) to an 18x18 hard- macro multiplier.

8.      Data/Control path mixing: Often it is advantageous to store control signals along with data bits in memories and pass-on to other modules. For example let us consider 16 data bits and 2 control bits to be transferred from one module to another through memory. These 18 bits can be stored as data bits in available block-memory of size say 1kx18 block memories. Also this method will be further advantageous if the hand-shake is asynchronous.

9.      Big multiplexer structures: It is not preferred to build very big multiplexer structures (say 256:1) especially for timing critical paths. Instead smaller multiplexers can be built, which are more controllable.

10.  High-level Floorplan: A high-level floorplan including IO planning shall be worked-out (as shown in Figure 1) based on the gate count and other macro estimates. Also spare area shall be planned for future/field upgrades. At this stage it is not necessary to fix the IO locations but it is necessary to fix the IO banks in FPGA. Having done the high level floorplan; the budgeted area shall be known to module level designers. Also interface module floorplan locations shall be known to the module level designers, which will enable them to further floorplan allocated area if necessary. Some of the high level floorplanning considerations are:

a.       Controlling congestion along with proximity

b.      Draw the data flow diagram of the design with the memories that are used to terminate the data paths and do module level area allocation

c.       Interdependent modules should be closer

d.      Module level area allocated shall be close to Macros which it is interfacing to

e.       Free area (rows and columns) between module area allocations, which will aid in inter module routing in full chip

f.       Clock resources and routing limitations if any

11.  Module output replication: Based on the initial floorplan each module output might have to be replicated if modules receiving this data are located in different corners of the chip.

12.  Best practices: RTL coding guidelines shall be passed on to module level designers.

 


No comments: