Changes between Version 10 and Version 11 of Writing Rules/RISC


Ignore:
Timestamp:
Jan 7, 2008, 8:10:01 PM (16 years ago)
Author:
alain
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Writing Rules/RISC

    v10 v11  
    9292 = C) ISS internal organisation =
    9393
    94 As an example, we present the general structure of the MIPS R3000 ISS, as depicted in the chronogram of figure 1. The instruction fetch, instruction decode, and instruction execution are done in one cycle. A specific register '''r_npc''' is introduced to model the delayed branch mechanism : the instruction following a branch instruction is always executed. The load instructions are executed in two cycles, as those instructions require two cache access (one for the instruction, one for the data). The ISS can issue two simultaneous request for the instruction cache, and the data cache, but those requests are done for different instructions.
     94As an example, we present the general structure of the MIPS R3000 ISS (chronogram of figure 1). The instruction fetch, instruction decode, and instruction execution are done in one cycle. A specific register '''r_npc''' is introduced to model the delayed branch mechanism : the instruction following a branch instruction is always executed. The load instructions are executed in two cycles, as those instructions require two cache access (one for the instruction, one for the data). The ISS can issue two simultaneous request for the instruction cache, and the data cache, but those requests are done for different instructions.
    9595
    9696[[Image(mips_iss.png, nolink)]]
    9797
    98 The '''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).
    99 
    100 From 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.
     98The '''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 executed at cycle (i+1).
     99
     100From an implementation point of view, a specific ISS is implemented by a class '''processorIss'''. This class inherits the class '''genericIss''', that defines the prototypes of the access function presented in section B, (defined as virtual functions).
    101101
    102102= D) Generic cache controler =
     
    111111    sc_in<bool>  req;  // valid request
    112112    sc_in<sc_dt::sc_uint<2>  >  type ;  // instruction access type
    113     sc_in<sc_dt::sc_uint<2> > mode;  // processor mode 
    114113    sc_in<sc_dt::sc_uint<32> >  adr;  // instruction address
    115114    sc_out<bool>  frz ;  // frozen processor
     
    121120    sc_in<bool>  req;  // valid request
    122121    sc_in<sc_dt::sc_uint<4>  >  type ;  // data access type
    123     sc_in<sc_dt::sc_uint<2> > mode;  // processor mode 
     122    sc_in<sc_dt::sc_uint<32> >  adr;  // data address
    124123    sc_in<sc_dt::sc_uint<32> >  wdata;  // data to be written
    125     sc_in<sc_dt::sc_uint<32> >  adr;  // data address
    126124    sc_out<bool>  frz ;  // frozen processor
    127125    sc_out<sc_dt::sc_uint<32> >  rdata;  // read data
     
    134132The CABA modeling for a complete CPU (processor + cache) is presented in figure 2.
    135133The processor ISS is wrapped in the generic CABA wrapper, implemented by the class '''!IssWrapper'''..
    136 The class '''!IssWrapper''' contains the member variable '''m_iss''' representing the processor ISS. The type of the '''m_iss''' variable - defining the type of the processor - is specified by the template parameter '''iss_t'''. The class '''!VciXcache''' inherit the class '''caba::!ModuleBase''', that is the basis for all CABA modules.
     134The class '''!IssWrapper''' contains the member variable '''m_iss''' representing the processor ISS. The type of the '''m_iss''' variable - defining the type of the
     135wrapped processor - is specified by the template parameter '''iss_t'''. The class '''!IssWrapper''' inherit the class '''caba::!ModuleBase''', that is the basis for all CABA modules.
    137136
    138137[[Image(caba_wrapper.png, nolink)]]