22 | | || || CABA Wrapper || TLM-T Wrapper || PV Wrapper || |
23 | | || ISS MIPSR3000 || CABA Model MIPS || TLM-T Model MIPS || PV Model MIPS || |
24 | | || ISS PPC405 || CABA Model PPC || TLM-T Model PPC || PV Model PPC || |
25 | | || ISS OpenRISC || CABA Model OpenRISC || TLM-T Model OpenRISC || PV Model OpenRISC || |
| 22 | || || CABA Wrapper || TLM-T Wrapper || PV Wrapper || |
| 23 | || ISS MIPSR3000 || CABA Model MIPS || TLM-T Model MIPS || PV Model MIPS || |
| 24 | || ISS PPC405 || CABA Model PPC || TLM-T Model PPC || PV Model PPC || |
| 25 | || ISS OpenRISC || CABA Model OpenRISC || TLM-T Model OpenRISC || PV Model OpenRISC || |
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. |
38 | | |
39 | | |
40 | | * '''inline void reset()''' |
41 | | This function reset all registers defining the processor internal state. |
| 37 | As explained in the introduction, the modeling method relies on a generic ISS API, usable by any 32-bit 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 allow the various wrappers to access those registers. |
| 38 | |
| 39 | Function '''step()''' is the main entry point, it executes one ISS step : |
| 40 | * For an untimed model (PV wrapper) one step corresponds to one instruction. |
| 41 | * For a timed model (CABA wrapper or TLM-T wrapper), one step corresponds to one cycle. |
| 42 | |
| 43 | |
| 44 | API: |
| 45 | |
| 46 | * '''inline void reset()''' |
| 47 | |
| 48 | This function resets all registers defining the processor internal state. |
65 | | RW , // Read Word Cached |
66 | | RH , // Read Half Cached |
67 | | RB , // Read Byte Cached |
68 | | RZ , // Cache Line Invalidate |
69 | | WW , // Write Word |
70 | | WH , // Write Half |
71 | | WB , // Write Byte |
72 | | SC , // Store Conditional Word |
73 | | LL , // Load Linked Word |
| 77 | READ_WORD, // Read Word |
| 78 | READ_HALF, // Read Half |
| 79 | READ_BYTE, // Read Byte |
| 80 | LINE_INVAL, // Cache Line Invalidate |
| 81 | WRITE_WORD, // Write Word |
| 82 | WRITE_HALF, // Write Half |
| 83 | WRITE_BYTE, // Write Byte |
| 84 | STORE_COND, // Store Conditional Word |
| 85 | READ_LINKED, // Load Linked Word |
81 | | This function is used by the wrapper to transmit to the ISS, the response to the data request. In case of a read request, the '''rdata''' parameter contains the read value. In case of exception (bus error), the '''error''' parameter is set. In any case, this function must reset the ISS data request. |
82 | | |
83 | | * '''inline void setWriteBerr ()''' |
| 94 | |
| 95 | This function is used by the wrapper to transmit to the ISS, the response to the data request. In case of a read request, the '''rdata''' parameter contains the read value. In case of exception (bus error), the '''error''' parameter is set. |
| 96 | |
| 97 | In any case, this function must reset the ISS data request. |
| 98 | |
| 99 | * '''inline void setWriteBerr ()''' |
| 100 | |
91 | | As 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. |
| 109 | As 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. |
| 110 | |
| 111 | A specific register '''r_npc''' is introduced to model the delayed branch mechanism : the instruction following a branch instruction is always executed. |
| 112 | |
| 113 | The load instructions are executed in two cycles, as those instructions require two cache access (one for the instruction, one for the data). |
| 114 | The ISS can issue two simultaneous request for the instruction cache, and the data cache, but those requests are done for different instructions. |
95 | | 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 executed at cycle (i+1). |
96 | | |
97 | | From 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). |
| 118 | The '''r_pc''' and '''r_npc''' registers contain respectively the current instruction address, and the next instruction address. |
| 119 | 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. |
| 120 | |
| 121 | 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. |
| 122 | |
| 123 | At the end of cycle (i), if 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). |
| 124 | |
| 125 | From an implementation point of view, a specific ISS is implemented by a class '''processorIss'''. This class inherits the class '''soclib::common::Iss''', that defines the prototypes of the access function presented in section B (defined as pure virtual methods). |
101 | | 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. |
102 | | Both 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. |
| 129 | The hardware component '''!VciXcache''' is a generic cache controler that can be used by various processor cores. |
| 130 | |
| 131 | It contains separated instruction and data caches, but has a single VCI port to acces the VCI interconnect. |
| 132 | |
| 133 | The cache line width, and the cache size are defined as independant parameters for the data cache and the instruction cache. |
| 134 | |
| 135 | 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. |
| 136 | |
| 137 | Both instruction and data caches are blocking : the processor is supposed to be frozen in case of MISS (uncached read acces are handled as MISS). |
| 138 | |
| 139 | Both caches are direct mapped, 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. |
| 140 | |
129 | | The CABA modeling for a complete CPU (processor + cache) is presented in figure 2. |
130 | | The processor ISS is wrapped in the generic CABA wrapper, implemented by the class '''!IssWrapper'''.. |
131 | | 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 |
132 | | wrapped 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. |
| 167 | The CABA modeling for a complete CPU (processor + cache) is presented in figure 2. |
| 168 | |
| 169 | The processor ISS is wrapped in the generic CABA wrapper, implemented by the class '''!IssWrapper'''. |
| 170 | |
| 171 | The class '''!IssWrapper''' contains the member variable '''m_iss''' representing the processor ISS. |
| 172 | The type of the '''m_iss''' variable - defining the type of the wrapped processor - is specified by the template parameter '''iss_t'''. |
| 173 | The class '''!IssWrapper''' inherits the class '''caba::!BaseModule''', that is the basis for all CABA modules. |
136 | | To communicate with the '''!VciXcache''', the '''!IssWrapper''' class contains two member variables '''p_icache''', of type '''!IcacheProcessorPort''' and '''p_dcache''', of type '''!DcacheProcessorPort'''. It contains also the member variable '''p_irq''', that is a pointer to an array of ports of type '''sc_in<bool>'''. This array represents the interrupt ports. The number N of interrupt ports depends on the wrapped processor, an is defined by the '''n_irq''' member variable of the '''iss_t''' class. |
| 177 | To communicate with the '''!VciXcache''', the '''!IssWrapper''' class contains two member variables '''p_icache''', of type '''!IcacheProcessorPort''' and '''p_dcache''', of type '''!DcacheProcessorPort'''. |
| 178 | It also contains the member variable '''p_irq''', that is a pointer to an array of ports of type '''sc_in<bool>'''. |
| 179 | This array represents the interrupt ports. The number N of interrupt ports depends on the wrapped processor, an is defined by the '''n_irq''' static member variable of the '''iss_t''' class. |
245 | | The TLM-T modeling for a complete CPU (processor + cache) is presented in figure 3. |
246 | | To increase the simulation speed, the TLM-T wrapper is the cache controller itself, and it is implemented as the class ''' !VciXcache'''. This class contains the SC_THREAD '''execLoop()''' implementing the PDES process, and the '''m_time''' member variable implementing the associated local clock. The class '''!VciXcache''' inherit the class '''tlmt::!ModuleBase''', that is the basis for all TLM-T modules. |
| 288 | |
| 289 | The TLM-T modeling for a complete CPU (processor + cache) is presented in figure 3. |
| 290 | |
| 291 | To increase the simulation speed, the TLM-T wrapper is the cache controller itself, and it is implemented as the class ''' !VciXcache'''. This class contains the SC_THREAD '''execLoop()''' implementing the PDES process, and the '''m_time''' member variable implementing the associated local clock. |
| 292 | |
| 293 | The class '''!VciXcache''' inherit the class '''tlmt::!ModuleBase''', that is the basis for all TLM-T modules. |
| 294 | |
252 | | This class contains also the member variable '''p_irq''', that is a pointer to an array of ports of type '''SynchroInPort'''. This array represents the interrupt ports. The number N of interrupt ports depends on the wrapped processor, an is defined by the '''n_irq''' member variable of the '''iss_t''' class. |
253 | | |
254 | | The '''execLoop()''' function contains an infinite loop. One iteration in this loop corresponds to one cycle for the local clock, (or more, as the thread is suspended in case of MISS). |
| 300 | |
| 301 | This class also contains the member variable '''p_irq''', that is a pointer to an array of ports of type '''SynchroInPort'''. This array represents the interrupt ports. The number N of interrupt ports depends on the wrapped processor, an is defined by the '''n_irq''' member variable of the '''iss_t''' class. |
| 302 | |
| 303 | The '''execLoop()''' function contains an infinite loop. One iteration in this loop corresponds to one cycle for the local clock (or more, as the thread is suspended in case of MISS). |