Difference between revisions of "SC Logger"

Revision as of 14:32, 25 June 2019

The NaplesPU single core system provides a logging system. The module npu_core_logger logs the last transactions to the main memory, logging all the memory request issued by the core and all the memory responses from the main memory.

This module gets in input signal from the memory interface:

// From the Memory
input                                       mc_valid_i,
input                  [ADDR_WIDTH - 1 : 0] mc_address_i,
input                  [DATA_WIDTH - 1 : 0] mc_block_i,

When mc_valid_i is hight, the logger stores in a dedicated SRAM (named u_mem_log) the current memory transaction information, namely memory address and fetched data.

Dually, the logger also gets in input all the core signals related to memory requests:

// From the Core
input                                       core_write_i,
input                                       core_read_i,
input                  [ADDR_WIDTH - 1 : 0] core_address_i,
input                  [DATA_WIDTH - 1 : 0] core_block_i,

In the same way the logger stores in a dedicated SRAM (named u_core_log) the current memory request issued by the core. Along with memory address and data, in the SRAM is also stored the type of operation to perform on memory (read or write).

The logger provides a snooping interface connected on the item interface, allowing the host to fetch those information at run-time:

// Snoop Request
input                                       snoop_valid_i,
input  log_snoop_req_t                      snoop_request_i,
input                  [ADDR_WIDTH - 1 : 0] snoop_addr_i,

The snoop_request_i signal embeds the kind of request the host issued to the logger, those are defined in the npu_system_defines.sv file and they are organized as an enum type as shown below:

typedef enum logic [`LOG_SNOOP_COMMANDS_WIDTH - 1 : 0]{
	SNOOP_CORE = 0,
	SNOOP_MEM  = 1,
	GET_CORE_EVENTS = 2,
	GET_MEM_EVENTS  = 3,
	GET_EVENT_COUNTER  = 4
} log_snoop_req_enum_t;

In details:

1. SNOOP_CORE: query the core SRAM and fetch the i-th core transaction. The number of the transaction is specified in the snoop_addr_i signal.
2. SNOOP_MEM: query the core SRAM and fetch the i-th memory transaction. The number of the transaction is specified in the snoop_addr_i signal.
3. GET_CORE_EVENTS: get the number of core transactions recorded.
4. GET_MEM_EVENTS: get the number of memory responses recorded.
5. GET_EVENT_COUNTER: get the total number of transactions (core + memory transactions).

Those counters help the user to have an idea of which is the last recorded transaction. The control logic of this unit overwrites old transactions if the SRAMs are full. The control logic uses SRAMs in a circular way. If the last memory location has been used, a new incoming transaction will be stored in the first position overwriting the old value.

A snooping request from the host is forwarded on the following output interface:

// Log Output
output logic                                cl_valid_o,
output logic           [ADDR_WIDTH - 1 : 0] cl_req_addr_o,
output logic           [DATA_WIDTH - 1 : 0] cl_req_data_o,
output logic           [ADDR_WIDTH - 1 : 0] cl_req_id_o,
output logic                                cl_req_is_write_o,
output logic                                cl_req_is_read_o

Those signals are actually unconnected and used for debugging purposes in simulation.