URL
https://opencores.org/ocsvn/pavr/pavr/trunk
Subversion Repositories pavr
[/] [pavr/] [trunk/] [doc/] [html/] [group__pavr__control.html] - Rev 6
Compare with Previous | Blame | View Log
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html><head><meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1"> <title>Pipeline structure</title> <link href="doxygen.css" rel="stylesheet" type="text/css"> </head><body> <!-- Generated by Doxygen 1.2.16 --> <center> <a class="qindex" href="main.html">Main Page</a> <a class="qindex" href="modules.html">Modules</a> <a class="qindex" href="pages.html">Related Pages</a> </center> <hr><h1>Pipeline structure<br> <small> [<a class="el" href="group__pavr__implementation.html">Implementation</a>]</small> </h1><table border=0 cellpadding=0 cellspacing=0> </table> <dl compact><dt><b> Shift-like flow</b><dd> pAVR has a pipeline with 6 stages: <ul> <li> 1. read Program Memory (PM) <li> 2. strobe Program Memory output into instruction register (INSTR) <li> 3. decode instruction and read Register File (RFRD) <li> 4. strobe Register File output (OPS) <li> 5. execution or Unified Memory access (ALU) <li> 6. write Register File (RFWR) </ul> <br> <div align="center"> <img src="pavr_pipestruct_01.gif" alt="pavr_pipestruct_01.gif"> </div> <br> Each pipeline stage is pretty much of an independent state machine. <br> <br> Basically, each pipeline stage receives values from the previous one, in a <b>shift-like</b> flow. Only the `terminal' registers contain data actually used, the previous ones are used just for synchronization. <br> For example, this is how a particular hardware resource request flows through pipeline stages s3, s4 until it is processed in s5: <br> <br> <div align="center"> <img src="pavr_pipestruct_02.gif" alt="pavr_pipestruct_02.gif"> </div> <br> <b>Exceptions</b> from this `normal' flow are the <b>stall</b> and <b>flush</b> actions, which can basically independently stall or reset to zero (force a nop into) any stage. Other exceptions are when several registers in such a chain are actually used, not only the terminal one. <br> <br> Apart from the (main) pipeline stages above (stages s1-s6), there are a number of pipeline stages only needed by a few instructions (such as 16 bit arithmetic, some of the skips, returns): s61, s51, s52, s53 and s54. During these pipeline stages, the main stages are stalled. <br> <br> Stages s1, s2 are common to all instructions. They bring the instruction from Program Memory (PM) into the instruction register (instruction fetch stages). <br> During stage s3, the instruction just read from PM is decoded. That is, the following pipeline stages (s4, s5, s6, s61, s51, s52, s53, s54) are instructed what to do, by means of dedicated registers. <br> <br> At a given moment, a pipe stage stage can do one of the following actions: <ul> <li> execute normally <br> The registers in that stage are loaded with: <ul> <li> Values from the previous stage, if that stage is different from s1 or s2 or s3 <li> Some particular values if that stage is s1 or s2 (those values are set by the Program Memory manager) <li> Values from the instruction decoder, if that stage is s3 </ul> <li> flush (execute nop) <br> All registers in that stage are reseted to zero. <li> stall <br> All registers in that stage are kept unchanged. </ul> <br> </dl><dl compact><dt><b> Hardware resource managing</b><dd> Pipeline stages can request access to hardware resources. Access to hardware resources is done via dedicated hardware resource managers (one manager per hardware resource; one VHDL process per manager). <br> <br> Main hardware resources: <ul> <li> Register File (RF) <li> Bypass Unit (BPU) <ul> <li> Bypass Register 0 (Bypass chain 0) (BPR0) <li> Bypass Register 1 (Bypass chain 1) (BPR1) <li> Bypass Register 2 (Bypass chain 2) (BPR2) </ul> <li> IO File (IOF) <li> Status Register (SREG) <li> Stack Pointer (SP) <li> Arithmetic and Logic Unit (ALU) <li> Data Access Control Unit (DACU) <li> Program Memory (PM) <li> Stall and Flush Unit (SFU) </ul> <br> Only one such request can be received by a given resource at a time. If multiple accesses are requested from a resource, its access manager will assert an error during simulation; that would indicate a design bug. <br> The pipeline is built so that each resource is normally accessed during a fixed pipeline stage: <ul> <li> RF is normally read in s3 and written in s6. <li> IOF is normally read/written in s5. <li> DM is normally read/written in s5. <li> DACU is normally read/written in s5. <li> PM is normally read in s1. </ul> However, exceptions can occur. For example, LPM instructions need to read PM in stage s5. Also, loads/stores must be able to read/write RF in stage s5. <br> Exceptions are handled at the hardware resource managers level. <br> </dl><dl compact><dt><b> Stall and Flush Unit</b><dd> Because of the exceptions above, different pipeline stages can compete for a given hardware resource. A mechanism must be provided to handle hardware resource conflicts. The SFU implements this function, by arbitring hardware resource requests. The SFU stalls some instructions (some pipeline stages), while allowing others to execute. <br> <br> Stall handling is done through two sets of signals: <ul> <li> SFU requests (SFU inputs) <ul> <li> stall requests <li> flush requests <li> branch requests <li> skip requests <li> nop requests </ul> <li> SFU control signals (SFU outputs) <ul> <li> stall control <li> flush control </ul> There is one pair of stall-flush control signals for each of the pipeline stages s1, s2, s3, s4, s5, s6. </ul> <br> <div align="center"> <img src="pavr_hwres_sfu_01.gif" alt="pavr_hwres_sfu_01.gif"> </div> <br> Each instruction has an embedded stall behavior, that is decoded by the instruction decoder. <br> Various instructions in the pipeline, in different execution phases, access the SFU exactly the same way they access any other hardware resources, through SFU access requests. <br> The SFU prioritizes stall/flush/branch/skip/nop requests and postpones younger instructions until older instructions free the hardware resources (SFU hardware resource including). The postponing process is done through the stall-flush controls, on a per-pipeline stage basis. <br> The `SFU rule': when a resource conflict appears, the older instruction wins. <br> <br> Some instructions need to insert a nop <b>before</b> the instruction `wave front', for freeing hardware resources normally used by younger instructions. For example, loads must `steal' the Register File read port 1 from younger instructions. <br> Nops are inserted by stalling certain pipe stages and flushing other, or possibly the same, stages. <br> Other instructions need a nop <b>after</b> the instruction wave front, for the previous instruction to complete and free hardware resources. For example, stores must wait a clock, until the previous instruction frees the Register File write port. <br> The two situations differ pretty much from the point of view of the control structure. In the second situation, the instruction is required to stall and flush itself, which adds additional problems. These problems are solved by introducing a dedicated noping state machine in stage s4, whose only purpose is to introduce at most one nop <b>after</b> any instruction. On the other hand, introducing nops <b>before</b> an instruction wave front is straightforward, as any instruction can stall/flush younger instructions by means of SFU requests. <br> <br> The specific SFU requests can be found <a class="el" href="group__pavr__hwres__sfu.html">here</a>. <br> </dl><dl compact><dt><b> Shadowing</b><dd> Let's consider the following situation: a load instruction reads the Data Memory during pipe stage s5. Suppose that next clock, an older instruction stalls s6, during which Data Memory output was supposed to be written into the Register File. After another clock, the stall is removed, and s6 requests to write the Register File, but the Data Memory output has changed during the stall. Corrupted data will be written into the Register File. With the shadow protocol, the Data Memory output is saved during the stall. When the stall is removed, the Register File is written with the saved data. <br> <br> <b>The</b> <b>shadow</b> <b>protocol</b> <br> If a pipe stage is not permitted to place hardware resource requests, then mark every memory-like entity in that stage as having its output `shadowed', and write its associated shadow register with the corresponding data output. Else, mark it as `unshadowed'. <br> As long as the memory-like enity is marked `shadowed', it will be read (by whatever entity needs that) from its associated shadow register, rather than directly from its data output. <br> In order to enable shadowing during multiple, successive stalls, shadow memory-like entities only if they aren't already shadowed. <br> <br> Basically, the condition that shadows a memory-like entity's output is `hardware resources are disabled during that stage'. However, there are exceptions. For example, LPM family instructions steal Program Memory access by stalling the instruction that would normally be fetched that time. By stalling, hardware resource requests become disabled in that pipe stage. Still, LPM family instructions must be able to access directly Program Memory output. Here, the PM must not be shadowed even though during its pipe stage s2 (during which PM is normally accessed) all hardware requests are disabled by default. <br> Fortunately, there are only a few such exceptions (holes through the shadow protocol). Overall, the shadow protocol is still a good idea, as it permits natural & automatic handling of a bunch of registers placed in delicate areas. <br> <br> </dl> <p> <dl compact><dt><b> <a class="el" href="todo.html#_todo000002">Todo: </a></b><dd> <ul> <li> Branch prediction with hashed branch prediction table and 2 bit predictor. <li> Super-RAM interfacing to Program Memory. <br> A super-RAM is a classic RAM with two supplemental lines: a mem_rq input and a mem_ack output. The device that writes/reads the super-RAM knows that it can place an access request when the memory signalizes it's ready via mem_ack. Only then, it can place an access request via mem_rq. <br> A super-RAM is a super-class for classic RAM. That is, a super-RAM becomes classic RAM if the RAM ignores mem_rq and keeps continousely mem_ack to 1. <br> The super-RAM protocol is so flexible that, as an extreme example, it can serially (!) interface the Program Memory to the controller. That is, about 2-3 wires instead of 38 wires, without needing to modify anything in the controller. Of course, that would come with a very large speed penalty, but it allows choosing the most advantageous compromise between the number of wires and speed. The only thing to be done is to add a serial to parallel converter, that complies to the super-RAM protocol. <br> After pAVR is made super-RAM compatible, it can run anyway from a regular RAM, as it runs now, by ignoring the two extra lines. Thus, nothing is removed, it's only added. No speed penalty should be payed. <br> A simple way to add the super-RAM interface is to force nops into the pipeline as long as the serial-to-parallel converter works on an instruction word. <br> <li> Modify stall handling so that no nops are required <b>after</b> the instruction wavefront. The instructions could take care of themselves. The idea is that a request to a hardware resource that is already in use by an older instruction, could <b>automatically</b> generate a stall. <br> That would: <ul> <li> generally simplify instruction handling <li> make average instruction execution slightly faster. </ul> </ul> </dl> <p> <br> <br> <hr><address align="right"><small>Generated on Tue Dec 31 20:26:30 2002 for Pipelined AVR microcontroller by <a href="http://www.doxygen.org/index.html"> <img src="doxygen.png" alt="doxygen" align="middle" border=0 width=110 height=53></a>1.2.16 </small></address> </body> </html>