Kestrel

I successfully put and tested a 4-PE single-cycle Kestrel on the FPGA, and it's working wonderfully!

kex02.kasm (PE counting)

kex04.kasm (#111)

Implemented 4-PE Utilization & Clocking

The following utilization is great news as it will allow us to fit 64 PEs on the Zedboard, being DSP-limited. The clocking is also excellent, since the original Kestrel board was clocked at 20MHz; however, this may change with the increased number of PEs.

Synthesized 64-PE Utilization (from 9/10)

Remaining Work

Verification with more complex programs (loops, nested loops, jump on wired or, controller registers, instruction interlocks)

An interface for the queues

Documentation

The design is finally working in simulation, with a small set of simple tests (outlined below). However, a lot more testing will be required to confirm the correct execution of the integrated system, especially past the simulation stage with regards to timing and overall correctness.

Tests performed

kex02.kasm accomplishments (9/20/2013)

✓ addxz with immediate ✓ add with registers and immediate ✓ program sequential flow  and 1 jump (start label) ✓ keep state once the program is concluded ✓ edge SSRs behave correctly ✓ final result in PEs is correct

kex04.kasm accomplishments (9/20/2013)

RF Using Xilinx BRAM IP

It turns out that the generated bram module with a width sufficient to support the 8x32 register file requires 4 36K bram primitives. We were counting on using an 1/8 of that amount! That really shrinks down the number of PEs we can put on the Zedboard.

RF Using Flip Flops

Fortunately, using FF, synthesis results show that the design is still DSP-limited, which means we can put up to 64 PEs on the Zedboard using this technique (!!! So much wasted time figuring out BRAM stuff). Unfortunately, this greatly increases the implementation time; I have not been able to completely implement (PAR, MAP, etc.) the design with 64 PEs yet, although synthesis is possible.

Synthesized 64-PE FF-SSRs Utilization

The systolic shared register banks must support reading from registers and writing the result of a computation during the same cycle. Unfortunately, this is impossible due to the nature of memories, which take at least one cycle to first produce data, and then to write it. Therefore, we must introduce two-phase clocking, as indicated by the Kestrel guide.

Two clock cycles

This option would be implemented with 2-phase clocking as explained in the Kestrel HW thesis. This would allow to continue using the BRAM as planned. However this will take a lot of editing of the current design as this detail was mistakenly ignored while implementing Kestrel on the Zedboard. The following are a few links that will be really useful in figuring out how to accomplish two-phase clocking on the FPGA.

About timing constraints

The PERIOD timing constraint

Fortunately, Xilinx also provides a clocking wizard through PlanAhead which may make this process more manageable.

The Xilinx Clocking Wizard

Verilog has a nifty block which makes the generation of PEs and SSRs very simple, the generate block. Using this statement alongside the NPES parameter, the array module can not only contain a large but also variable number of PE instances without having to hard-code all of them. Here's what the code looks like at the moment (sorry for the lack of formatting):

generate // Shared Systolic Registers for (i = 0; i < NSSR; i = i + 1) begin : SSRs ssr s ( .CLK (CLK), .RST_L (RST_L), .i_opA (i_opA[4:0]), .i_opC (i_opC[4:0]), .i_dest (i_dest), .nop (i_func == 5'b00101), .result_left (i == 0 ? dataFromControl : result[i-1]), .result_right (i == NPES ? dataFromControl : result[i]), .mask_left (i == 0 ? I_DATA_READ : mask[i-1]), .mask_right (i == NPES ? I_DATA_READ : mask[i]), .opA (opA[i]), .opC (opC[i]) ); end // Processing Elements for (i = 0; i < NPES; i = i + 1) begin : PEs pe p ( .CLK (CLK), .RST_L (RST_L), .instruction (instruction_fixed), .opAFromLeft (opA[i]), .opAFromRight (opA[i+1]), .opCFromLeft (opC[i]), .opCFromRight (opC[i+1]), .result (result[i]), .pe_wor (pe_wor[i]), .mask (mask[i]) ); end endgenerate

Program Counter takes 2 cycles to propagate, one to latch the instruction, and the second to latch the PC -- should only take 1

Program Counter

Loop Counter

Nomenclature to follow HW thesis

Some bugs

Upon inspecting the controller, it seems that most of the work to do to obtain a working Kestrel implementation will lie there. The following is an abbreviated list of TODOs to the current code base.

Implement input and output queues, as well as surrounding logic to correctly read from and write to them

Fix a few bugs, most of which are related to misnaming wires/registers and to the resulting misattribution of functionality

Ensure that all other functionality is correct

Fix the PEs/Controller interface: inputs to the PEs not currently implemented (e.g. scr, cbs)

The Code

I jotted up a quick and simple simulation to read the outputs of the array to make sure that the mistakes I saw on the board were not caused by the design, but by me. It looks to me like the PE is working just fine.

The Simulation Results

One PE Working … mostly.

I think the errors are due to how I wired things, especially since the CLK signal is wired to the down button (PlanAhead complained about that...), but I need to make sure of it. A simple simulator could confirm this.

I changed up the testing code from last week's attempt at proving PE functionality. Here are the visuals:

System Description

The DataPath module contains the PE and SSRs. It is fed every cycle by an InstructionIssuer which contains an Instruction Memory. The left and right outputs of the PE array are then fed to the OutputMemory. Either the left or right output is then displayed on the LEDs, based on the READ_L switch value.

System Schematic

Instruction Memory Contents

The program on the test architecture is a counter, which should wrap-around at 30.

nop addzz L0 add   L0, L0, #1 add   L0, L0, #1 ; ...

Results

Check out the next post for a video demo of the counter mostly working. :P