Changes between Version 3 and Version 4 of Writing Rules/RISC


Ignore:
Timestamp:
Jan 7, 2008, 1:57:02 PM (16 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • Writing Rules/RISC

    v3 v4  
    9898The '''r_pc''' et '''r_npc''' registers contain respectively the current instruction address, and the next instruction address. The wrapper can obtain the PC content using the '''getInstructionRequest()''' function, fetch the instruction in the cache (or in memory in case of MISS), and  propagate the requested intruction to the ISS using the '''setInstruction()''' function. The wrapper starts the instruction execution using the '''step()''' function. The general registers '''r_gp''', as well as the '''r_mem''' registers defining the possible data  access,  are modified. If, at the end of cycle (i) the '''r-mem''' registers contain a valid data access, this access will be performed during the next cycle, in parallel with the execution of instruction (i+1).
    9999
    100 
    101100From an implementation point of view, a specific ISS is implemented by a class '''processorIss'''. This class inherits the class '''genericIss''', that defines the characteristics common to all ISS, including the prototypes of the access function presented in section B, that are defined as virtual functions.
    102101
    103102= D) Generic cache controler =
    104103
    105 The hardware component ‘’’VciXcache’’’ is a generic cache controler, that can be used by various processor cores. It contains two separated instruction and data caches, but has a single VCI port to acces the VCI interconnect. The cache line width, and the cache size are defined as independant parameters for the data cache and the instruction cache.  On the processor side, the cache controler can receive two requests at each cycle : one instruction request (read only), and one data request (read or write). Those requests, and the corresponding responses are transmited through a normalised interface described below.
     104The hardware component '''!VciXcache''' is a generic cache controler, that can be used by various processor cores. It contains two separated instruction and data caches, but has a single VCI port to acces the VCI interconnect. The cache line width, and the cache size are defined as independant parameters for the data cache and the instruction cache.  On the processor side, the cache controler can receive two requests at each cycle : one instruction request (read only), and one data request (read or write). Those requests, and the corresponding responses are transmited through a normalised interface described below.
    106105Both instruction and data caches are blocking : the processor is supposed to be frozen in case of MISS (uncached read acces are handled as MISS). Both caches are direct mapping, and the write policy for the data cache is WRITE-THROUGH. The cache controler contains a write buffer supporting up to 8 fposted write requests. In case of successive write requests to contiguous addresses, the cache controler will build a single VCI burst. Therefore, the procesor can be blocked in case of MISS on a read request, but is generally not blocked in case of write request.
    107 Finally, in order to garanty a strong ordering memory consistency, the ‘’’VciXcache’’’ controler sequencialize the memory accesses, strictly respecting the access ordering defined by the processor on the ‘’’VciXcache’’’ interface. As the VCI interconnect does not garanty the in order delivery property, the cache controler waits the VCI response packet corresponding to transaction (n) before sending the VCI command packet corresponding to transaction (n+1).
    108 
    109 To communicate with the processor, the CABA model of the ‘’’VciXcache’’’ component contains two ports  defined below :
    110 
     106Finally, in order to garanty a strong ordering memory consistency, the ‘’’VciXcache’’’ controler sequencialize the memory accesses, strictly respecting the access ordering defined by the processor on the '''!VciXcache''' interface. As the VCI interconnect does not garanty the in order delivery property, the cache controler waits the VCI response packet corresponding to transaction (n) before sending the VCI command packet corresponding to transaction (n+1).
     107
     108To communicate with the processor, the CABA model of the '''VciXcache''' component contains two ports  defined below :
     109{{{
    111110class IcacheCachePort {
    112 sc_in<bool>  req;  // valid request
    113 sc_in<sc_dt::sc_uint<2>  >  type ;  // instruction access type
    114 sc_in<sc_dt::sc_uint<2> > mode;  // processor mode 
    115 sc_in<sc_dt::sc_uint<32> >  adr;  // instruction address
    116 sc_out<bool>  frz ;  // frozen processor
    117 sc_out<sc_dt::sc_uint<32> >  ins;  // instruction
    118 sc_out<bool>  berr;  //  bus error
     111    sc_in<bool>  req;  // valid request
     112    sc_in<sc_dt::sc_uint<2>  >  type ;  // instruction access type
     113    sc_in<sc_dt::sc_uint<2> > mode;  // processor mode 
     114    sc_in<sc_dt::sc_uint<32> >  adr;  // instruction address
     115    sc_out<bool>  frz ;  // frozen processor
     116    sc_out<sc_dt::sc_uint<32> >  ins;  // instruction
     117    sc_out<bool>  berr;  //  bus error
    119118}
    120119
    121120class DcacheCachePort {
    122 sc_in<bool>  req;  // valid request
    123 sc_in<sc_dt::sc_uint<4>  >  type ;  // data access type
    124 sc_in<sc_dt::sc_uint<2> > mode;  // processor mode 
    125 
    126 sc_in<sc_dt::sc_uint<32> >  wdata;  // data to be written
    127 sc_in<sc_dt::sc_uint<32> >  adr;  // data address
    128 sc_out<bool>  frz ;  // frozen processor
    129 sc_out<sc_dt::sc_uint<32> >  rdata;  // read data
    130 sc_out<bool>  berr;  // bus error
    131 }
    132 
    133 The possible values for the data access ‘’’type’’’ are defined below :
    134 
    135 enum data_access_type {
    136 RW ,   // Read Word Cached
    137 RH ,  // Read Half Cached
    138 RB  ,  // Read Byte Cached
    139 RZ ,   // Cache Line Invalidate
    140 RWU ,  // Read Word Uncached
    141 RHU ,  // Read Half Uncached
    142 RBU ,  // Read Byte Uncached
    143 WW ,  // Write Word
    144 WH ,  // Write Half
    145 WB ,  // Write Byte
    146 SC ,  // Store Conditional word
    147 LL ,  // Load Linked word
    148 }
    149 
    150 The possible values for the instruction access ‘’’type’’’ are defined below :
    151 
    152 enum ins_access_type {
    153 RC ,  // Read Instruction Cached
    154 RU ,  // Read Instruction Uncached
    155 }
    156 
    157 The mode parameter, defining the processor mode, is used for access right checking. It is not used by the ‘’’VciXcache’’’ component , but this parameter is mandatory for a cache controler supporting a page based protection scheme. Due to the pipe-lined structure of the processor, the ‘’’mode’’’ parameter can have different values for instruction and data requests. The possible values are defined below :
    158 
    159 enum access_mode {
    160 USER ,         
    161 KERNEL ,                                       
    162 HYPER ,
    163 }
     121    sc_in<bool>  req;  // valid request
     122    sc_in<sc_dt::sc_uint<4>  >  type ;  // data access type
     123    sc_in<sc_dt::sc_uint<2> > mode;  // processor mode 
     124    sc_in<sc_dt::sc_uint<32> >  wdata;  // data to be written
     125    sc_in<sc_dt::sc_uint<32> >  adr;  // data address
     126    sc_out<bool>  frz ;  // frozen processor
     127    sc_out<sc_dt::sc_uint<32> >  rdata;  // read data
     128    sc_out<bool>  berr;  // bus error
     129}
     130}}}
     131
    164132 = E) CABA modeling =
    165133
    166 The CABA modeling for a complete CPU (processor + cache) is presented in figure 3.
    167 The processor ISS is wrapped in the generic CABA wrapper, implemented by the class ‘’’ !IssWrapper’’’.
    168 This class inherit the class ‘’’ !Caba::ModuleBase’’’, that is the basis for all CABA modules.
    169 The class ‘’’ !IssWrapper’’’ contains the member variable ‘’’iss’’’ representing the processor ISS. The type of the ‘’’iss’’’ variable is defined by the template parameter ‘’’iss_t’’’.
    170 
    171 
    172 
    173 
    174 
    175 
    176 
    177 
    178 
    179 
    180 FIGURE 3
    181 
    182 To communicate with the ‘’’ !VciXcache’’’, the ‘’’ !IssWrapper’’’ class contains two member variables ‘’’p_icache’’’, of type ‘’’ !IcacheProcessorPort’’’ and ‘’’p_dcache, of type ‘’’ !DcacheProcessorPort’’’.
    183 
    184 This class contains also N member variables ‘’’p_irq[i]’’’, of type ‘’’sc_in<bool>’’’, representing the interrupt ports. The number N of interrupt ports depends on the wrapped ISS, an is defined by the ‘’’n_irq’’’ member variable of the ‘’’iss’’’ object.
     134The CABA modeling for a complete CPU (processor + cache) is presented in figure 2.
     135The processor ISS is wrapped in the generic CABA wrapper, implemented by the class '''!IssWrapper'''.
     136This class inherit the class '''!Caba::ModuleBase''', that is the basis for all CABA modules.
     137The class '''!IssWrapper''' contains the member variable '''iss''' representing the processor ISS. The type of the '''iss''' variable - defining the type of theprocessor - is specified by the template parameter '''iss_t'''.
     138
     139[[Image(caba_model.png, nolink)]]
     140
     141To communicate with the '''!VciXcache''', the '''!IssWrapper''' class contains two member variables '''p_icache''', of type '''!IcacheProcessorPort''' and '''p_dcache''', of type '''!DcacheProcessorPort'''.
     142
     143This class contains also N member variables '''p_irq[i]''', of type '''sc_in<bool>''', representing the interrupt ports. The number N of interrupt ports depends on the wrapped ISS, an is defined by the '''n_irq''' member variable of the '''iss''' object.
    185144
    186145The CABA wrapper is presented below :