View source for RAMP Relation

RAMP is a collaborative research community that aims at using FPGAs to accelerate processor simulations. Most RAMP projects aim at multiprocessor acceleration.

This is a similar goal to SCOORE, a major difference is that RAMP does not have an emphasis on ASIC or synthesis but rather on the FPGA acceleration.

=== RTL Layers ===
RAMP common interface divides the RTL implementation in 3 blocks:

-'''Model RTL''': The RTL required to implement a CPU/Memory/... model. Equivalen to the synos/scoore directory.

-'''Unmodel RTL''': The RTL required to gather statistics or control the modeled architecture. It may not be necessary to execute instructions in the model architecture, but it is a requirement for researchers.

-'''Platform RTL''': Each model and unmodel RTL needs to be synthesized in a specific FPGA platform. The platform RTL is the RTL specific for each platform. 


The RAMP project aims at providing a common interface to avoid platform and unmodel RTL. SCOORE can benefit as it could potentially reuse both.


=== Unit / Channel ===

RAMP partitions the design into units and channels. Main characteristics:

-Units only communicate through channels
-Units wait until all the inputs (in channels) are ready before generating outputs (out channels)
-Channels have a fixed latency
-Channels are unidirectional
-Channels have an initialization
-A firing happens when a unit reads/consumes all the inputs and generates all the outputs.


The RAMP channels are similar to the SCOORE inter-block communication. In SCOORE:

-All the inputs are read every cycle. The unit or block is responsible to read. A key difference is that in SCOORE we can set a "busy" signal which means that the following cycle the sent packet would not be processed until the busy is deasserted. E.g: The channel control between Unit A and Unit B could be as follows (the values are available only after clock posedge):

 CLK           0 1 2 3 4   -   5 6 7 8 9 0   -  1 2 3 4 5 
 B_to_A busy   F F T T T       F F T F F F      F T T F F
 A_to_B DInst  A B C C C       D E F F G H      I J J J K
             busy > 2 cycles   busy 1 cycle     busy 2 cycles

The busy signal implies that the receiver is responsible to buffer the state. The receiver became busy and sets the busy signal, but
the signal is not visible until the following clock posedge. This implies that a new packet may get in the input channel and that the
receiver is responsible to buffer.

If the receiver is not capable to buffer it without a significant logic overhead. It is possible to use the "retry" signal. We avoid to use the retry signal as it is seen as passing the problem to the sender.

 CLK           0 1 2 3 4 5 6 7 8 9 0
 B_to_A retry  F F T T T F F T F F F
 A_to_B DInst  A B C C C D E F F G H


Busy saves a cycle in relation to retry but the main issue is "who is the responsible to buffer?".
Retry the sender has to buffer, for busy the receiver has to buffer.

-RAMP uses a "enable" signal to notify that the channel has data. We use a "valid" signal. E.g:

  typedef struct packed{
    BoolType                            valid; // equivalent to the RAMP enable
    BoolType                            fault;
    RIDType                             RID;
    OPType                              op;
    PRegType                            psrc1;
    PRegType                            psrc2;
    IMMType                             imm;
    PRegType                            pdest;
  }DInst_SEType;