Automatic Latency Equalizer For Pipelined Designs Implemented In VHDL

The pipelined architecture is often used in high speed FPGA cores. In complex designs data processing is often splitted into multiple paths performing some (maybe different) operations in parallel. In such a case it may be difficult to keep the same latency (measured in clock periods) in all paths.
GUI based tools (e.g. Xilinx System Generator or Altera DSP Builder) take care to equalize (balance) latencies (delays) of different paths. However it seems, that up to now there is no good solution for designers implementing their designs in HDL. This project offers a methodology, which allows to automatically balance latencies in different paths of pipelined core, so that data arriving to certain processing block, or appearing on the output are properly aligned in time.
As estimation of delay based on analysis of the source code may be difficult and error prone (if the author uses non-standard solutions), the method is based on simulation (the more detailed description of the method is available in two papers: Automatic latency equalization in VHDL-implemented complex pipelined systems and Automatic latency balancing in VHDL-implemented complex pipelined systems).
The similar method was used in the old "Xilinx Sync Block" available e.g. in the Xilinx System Generator for Simulink (see https://safe.nrao.edu/wiki/pub/CICADA/WebHome/xilinx_ref_guide.pdf , page 47). That block however analyzed only the moment when first valid data appeared on its inputs, while the method proposed in this project analyses the latency differences during the whole simulation period.
Data going through the IP core are labelled (in simulation only) with additional "time marker", which the user has to generate on the input. The directives "-- pragma translate_on" and "--pragma translate off" are used to limit generation and processing of those labels only to simulation.
Wherever the user wants to equalize latency in certain data paths, he/she places a special block (latency checker and equalizer - LCEQ or "lateq").
The equalized data paths are routed through the shift registers with length calculated from results of previous simulation (the initial length is equal to 0).
The block may work in two simulation modes and one synthesis mode.

1. In the standard simulation mode it reports the time markers of the data in different paths. This "delay report" is written to the file (the next version may use a C++ written function called via VHPI to analyze those reports without writing them to the file, or a dedicated program connected via named socket). The delay report file is then analyzed by another program "latreadgen.py", which generates a dedicated function returning the appropriate delay for each path in each equalizer block.
2. If the delays are already correctly selected, the user may set the parameter switching on the "final verification". In this mode the delay report is not generated, so the simulation is faster and no disk space is used for the report. In this mode any inconsistency of time markers on the output of the "lateq" block cause simulation error.
3. In the synthesis mode, all instructions related to time markers and their processing are switched off using the "-- pragma translate_off" and "-- pragma translate_on" directives. Therefore the system does not affect performance of the IP core.

,

1. The first version, located in the "single_type" subdirectory assumes, that all time aligned data in all data paths are of the same type. It allows to use the versatile latency checking and equalizing block implemented in a pure VHDL.
2. The second version, located in the "various_types" subdirectory assumes, that the datapath may use various number of data od different types.

,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,

HOW TO USE PROVIDED DEMOS

• Python3
• GHDL
• gtkwave

,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,