diff options
| -rw-r--r-- | algorithm.tex | 8 |
1 files changed, 5 insertions, 3 deletions
diff --git a/algorithm.tex b/algorithm.tex index f0c8ca2..7ceb0fa 100644 --- a/algorithm.tex +++ b/algorithm.tex @@ -93,11 +93,13 @@ module main(reset, clk, finish, return_val); input [0:0] clk, reset; output reg [31:0] return_val = 0; output reg [0:0] finish = 0; reg [31:0] state = 0, d_out = 0, d_in = 0, reg_1 = 0, addr = 0, reg_2 = 0; reg [0:0] en = 0, wr_en = 0, u_en = 0; reg [31:0] stack [0:0]; + // RAM template always @(negedge clk) if ({u_en != en}) begin if (wr_en) stack[addr] <= d_in; else d_out <= stack[addr]; en <= u_en; end + // Data-path always @(posedge clk) case (state) 32'd6: reg_1 <= d_out; @@ -107,6 +109,7 @@ module main(reset, clk, finish, return_val); 32'd1: begin finish <= 32'd1; return_val <= reg_1; end default:; endcase + // Control-logic always @(posedge clk) if ({reset == 32'd1}) state <= 32'd4; else case (state) @@ -119,7 +122,7 @@ module main(reset, clk, finish, return_val); endcase endmodule \end{minted} -\caption{Verilog produced by \vericert{}. It demonstrates the instantiation of the RAM in the first always-block, the data-path in the second always-block and finally the control-logic in the last always-block.}\label{fig:accumulator_v} +\caption{Verilog produced by \vericert{}. It demonstrates the instantiation of the RAM, the data-path and finally the control-logic.}\label{fig:accumulator_v} \end{subfigure} \caption{Translating a simple program from C to Verilog.}\label{fig:accumulator_c_rtl} \end{figure} @@ -247,13 +250,12 @@ Typically, HLS-generated hardware consists of a sea of registers and RAM memorie This memory view is very different to the C memory model, so we perform the following translation. Variables that do not have their address taken are kept in registers, which correspond to the registers in 3AC. All address-taken variables, arrays, and structs are kept in RAM. -The stack of the main function becomes an unpacked array of 32-bit integers, which is translated to a RAM when the hardware description is passed through a synthesis tool. We generate a well-formed RAM template to ensure that a RAM is present in the final hardware, performing reads and writes using the signals that the RAM template exposes. +The stack of the main function becomes an unpacked array of 32-bit integers, which is translated to a RAM when the hardware description is passed through a synthesis tool. \vericert{} generates a well-formed RAM template in Verilog to ensure that a RAM is present in the final hardware, performing reads and writes using the signals that the RAM template exposes, instead of directly modifying the memory. Finally, global variables are not translated in \vericert{} at the moment. A high-level overview of the architecture can be seen in Figure~\ref{fig:accumulator_diagram}. \paragraph{Translating instructions} -\YH{TODO: Need to update text} Each 3AC instruction either corresponds to a hardware construct, or does not have to be handled by the translation, such as function calls (because of inlining). For example, state 15 in Figure~\ref{fig:accumulator_rtl} shows a 32-bit register \texttt{x8} being initialised to 1, after which the control flow moves to state 14. This initialisation is also encoded in HTL at state 15 in both the control- and data-path always-blocks, as shown in Figure~\ref{fig:accumulator_v}. Simple operator instructions are translated in a similar way. For example, in state 5, the value of the array element is added to the current sum value, which is simply translated to an addition of the equivalent registers in the HTL code. |