Base Predictor Class and Sub Predictor Interface

In the Xiangshan branch prediction unit, all its sub-predictors and the class implementations of Composer are inherited from the sub-predictor base class (BasePredictor). The sub-predictor interface (BasePredictorIO) is also defined in the sub-predictor base class. Therefore, we can consider that Composer and all sub-predictors have the same interface.

In the understanding and verification of sub-prediction, our most direct external interaction occurs in the sub-predictor interface and some variables defined in the sub-predictor base class. Therefore, before verifying the sub-predictor, it is strongly recommended that you read and understand this section of the document.

The general content and usage of the sub-branch predictor interface have been introduced in the Xiangshan Branch Prediction Unit (BPU) Basic Design section. This document will focus on the signal details of the interface.

Sub-Branch Predictor Interface (BasePredictorIO)

Interface Definition: src/main/scala/xiangshan/frontend/BPU.scala

Each sub-branch predictor needs to implement this interface, which defines the input and output interfaces of the sub-branch predictor.

Note: Some signals are defined as numDup quantities, where each signal is exactly the same. Multiple identical signals are for other considerations.

The detailed signal list is as follows:

• reset_vector Reset vector, when reset occurs, the BPU’s pc will be reset to this value.

  • Interface Type：UInt(PAddrBits.W)

• in Information sent from the BPU to the sub-branch predictor

  • Interface Type：DecoupledIO(new BasePredictorInput)
  • Signal List：
    • s0_pc PC of the s0 pipeline stage
      • Interface Type：Vec(numDup, UInt(VAddrBits.W))
    • folded_hist Global folded history information
      • Interface Type：Vec(numDup, new AllFoldedHistories(foldedGHistInfos))
      • Signal List：See（AllFoldedHistories）
    • ghist Global branch history information
      • Interface Type：UInt(HistoryLength.W)
    • resp_in Global branch prediction information (including s1, s2, s3 prediction result information)
      • Interface Type：BranchPredictionResp
      • Signal List：See（BranchPredictionResp）

• out Information sent from the sub-branch predictor to the BPU (including s1, s2, s3 prediction result information)

  • Interface Type：new BasePredictorOutput 继承自 BranchPredictionResp
  • Signal List：See（BranchPredictionResp）

• ctrl BPU sub-predictor enable control signal, mainly used to control whether each predictor is enabled

  • Interface Type：BPUCtrl
  • Interface Type：
    • ubtb_enable: UBTB predictor enable
      • Interface Type：Bool()
    • btb_enable: BTB predictor enable
      • 接Interface Type：Bool()
    • bim_enable: BIM predictor enable
      • Interface Type：Bool()
    • tage_enable: TAGE predictor enable
      • Interface Type：Bool()
    • sc_enable: SC predictor enable
      • Interface Type：Bool()
    • ras_enable: RAS predictor enable
      • Interface Type：Bool()
    • loop_enable: LOOP predictor enable
      • Interface Type：Bool()

• s0_fire s0 stage handshake success signal

  • Interface Type：Vec(numDup, Bool())

• s1_fire s1 stage handshake success signal

  • Interface Type：Vec(numDup, Bool())

• s2_fire s2 stage handshake success signal

  • Interface Type：Vec(numDup, Bool())

• s3_fire s3 stage handshake success signal

  • Interface Type：Vec(numDup, Bool())

• s2_redirect s2 stage redirection signal

  • Interface Type：Vec(numDup, Bool())

• s3_redirect s3 stage redirection signal

  • Interface Type：Vec(numDup, Bool())

• s1_ready s1 stage ready to receive information (Direction: output from the sub-predictor)

  • Interface Type：Bool()

• s2_ready s2 stage ready to receive information (Direction: output from the sub-predictor)

  • Interface Type：Bool()

• s3_ready s3 stage ready to receive information (Direction: output from the sub-predictor)

  • Interface Type：Bool()

• update Update request forwarded from the BPU to the sub-branch predictor

  • Interface Type：Valid(new BranchPredictionUpdate)
  • Signal List：See（BranchPredictionUpdate）

• redirect Redirect request forwarded from the BPU to the sub-branch predictor

  • Interface Type：Valid(new BranchPredictionRedirect)
  • Signal List：See（BranchPredictionRedirect）

The pipeline control signals will be further explained in the following content.

Global Folding History (AllFoldedHistories)

Interface Definition：src/main/scala/xiangshan/frontend/FrontendBundle.scala

Interface Type：AllFoldedHistories(foldedGHistInfos))

The interface information of the global folding history consists of only one FoldedHistory list.

• hist List of folded histories
  • Interface Type：MixedVec(gen.map{case (l, cl) => new FoldedHistory(l, cl, numBr)})

The interface information of FoldedHistory also has only one item.

• folded_hist Single folded history, with a bit width equal to the compressed history length.
  • Interface Type：UInt(compLen.W)

This means that the interface of the global folding history is actually a list that stores folded histories, where each item is a folded history of a specific length.

Base Predictor Class

The base predictor class defines several signals, which can be accessed in each sub-predictor, and several connections are made within it.

Most of the signals are relatively easy to understand. We need to pay particular attention to the pc of each pipeline, which also involves your understanding of pipeline control signals. Therefore, next, we will introduce the meanings of pipeline control signals that need to be paid attention to in sub-predictors, as well as the meanings of the s1_pc, s2_pc, s3_pc signals.

There are three groups of pipeline control signals:

• fire signals (s0, s1, s2, s3)
• redirect signals (s2, s3)
• ready signals (s1, s2, s3)

The pc signals in the base predictor class are divided into four groups, s0_pc_dup, s1_pc_dup, s2_pc_dup, s3_pc_dup. Each group of signals contains multiple pc signals, which are exactly the same and are duplicated for some other reasons. Therefore, we can simply consider them as s0_pc, s1_pc, s2_pc, s3_pc.

Their usage can be seen in the following diagram:

Their relationship with the pipeline control signals is as follows:

• s0_pc is directly connected from the in.s0_pc in the input interface.
• When s0_fire is active, the next cycle s1_pc will output the value of s0_pc.
• When s1_fire is active, the next cycle s2_pc will output the value of s1_pc.
• When s2_fire is active, the next cycle s3_pc will output the value of s2_pc.

In other words, the fire signal affects whether the data of the next cycle is valid. For example, the s0_fire signal affects whether the data of the s1 pipeline is valid, and the s1_fire signal affects whether the data of the s2 pipeline is valid.

Whether the fire signal is valid depends on whether the data of this pipeline stage is valid and whether the next pipeline stage is ready. For example, the s1_fire signal is valid only if the data of the s1 stage is valid and the s2_ready signal from the sub-predictor output is valid. At this point, it can be considered that the data processing of the s1 stage is completed, the s2 stage is ready, and the data of the next cycle will be directly sent to the s2 stage.

Therefore, in the sub-predictor, taking the s1 stage as an example, s1_ready can block data from entering the s1 stage. When s1_ready is active, the data for the s1 stage will be valid in the next cycle. When s1_fire is active, it indicates that the data in the s1 stage is already valid and the predictor has generated the result for the s1 stage. The data will then be directly sent to the s2 stage in the next cycle.

The redirect signal is relatively clear. For example, in the s2 stage, when s2_redirect is valid, it indicates that when s2_fire is valid, the s2 prediction result is different from the s1 prediction result in the previous cycle.