Revision as of 17:41, 8 April 2019

This module is the L1 cache controller (CC) allocated in the nu+ core. It doesn't link directly to load/store (LDST) unit, but there is a component that it filter all request to/from LDST: core interface (CI). Regards to this component, it can be possible decouples a service speed of cache controller and service speed of LDST units. In fact cache controller can manage one request at a time but there are more than one LDST units so they can send more than one request at a time. Core interface receive a request from the LDST unit (all the event concerned to the memory: miss, flush, evict) and store it in one of four queue. Once elaboration of cache controller terminated, it sends a dequeue signal to core interface for delete request in a queues.

TODO: magari un disegno di tutti i componenti collegati al CC

In a single core architecture there isn't need of Miss Status Holding Register (MSHR) because TODO: chiedere perché (c'è un solo core quindi una sola richiesta)

Interface

This section shows the interface of cache controller to/from all other linked units.

To/from Core interface

Following lines of code define interface to/from core interface:

output logic                                       cc_dequeue_store_request,
~
input  logic                                       ci_store_request_valid,
input  thread_id_t                                 ci_store_request_thread_id,
input  dcache_address_t                            ci_store_request_address,
input  logic                                       ci_store_request_coherent,
~
input  logic                                       ci_flush_request_valid,
input  dcache_address_t                            ci_flush_request_address,
input  dcache_line_t                               ci_flush_request_cache_line,
input  dcache_store_mask_t                         ci_flush_request_dirty_mask,
input  logic                                       ci_flush_request_coherent,
~

In these lines of code there are dequeue signal, depend on kind of request, for load and store operation there are valid, thread ID, address and coherent signals, for flush, replacement and dinv (TODO: chiedere cos'è dinv). All these signals are described link alla pagina del core interface here. TODO: creare la pagina core interface?

To/from LDST

TODO

To/from IO Map

TODO

To/from Memory controller

TODO

To/from Instruction cache

TODO

To/from Thread controller

TODO

Implementation

In this section is described how to is implemented CC.

Main behaviour

The main behaviour is implemented by a finite state machine (FSM). There are tree state:

• idle
• send request
• wait response

Memory swap

This portion of code is use to transform a vector of data from xxx-endian into xxx-endian (TODO: chiedere a francesco cosa siamo noi e in cosa trasforma). For each vector of date there is a flag ENDSWAP: if it is asserted then is need to transform format of data. TODO: chiedere se mettere il codice

IO and instruction requests managing

Every requests are stored in a vector (TODO: chiedere se il segnale valid è un id della richiesta; TODO2: chiedere meglio questa parte). Regards to this vector, it can be possible schedule a request. There is a component (described [here]) that allow to round robin schedule.

TODO: gestione istruzioni "speciali"

Snoop managing

TODO: chiedere meglio questa parte

Way counter

TODO: chiedere meglio questa parte