Overview

The objective for this week's project challenge was to bridge the gap between the high-level hardware design realized in Challenge #15 and its physical representation. In essence we are focusing on translating that HDL file's logic into a more concrete, synthesizable format which is suitable for ASIC or FPGA implementation as we move into practical, low-level design.

To this end OpenLane2 was used to determine the physical synthesis with an emphasis on learning how to utilize it to transform a Register Transfer Level (RTL) description to a more transistor-level layout or FPGA configuration.

Design for Open Lane

The design utilized for OpenLane is the synthesizeable "qr_hw_accelerators.v" as seen from Challenge 15, which is a composite module for the warp_image and correct_errors functions. The file config.json sets the clock period to 25 nanoseconds (ns) as a standard value to evaluate the maximum frequency and throughput of the design which is described in the Results section.

Results

Figure 1 below shows the physical design flow verifying that "qr_hw_accelerators.v" was routed successfully and reacted Stage 78 - Report Manufacturability, which indicates the flow successfully completed all required synthesis, floorplanning, placement, routing, and signoff stages. It shows that the design layout was validated and can be manufactured under standard PDK constraints and doesn't have any fatal design rule violations. There were however several warnings that were generated. Timing optimizations were done on default assumptions since no PNR_SDC_FILE & SIGNOFF_SDC_FILE was defined, there was a no global routing found for nets, and unsupported design rules for routing constraints, or threshold for long-wire reporting so there was no automatic detection for excessively long wires.

Figure 1: Flow result of OpenLane design.

Figure 2 below shows the GDSII layout of the design, in which it has a ~40µm x 40µm die area.

Figure 2: GDSII layout of OpenLane design.

Figure 3 shows the GDSII design in OpenRoad.

Figure 4: GDSII design shown in OpenRoad.

Figure 5 shows the clock timing in which it's used to calculate the maximum frequency and throughput of the design.

Figure 5: Timing Results of OpenLane design.

From Figure 5, the maximum operating frequency is calculated from the worst-case setup path delay which is the "timing__setup__ws" which is recorded to have 17.4749866539094 nanoseconds.

Thus the equation to calculate the frequency is: 1/17.474928665393094 * (10^-9) = 57.23 MHz as the maximum frequency.

In terms of the throughput of the equation would be: Throughput = (Number of Outputs per Operation / Clock Cycles per Operation) * Max Operating Frequency.

In the design, there are four operations, which are IDLE, LOAD, COMPUTE, DONE, in which each of these is one cycle, and the design runs an operation every 4 cycles. Thus 1 output byte is done per operation.

So given that the equation is: Throughput = (1 byte/4 cycles) * (57.2 * 10^6 cycles/sec) = 14.3 MB/s as the throughput.

Inquiries/Problems

Attached below are the various figures that are my inquiries to GPT-4o in order to help debug and understand how OpenLane works with my machine as OpenLane's tutorial didn't cover some of those. The one thing I took away from that is that unless I sent specified screenshots of my actual terminal or the errors, GPT would only give basic solutions.

Figure 6: First inquiry to GPT-4o to support OpenLane usage.

Figure 7: Second inquiry to GPT-4o to support OpenLane usage.

Figure 8: Third inquiry to GPT-4o to support OpenLane usage.

Figure 9: Fourth inquiry to GPT-4o to support OpenLane usage.