Difference between revisions of "SC Item"

Latest revision as of 14:31, 25 June 2019

The item interface provides communication between the system and the host. This module (named npu_item_interface) implements a control logic which interprets messages from the host and applies those requests on the NPU core through a specific interface. Messages are organized in items (32 bits in the default version) when item_valid_i is high the item_data_i bus is evaluated by the control FSM. Often, a command requires more than one item, the FSM starts waiting for a command, hence the first item is the command from the host. Some commands require additional information, such as thread ID, in such cases, the FSM waits for a number of items equal of the number of additional information required to fulfil the host command.

Some commands send back a response to the host, such as reading internal registers, when required the response is forwarded to the host through:

output                 [ITEM_w - 1 : 0]           item_data_o,       
output                                            item_valid_o,

The item interface provides a standard on/off back-pressure control logic:

output                                            item_avail_o,       
input                                             item_avail_i   

The supported messages are defined in the module:

typedef enum logic [HOST_COMMAND_WIDTH - 1 : 0] {
  HN_BOOT_COMMAND         = 0, 
  HN_BOOT_ACK             = 1, 
  HN_ENABLE_CORE_COMMAND  = 2, 
  HN_ENABLE_CORE_ACK      = 3, 
  HN_READ_STATUS_COMMAND  = 8, 
  HN_WRITE_STATUS_COMMAND = 9
} hn_messages_t;

The supported commands are:

Setting PCs

HN_BOOT_COMMAND item sets the PC of a given thread, the next item defines the ID of the thread, while the last item sets the PC value. The control logic gathers that information and sets the PC using a specific interface to the core:

output logic                                      hi_job_valid,
output address_t                                  hi_job_pc,
output thread_id_t                                hi_job_thread_id,

When all the required items are ready, the FSM sets the hi_job_valid bit for a clock cycle and forwards PC and thread ID respectively on hi_job_pc and hi_job_thread_id.

Running threads

HN_ENABLE_CORE_COMMAND item sets the active thread mask in the NPU core. The value from the host is organized as a bitmask, if the i-th is high the i-th is active and it starts running. The bitmask is stored in a dedicated register:

always_ff @ ( posedge clk, posedge reset )
   if ( reset ) begin
      thread_en      <= {`THREAD_NUMB{1'b0}};
   end else begin
      if ( update_thread_en )
         thread_en      <= item_data_i[`THREAD_NUMB - 1 : 0];
end

and combinatorially propagated to the core:

output                 [`THREAD_NUMB - 1 : 0]     hi_thread_en,
assign hi_thread_en        = thread_en;

Control Registers

HN_READ_STATUS_COMMAND item fetches a special purpose register from the core, such as performance counters and PCs. Some registers are shared others are private among threads, e.g. PCs. The control logic waits for two data from the host, which are both in the next item from the host. The low half of the data defines the register ID, while the remaining part stores the thread id. The request is composed and sent to the core:

output logic                                      hi_read_cr_valid,
output register_t                                 hi_read_cr_request,

Then, the FSM waits for a clock cycle, fetches the output from the core:

input  register_t                                 cr_response,

and sends the response to the host through the item interface.

HN_WRITE_STATUS_COMMAND item writes a special purpose register of the core. The control logic waits for the register ID, thread ID, and the data. Then, the request is composed and issued to a special purpose interface:

output logic                                      hi_write_cr_valid,
output register_t                                 hi_write_cr_data,
output register_t                                 hi_read_cr_request,

Thread ID and register ID are propagated through hi_read_cr_request signal, as in the HN_READ_STATUS_COMMAND case.