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


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

--

Legend:

Unmodified
Added
Removed
Modified

  • Writing Rules/RISC

    v2 v3  
    2929This modeling approach supposes that all ISS implement the same generic API (Application Specific Interface), as this API must be independant from both the procesor architecture, and the wrapper type.
    3030
    31 The proposed method makes the assumption that the processors use the ‘’’VcIXcache’’’ cache controler available in the SoCLib library to interface the VCI interconnect. Such modular approach allows to share the modeling effort of the L1 cache controler. The functionnal validation and debug of this component has been a tedious task, and such reuse is probably a good policy. Nevertheless, a clean procedural interface has been defined between the processor core, and the cache controler, and the cache behaviour can be easily modified if required. 
     31The proposed method makes the assumption that the processors use the '''VcIXcache''' cache controler available in the SoCLib library to interface the VCI interconnect. Such modular approach allows to share the modeling effort of the L1 cache controler. The functionnal validation and debug of this component has been a tedious task, and such reuse is probably a good policy. Nevertheless, a clean procedural interface has been defined between the processor core, and the cache controler, and the cache behaviour can be easily modified if required. 
    3232
    3333Finally this generic approach has been exploited to develop the gdbServer module that is mandatory to help the debug of the multi-tasks application software running on the MP-SoC architectures modeled with SoCLib. This tool can be used for all simulation models compliant with the method described below.
    … …  
    3535= B) Generic ISS API =
    3636
    37 As explained in the introduction, the modeling method relies on a generic ISS API, usable by any 32 bits RISC processor, and by the three wrappers CABA, TLM-T & PV. The Instruction Set Simulator corresponding to a given processor handles a set of registers definning the processor internal state. The API described below defines a procedural interface to allows the various  wrappers  to access those registers. The main access function is the ‘’’step()’’’ function, that executes one ISS step : For an untimed model (PV wrapper) one step corresponds to one instruction. For a timed model (CABA wrapper or TLM-T wrapper), one step corresponds to one cycle.
     37As explained in the introduction, the modeling method relies on a generic ISS API, usable by any 32 bits RISC processor, and by the three wrappers CABA, TLM-T & PV. The Instruction Set Simulator corresponding to a given processor handles a set of registers definning the processor internal state. The API described below defines a procedural interface to allows the various  wrappers  to access those registers. The main access function is the '''step()''' function, that executes one ISS step : For an untimed model (PV wrapper) one step corresponds to one instruction. For a timed model (CABA wrapper or TLM-T wrapper), one step corresponds to one cycle.
    3838
    3939
    … …  
    4242
    4343 * '''inline bool isBusy()'''
    44 This function is only used by timed wrappers (CABA & TLM-T). In RISC processors, most instructions have a visible latency of one cycle. But some instructions (such as multiplication or division) can have a visible latency larger than one cycle. This function is called by the CABA and TLM-T wrappers before executing one step : If the processor is busy, the wrapper calls the ‘’’nullStep()’’’ function. If the processor is available, the wrapper may call the ‘’’step()’’’ function to execute one instruction.
     44This function is only used by timed wrappers (CABA & TLM-T). In RISC processors, most instructions have a visible latency of one cycle. But some instructions (such as multiplication or division) can have a visible latency larger than one cycle. This function is called by the CABA and TLM-T wrappers before executing one step : If the processor is busy, the wrapper calls the '''nullStep()''' function. If the processor is available, the wrapper may call the '''step()''' function to execute one instruction.
    4545
    4646 * '''inline void step()'''
    … …  
    5151 
    5252 * '''inline void getInstructionRequest (bool & req , enum !InsAccessType       & type, uint32_t & address)'''
    53 This function is used by the wrapper to obtain from the ISS the instruction request parameters. The ‘’’req’’’ parameter is true when there is a valid request. The ‘’’address’’’ parameter is the instruction address. The  ‘’’type’’’ parameter can have the values defined below: 
     53This function is used by the wrapper to obtain from the ISS the instruction request parameters. The '''req''' parameter is true when there is a valid request. The '''address''' parameter is the instruction address. The  '''type''' parameter can have the values defined below: 
    5454{{{
    5555enum InsAccessType {
    … …  
    6060
    6161 * '''inline void getDataRequest (bool &req , enum !DataAccessType      & type, uint32_t & address, uint32_t & wdata)'''
    62 This function is used by the wrapper to obtain from the ISS the data request parameters. The ‘’’req’’’ parameter is true when there is a valid request. The ‘’’address’’’ parameter is the data address, and the ‘’’wdata’’’ parameter is the data value to be written. The  ‘’’type’’’ parameter is  defined below :
     62This function is used by the wrapper to obtain from the ISS the data request parameters. The '''req''' parameter is true when there is a valid request. The '''address''' parameter is the data address, and the '''wdata''' parameter is the data value to be written. The  '''type''' parameter is  defined below :
    6363{{{
    6464enum DataAccessType {
    … …  
    7979
    8080 * '''inline void setInstruction (bool error, uint32_t ins)'''
    81 This function is used by the wrapper to transmit to the ISS, the instruction to be executed (‘’’ins’’’ parameter). In case of exception (bus error), the ‘’’error’’’ parameter is set.
     81This function is used by the wrapper to transmit to the ISS, the instruction to be executed ('''ins''' parameter). In case of exception (bus error), the '''error''' parameter is set.
    8282
    8383 * '''inline void setRdata (bool error, uint32_t rdata)'''
    84 This function is used by the wrapper to transmit to the ISS, the read data (‘’’rdata’’’ parameter). In case of exception (bus error), the ‘’’error’’’ parameter is set.
     84This function is used by the wrapper to transmit to the ISS, the read data ('''rdata''' parameter). In case of exception (bus error), the '''error''' parameter is set.
    8585
    8686 * '''inline void setWriteBerr ()'''
    … …  
    8888
    8989 * '''inline void setIrq (uint32_t irq)'''
    90 This function is used by the wrapper to signal the current value of the interrupt lines. For each processor, the number of interrupt lines must be defined by the ISS variable ‘’’n_irq’’’.
     90This function is used by the wrapper to signal the current value of the interrupt lines. For each processor, the number of interrupt lines must be defined by the ISS variable '''n_irq'''.
    9191 
    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 2. 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.
    95 
    96 [[Image(chronogramme.png, nolink)]]
    97 
    98 
    99 
    100 
    101 
    102 
    103 
    104 
    105 
    106 
    107 
    108 
    109 
    110 
    111 
    112 
    113 
    114 
    115 
    116 
    117 
    118 
    119 
    120 
    121 
    122 FIGURE 2
    123 
    124 
    125 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 can then start the instruction execution using the ‘’’step()’’’ function. The general registers ‘’’r_gp’’’, as well as the ‘’’r_mem’’’ registers defining the possible data  access, and the ‘’’r_pc’’’ & ‘’’r_npc’’’ will be modified. If, at the end of cycle (i) the ‘’’r-mem’’’ register contain a valid data access, this access will be performed during the next cycle, in parallel with the execution of instruction (i+1).
    126 
    127 
    128 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. Those functions are defined as virtual functions in the class ‘’’genericIss’’’.
     94As 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.
     95
     96[[Image(mips_iss.png, nolink)]]
     97
     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 (i+1).
     99
     100
     101From 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.
    129102
    130103= D) Generic cache controler =