Step 5 of Self-writing CPU (1) -- pipeline data problems

I will upload my new book "Write CPU by myself" (not published yet). Today is 15th articles. I try to write them every Thursday.

In the previous chapter, the original five-level pipeline structure of openmips is established, but only one Ori instruction is implemented. It will be gradually improved from this chapter. This chapter first discusses issues related to pipeline data, then modifies openmips to solve the problem, and verifies the solution in section 5.3. Then, the command formats, usage, and functions of logic, shift operations, and empty commands are described one by one. In section 5.5, these commands are implemented by extending openmips, and finally the test program is compiled, the implementation results are verified.

5.1 assembly line data problems

The five-level pipeline structure we implemented in Chapter 1 is very simple. If we follow the "simple is beauul ul" standard, our pipeline is beautiful, but not perfect, because the reality is often complicated and a simple pipeline cannot solve so many practical problems, the data-related problems discussed in this section are one of the problems. We must discuss this issue before implementing other commands such as logic and shift operations, because this issue has affected the compilation of the test program.

The pipeline is often referred to as "related", which makes the next instruction in the command sequence unable to be executed according to the designed clock cycle. These "related" will reduce the pipeline performance. There are three types of correlation in the pipeline.

(1) structure-related: refers to the problems arising from hardware resource conflicts during command execution because the hardware resources cannot meet the command execution requirements. For example, commands and data share a memory. In a certain clock cycle, the pipeline needs to complete the access operation of a command to the data in the memory, and to complete Subsequent commands, in this case, a memory access conflict occurs and the structure is related.

(2) data correlation: refers to the execution results of several commands executed in the pipeline.

(3) control related: it refers to the problems caused by branch commands in the pipeline or other commands that require rewriting of the PC.

Structure-related and control-related issues will be discussed in subsequent instruction analysis. This section focuses on data-related issues. There are three types of Pipeline Data: raw, war, and waw.

• Raw: Read after write. If instruction J is a command executed after instruction I, raw indicates that instruction I can only read data from this register after writing data to the Register. If instruction J tries to read the content of this register before writing instruction I into the register, it will get incorrect data.
• War: write after read. Assume that command J is a command executed after command I. War indicates that command I can write this register only after reading data. If instruction J writes this register before instruction I reads data, the data read by instruction I is incorrect.
• Waw: write after write: Assume that instruction J is the instruction executed after instruction I. waw indicates that instruction I can write data to this register only after writing data to the Register. If instruction J writes this register before instruction I, the value of this register is not the latest value.

For the original openmips five-level assembly line established in chapter 1, we can know from the implementation process of the Ori command that the Register will be written only in the back-to-write stage of the assembly line (in fact, the other commands are the same, this will be clearer when other commands are implemented later), so there is no waw related. Because the Register can only be read and written back in the pipeline decoding phase, there is no war correlation, so the openmips pipeline only has raw correlation. There are three raw-related cases.

(1) data correlation exists between adjacent commands

Consider the following code.

1   ori $1,$0,0x1100        # $1 = $0 | 0x1100 = 0x11002   ori $2,$1,0x0020        # $2 = $1 | 0x0020 = 0x1120

1st Ori commands write registers $1, and the subsequent 2nd Ori commands need to read the data of $1, however, only 1st Ori commands write their operation results to $1 in the write-back phase, and 2nd Ori commands need to read the value of $1 in the decoding phase, at this time, 1st Ori commands are still in the execution phase. Therefore, the result is not calculated by the 1st Ori commands. If you calculate this value, errors will inevitably occur. 5-1. This situation can be called data correlation between adjacent commands. For openmips, it can also be called data correlation in the pipeline decoding and execution stages.

(2) there is data correlation between commands separated by one command

Consider the following code.

1   ori $1,$0,0x1100        # $1 = $0 | 0x1100 = 0x11002   ori $3,$0,0xffff        # $3 = $0 | 0xffff = 0xffff3   ori $2,$1,0x0020        # $2 = $1 | 0x0020 = 0x1120

1st Ori instruction write registers $1 and 3rd Ori Instructions need to read register $1 in the decoding phase. At this time, 1st Ori instructions are still in the memory access phase, therefore, the obtained value is not necessarily the correct value. As shown in Figure 5-2. This situation can be referred to as the data correlation between commands separated by one command. For openmips, it can also be referred to as the data correlation in the pipeline decoding and memory access phases.

(3) there is data correlation between commands separated by two Commands

Consider the following code.

1   ori $1,$0,0x1100        # $1 = $0 | 0x1100 = 0x11002   ori $3,$0,0xffff        # $3 = $0 | 0xffff = 0xffff3   ori $4,$0,0xffff        # $4 = $0 | 0xffff = 0xffff4   ori $2,$1,0x0020        # $2 = $1 | 0x0020 = 0x1120

1st Ori instruction write registers $1 and 4th Ori Instructions need to read register $1 during decoding. At this time, 1st instructions are in the write-back stage, at the end of the write-back stage, the rising edge of the clock writes the calculation result to $1. Therefore, the value of $1 is not obtained from the 4th logs. As shown in Figure 5-3. This situation can be referred to as the data correlation between commands separated by two commands. For openmips, it can also be referred to as the data correlation in the pipeline decoding and write-back phases.

Two commands are separated from each other and there is data correlation (that is, there is data correlation in the pipeline decoding and write-back stages). This problem has been solved in the regfile module designed in Chapter 4th, the code of the regfile module is as follows.

Module regfile (......);...... /*************************************** ************************************ section 3: read operation ********************************** **************************************** /// raddr1 indicates the read address, waddr indicates the write address, we indicates the write enable, and wdata indicates the data to be written. Always @(*) begin ...... end else if (raddr1 = waddr) & (We = 'writeenable) & (RE1 = 'readenable )) begin rdata1 <= wdata ;...... end /************************************** ************************************* Section 4: read operation ********************************** **************************************** /// raddr2 is the read address, waddr is the write address, we is the write enabling, and wdata is the data to be written. Always @(*) begin ...... end else if (raddr2 = waddr) & (We = 'writeenable) & (re2 = 'readenable )) begin rdata2 <= wdata ;...... endendmodule

There is a judgment in the reading operation. If the register to be read is the one to be written at the rising edge of the next clock, the data to be written will be directly output as a result. In this way, data is related to two commands separated.

There are three solutions for data correlation between adjacent commands and data correlation between commands separated by one command.

(1) Insert pause period: when the related period is detected, insert some pause periods in the pipeline, as shown in Figure 5-4.

(2) compiler scheduling: After the compiler detects relevant information, it can change the execution sequence of some commands, as shown in Figure 5-5.

(3) Data push-ahead: the calculation result is directly sent from the place where it is generated to other instructions or all required functional units to prevent the pipeline from being paused. In the example 5-6, the new $1 value has been calculated in the execution phase of 1st Ori commands, this value can be directly sent from the execution phase of 1st Ori commands to the decoding phase of 2nd Ori commands, so that 2nd Ori commands get a new value of $1 in the decoding phase. You can also directly send the value from the memory access phase of the 1st Ori instruction to the decoding phase of the 3rd Ori instruction, so that the new value of $1 can be obtained in the decoding phase of the 3rd Ori instruction.

Readers should note that the premise of method (3) is that the value of the new register can be calculated during the execution phase. If the new register value is loaded, this premise is not met, this is because the loading command can obtain the final result in the memory access phase. This is a load-related issue. This case will be considered in this book when loading the storage command. This Chapter does not take it into consideration for the time being.

Next time, we will introduce how openmips solves data-related problems. Stay tuned!