Basic comps

The following section describes all the basic components used in the design of the system. Such components are located in the src/common folder and due to their extensive use, we dedicate this section to their comprehension.

Memory Banks

Two components are mainly used as memory banks:

1. memory_bank_1r1w: 1 Read port and 1 Write port.
2. memory_bank_2r1w: 2 Read ports and 1 Write port.

They both are memory elements (often mapped into a BRAM in Vivado), the first provides a simple interface and it is highly parametrizable in size, number of element of each line, number of bits for element:

parameter SIZE          = 1024,
parameter ADDR_WIDTH    = $clog2( SIZE ),
parameter COL_WIDTH     = 8, 
parameter NB_COL        = 4,                

The reading interface is reported in the following snippet code, when the address is ready, and the enable is high, the SRAM produces on the output bus the requested data the next clock cycle.

input   logic                               read_enable,
input   logic   [ADDR_WIDTH         - 1:0]  read_address,
output  logic   [NB_COL*COL_WIDTH   - 1:0]  read_data

Similarly, the writing interface is reported below. When the data to store and the address are ready, and the enable is set, the SRAM stores the incoming data in the selected address.

input   logic   [NB_COL             - 1:0]  write_enable,
input   logic   [ADDR_WIDTH         - 1:0]  write_address,
input   logic   [NB_COL*COL_WIDTH   - 1:0]  write_data,

The writing interface has a selective write_enable signal, this is a bitmap of which elements of the line are affected by the current operation. In case of concurrent write and read on the address, the behaviour of the SRAM depends on the mode selected on its parameters:

parameter WRITE_FIRST   = "TRUE"

If "write_first" is enabled (true), the SRAM first stores the data in the memory then forwards the data just stored on the output signal. The other functionality mode is "read_first" (parameter WRITE_TRUE set to false), in this case, the module first fetch the old data from the memory and outputs it on the reading output signal, then stores into the memory the new data from the interface.

The second module memory_bank_2r1w provides a similar interface, although the memory_bank_2r1w has an extra reading port, obtained allocating two memory_bank_1r1w modules with their writing port connected together. In this way, each write operation is propagated to both elements, and the two memories are aligned in their content, thus the same reading operation performed on both fetches the same value.

FIFO

The sync_fifo module is extensively used in the design, it instantiates a parametrizable FIFO, the width and the size of such a FIFO are fully parametrizable, although the SIZE ought to be a power of 2:

parameter WIDTH                  = 64,
parameter SIZE                   = 4,

Two parameters are control-oriented and widely used in the architecture:

parameter ALMOST_FULL_THRESHOLD  = SIZE,
parameter ALMOST_EMPTY_THRESHOLD = 1

Those set when the FIFO should signal to the back-pressure logic when it is full or empty:

output logic               full,
output logic               almost_full,
output logic               empty,
output logic               almost_empty,

In the default instantiation, the FIFO signals that it is full when the number of elements stored is equal to SIZE, ALMOST_FULL_THRESHOLD changes this rule, allowing the FIFO to signal the full condition in advance. The same for the empty condition.

Enqueuing an element in the FIFO can be easily done using the enqueue interface:

input                      enqueue_en,
input        [WIDTH - 1:0] value_i,

When at least one element is pending in the FIFO, it is propagated on the value_o signal output and the empty signal is low. The dequeue_en signal pops the element from the FIFO:

input                      dequeue_en,
output       [WIDTH - 1:0] value_o

Finally, the flush_en input signal empties the FIFO. Often used in case of rollbacks:

input                      flush_en,   

Control Logic Support

The following three modules are widely used in control units, in the remainder of this section we describe their features:

1. idx_to_oh
2. oh_to_idx
3. rr_arbiter

The first to modules mainly act as converters, the idx_to_oh component converts a natural number to a one-hot bitmap, while the oh_to_idx module does the opposite task. These are useful in scheduling-related tasks. Their interface is combinatorial and really straight forward, hereafter reported for completeness.

The idx_to_oh component gets in input ad ID expressed as a natural number, then it outputs its one-hot version (e.g. 0101 -> 010000).

input        [INDEX_WIDTH - 1:0] index,
output logic [NUM_SIGNALS - 1:0] one_hot

Dually, the oh_to_idx component gets in input a one-hot number, then it outputs its plain version (e.g. 010000 -> 0101).

input        [NUM_SIGNALS - 1:0] one_hot,
output logic [INDEX_WIDTH - 1:0] index);

Finally, the rr_arbiter component, as the name suggests, is an arbiter whit a round-robin scheduling policy, units that want to access a shared resource assert their bit in the 'request' signal bitmap:

#(parameter NUM_REQUESTERS = 4)
(input                              clk,
input                               reset,
input[NUM_REQUESTERS - 1:0]         request,

The arbiter picks a unit and sets the appropriate bit in the one hot signal grant_oh:

output logic[NUM_REQUESTERS - 1:0]  grant_oh);

The update_lru signal indicates the granted unit has used the resource and should not receive access again until other requestors have had a turn:

input                               update_lru,