Overview

This phase of the project moves into the hardware design portion after identifying the hardware/software boundary analysis and toy example implementation seen here(insert link to Challenge #12). The primary objective for this section is to create and simulate a functional hardware description of one or more of the components identified for acceleration for the QR code analyzer. In which this will serve as an initial step towards a more synthesizable RTL design to bring the pipeline closer to a chiplet based on FPGA's.

The suggested learning goals provided by Prof. Teuscher are to develop a familiarity with hardware description languages (HDLs) such as Verilog, SystemVerilog, or VHDL to develop the module and testbench(es) to verify their behavior through simulation.

Verilog Design

Below describes the hardware module and the testbench in regards to the HW/SW boundary which was the warp_image() and correct_errors() function of the algorithm.

Hardware Module

The file "qr_hw_accelerators.v" contains the RTL implementation of warp_image and correct_errors. Originally these were developed via PyRTL and tested with a Toy Example(insert link to challenge 12).

The first module (warp_image) represents the image warping logic that is responsible for rectifying QR code grids into canonical square form utilizing a homography transformation. In the accelerator design, this transformation is abstracted into a direct passthrough for validation, with an open-ended design to account for more advanced calculations via homography in the future when moving into additional iteration of the designs.

The I/O ports of warp_image are:

• input[7:0] ix: The X-coordinate of the input pixel (8-bit)
• input[7:0] iy: The Y-coordinate of the input pixel (8-bit)
• input[7:0] pix_in: The pixel value from the distorted image
• output [7:0] pix_out: Output pixel to the corrected grid -- this is currently set as a passthrough.

The logic in warp_image module is that the pixel data is forwarded directly to the output without transformation. In which this version will validate signal flow and the interface structure. In future iterations (adding the other address modes and additional elements missing from IB.py from the original source code), this may use a perspective transformation matrix in order to find the remapped coordinates and apply interpolation.

The second module (correct_errors) is a basic Reed-Solomon error correction setup, which is capable of using a 8-bit codeword and applying a mockup of correction logic. It is still set as a functional passthrough that will put the input codeword into a register and re-emits it. However it needs in future iterations to include syndrome evaluation, error locator polynomial generation, and chien search.

The I/O ports of correct_errors are:

• input [7:0] cw_in: Incoming QR codeword
• input valid_in: This is a data-valid signal for synchronous codeword input
• output [7:0] cw_out: The output codeword
• output valid_out: This is a data-valid flag for the output.

In which in the module reg_cw is used to store the input word when valid_in is asserted. Thus on the next clock cycle this value is then sent to the output.

Testbench

The file "qr_hw_accelerators_tb.v" is the testbench for the two modules in "qr_hw_accelerators.v". The objective for this testbench was to simulate a simplified runtime environment in which a known input pattern is applied to both modules and the outputs responses are observed over a series of clock cycles. It's focused on validating signal connectivity, register behavior, and passthrough logic correctness.

The testbench first defines all the necessary signals, which includes the 8-bit data lines and single-bit control flags, and instantiates the two modules. The inputs are then fed into the design synchronously utilizing a controlled clock.

The simulation loop then drives sequential values into both modules in which the warp_image module receives a pixel intensity value that cycles through a series of 8-bit test values. The correct_errors module receives the test codewords under a constant valid_in = 1 condition, which allows the passthrough register to latch new values on every clock edge. The outputted codewords are then displayed after the simulation has ended.

Results

Figure 1 below shows the output of the verilog module when the testbench is executed.

Figure 1: Output of qr_hw_accelerators.v with qr_hw_accelerators_tb.v

Upon execution of the testbench, both modules were successfully instantiated and the computed warp coordinates (x: 2560 y: 5120) are consistent with expected values thus confirming their operation. And following that all seven codewords were outputted correctly.

LLM Inquiries & Problems

Attached in the Challenge #15 folder is a subfolder called "Inquiries" which show the results that GPT-4o gave on certain prompts. One of the main issues with utilizing the LLM to support Verilog development was that it took several prompts to get it to where I wanted it to give me an output, which was mainly debugging as it only did several small iterations. As well as a prompt or two to fix the syntax errors.

Figure 2: First inquiry to Chat GPT-4o on the Verilog. See C15-Result1.v

Figure 3: Second inquiry to Chat GPT-4o to develop a testbench. The specified testbench is in the Challenge #15 folder.

Figure 4: Third inquiry to Chat GPT-4o. Beginning the debug phase.

Figure 5: Fourth inquiry to Chat GPT-4o.

Figure 6: Fifth inquiry to Chat GPT-4o with result.

Figure 7: Sixth inquiry to Chat GPT-4o.

Figure 8: Seventh inquiry to Chat GPT-4o.

Figure 9: Eighth inquiry to Chat GPT-4o with result.

Figure 10: Ninth inquiry to Chat GPT-4o with result.

Figure 11: Tenth inquiry to Chat GPT-4o.

Figure 12: Eleventh inquiry to Chat GPT-4o.