Week 11: Working with the Synthesis of the Verilog Code

Welcome back, everyone! Last week, I focused on synthesizing the Verilog code and generating a netlist that maps the logic elements/cells within FPGA, such as LUT (lookup table) and SLE (Sequential Logic Element or Flip Flop).

The synthesis tool, a crucial component in the Verilog code implementation process, takes the Verilog code (also known as the RTL code: Register Transfer Level code) for my path-finding algorithm as an input. It then produces the netlist, a digital circuit that connects various digital logic elements of an FPGA. In essence, the synthesis tool transforms the behavioral RTL code into a digital circuit that can be realized on an FPGA.

I set the target device as Microchip’s PolarFire FPGA. I provided a clock constraint as 100MHz. The synthesis tool first gave me the an error: that my code had portions of logic within the “always” block, where I used both non-blocking and blocking statements. I intended to create the sequential logic. So, I converted all the blocking statements within the clocked “always” block into non-blocking statements. Going further, the synthesis tool gave an error that the “visitmap” array was updated in two different always blocks. I knew those were nonoverlapping statements because I was only initializing the “visitmap” in one “always” block and updating it in another “always” block where the state machine was coded. However, to resolve the issue indicated by the synthesis tool, I removed the initialization code of the “visitmap” from one “always” block and moved it to another “always” block where the state machine was coded. After making all these changes, I could synthesize the code successfully.

The tool generated the netlist with 126 SLE (sequential logic elements or Flip Flops) and 564 LUTs (Lookup tables). Each lookup table implements four input combinational functions. FPGAs do not have combinational gates such as AND, OR, NOT, NAND, or NOR. Instead, all the combinational logic is implemented in the LUTs (Lookup tables).

The timing analysis engine within the synthesis tool reported that the design could run at 110.7 MHz, faster than my original constraint. Within the 6×6 grid map that I took, for example, purposes, the algorithm can find the optimal path in 36 clock cycles in the worst case scenario. With a 110 MHz clock, it will take only 327 ns to find the optimal path. This demonstrates the clear advantage of hardware implementation, which is more deterministic and reliable than software implementation that relies on the operating system and system resource usage.

From the start of this project, my aim was to demonstrate the speed and suitability of the hardware implementation of the path-finding algorithm for a robot’s real-time application. Now, this goal has been successfully achieved! Hope that my project was informative and interesting to engage with!