Difference between revisions of "SC Item"
(→HN_BOOT_COMMAND) |
|||
Line 24: | Line 24: | ||
The supported commands are: | 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: | '''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: | ||
Line 48: | Line 48: | ||
assign hi_thread_en = thread_en; | assign hi_thread_en = thread_en; | ||
− | + | ===Running threads=== | |
+ | '''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 logic hi_read_cr_valid, | ||
Line 59: | Line 60: | ||
and sends the response to the host through the item interface. | and sends the response to the host through the item interface. | ||
− | + | ===Reading Control Registers=== | |
+ | '''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 logic hi_write_cr_valid, | ||
Line 67: | Line 69: | ||
Thread ID and register ID are propagated through hi_read_cr_request signal, as in the HN_READ_STATUS_COMMAND case. | Thread ID and register ID are propagated through hi_read_cr_request signal, as in the HN_READ_STATUS_COMMAND case. | ||
− | + | ===Querying Logger=== | |
+ | '''HN_LOG_REQUEST''' item queries the system logger. |
Revision as of 17:27, 15 May 2019
The item interface provides communication between the system and the host. This module (named nuplus_item_interface) implements a control logic which interprets messages from the host and applies those requests on the nu+ 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_LOG_REQUEST = 10 } 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.
- HN_ENABLE_CORE_COMMAND: sets the active thread mask in the nu+ 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;
Running threads
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.
Reading Control Registers
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.
Querying Logger
HN_LOG_REQUEST item queries the system logger.