Revision as of 08:30, 20 April 2019

This module is the L1 cache controller (CC) allocated in the nu+ core. There is a component that it filters all request to/from LDST: core interface (CI). Regards to this component, it can be possible to decouple a service speed of cache controller and a service speed of LDST units. In fact, the 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 receives a request from the LDST unit (all the event concerned to the memory: miss, flush, evict) and store it in one of four queues. Once elaboration of cache controller terminated, it sends a dequeue signal to core interface for delete request in queues.

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

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

Interface

This section shows the interface of the 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 is dequeue signal, depending 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.

Behaviour

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

• idle
• send request
• wait response

The FSM is implemented dividing sequential and combinatorial output.

TODO: disegno FSM

Memory swap

This portion of code is used 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 the format of data.

Requests managing

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

TODO: gestione istruzioni "speciali"

Snoop managing

TODO: chiedere meglio questa parte

Way counter

TODO: chiedere meglio questa parte