再次请教frontend几个问题

[ddxoxpp]

新的ifu改动挺大的，又拜读了一遍，但有几个地方看不懂，向大佬请教一下：
1）请问false hit lasthalf 是针对哪种错误情况的，为什么false hit不全都产生ifu redirect；或者为什么 false hit lasthalf需要产生ifu redirect，也用haslasthalf信号来通知next fetchpacket起始地址不行吗？

2）false oversize 的问题：为啥ftb entry需要为最后的rvc br或jmp指令设置oversize信号，与普通的last rvc指令一样使用haslasthalf信号通知next fetchpacket的起始地址不行吗？

3）如果false hit导致fallthrouaddr超出startAddr+34byte范围，那么进入ifu的fetch req的fallthrouaddr修正为startAddr+32byte，而如果bpu预测顺序取next fetchpacket，即用超出startAddr+34byte范围的fallthrouaddr地址取next fetchpacket，ifu好像没有对错误此进行纠正？

4）如果false hit造成的f2_ftr_range比f2_jump_range小，那么ifu中有效指令范围中就没有jump指令，那么此fetchpacket之后应该顺序取next fetchpacket; 但是bpu预测的是jump，即bpu不是顺序取的next fetchpacket，此错误好像没有被ifu纠正？

XiangShan/src/main/scala/xiangshan/frontend/IFU.scala

Lines 260 to 262 in 856013d

	val f2_jump_range = Fill(PredictWidth, !f2_ftq_req.ftqOffset.valid) | Fill(PredictWidth, 1.U(1.W)) >> ~f2_ftq_req.ftqOffset.bits
	val f2_ftr_range = Fill(PredictWidth, f2_ftq_req.oversize || f2_ftq_req.ftqOffset.valid) | Fill(PredictWidth, 1.U(1.W)) >> ~getBasicBlockIdx(f2_ftq_req.nextStartAddr, f2_ftq_req.startAddr)
	val f2_instr_range = f2_jump_range & f2_ftr_range

[poemonsense]

Discussions好像没有提醒，没留意到， @Lingrui98 @jinyue110 会回答这个问题

[Lingrui98]

您好，针对您的第二个问题，目前是对最后的rvi跳转指令设置oversize，在这一版开发初期，我们沿用了上一版的思路，为了避免行末后半条rvi跳转指令取不到的问题，采用了这个逻辑。后来发现这个逻辑其实是没有必要的，可以被简化，只是还没来得及做；
我没有理解您的第三个问题，如果BPU预测顺序取next fetchpacket，在目前的参数配置下，一定是startAddr + 32Byte，应该不会出现超过startAddr+34Byte的情况

[ddxoxpp]

感谢大佬回答！

[jinyue110]

(｡･∀･)ﾉﾞ嗨，感谢您对香山项目的关注，针对您的问题：

1. 这个其实是时序的考虑，last half其实可以统一处理，可以规约为fallthrouAddr或者说这个packet的结束边界恰好卡在一条RVI指令中间。但这样处理的坏处在于，需要根据变动的fallthrouAddr去找到最后一条有效指令，然后再判断这个指令是不是半条RVI，predChecker里面做了很多检查，生成的fixedRange逻辑路径比较长，如果再加上这个找最后一条有效指令index的路径，那到终点f3_lastHalf.valid寄存器的时序就会违例。所以这里我们只处理每个packet里第16条指令发生last half的情况，因为这时候最后一条指令的index是常数，省掉了找index的路径。而对于那些提前结束的last half（即最后一条有效指令在16之前，并且卡在一条RVI中间）我们认为是false hit造成的，因为既然提前结束了说明一定做出了预测（e.g. packet里有两条不跳转的分支），而预测结果不对（错误地把结束地址放在了一条RVI指令中间），这时候的情况我们观察下来是少数，因此这种时候我们发redirect 刷掉重新取指令。

2. 这个和我们的range独热码产生的逻辑有关，你可以看到在你贴出的代码的261行，我们计算一个packet的range独热码（每一位为1代表这个2Bytes在这个packet的范围内，为0表示在fallthrouAddr之后了）的算法是根据fallThrouAddr（这个是以前的命名，现在是nextStartAddr），计算出最后一条指令的index，然后取反得到shift=（15 - index）,再把16位全1右移shift位得到这个range，这个算法要是fallthrouaddr大于等于startAddr+34byte就会出错，因此简单起见添加了一个oversize位专门指示这种情况。另外oversize和last half是两种不同的情况，前者是因为最后一条指令是RVI跳转指令并且恰好被32边界卡住，这个时候我们为了把这条算在前半条的packet里，取指令的时候也是按34Byte取，后面的其实地址是从+34开始的，不需要通知后面的packet。而last half是预测器不知道或者误预测了，导致两个相邻的顺序packet之间其实共享同一条RVI指令，这个时候我们通知后一个packet把第一个2Bytes 不要算在内。

3. 这个其实预测器那边会做检查，保证给IFU的不会超过34Bytes.。可以看一下FrontendBundle.scala里关于fallThroughErr的逻辑。

4. 这个确实是一个问题，不过这种情况下做出预测大部分是会被IFU取消掉的（要么类型错，要么位置错，要么跳转地址错），只有在两种情况下会有这样的问题：一是两个br或jal恰好跳到同一个地址，恰好在各自基本块同一个offset；二是两个jalr就在同一个位置。不过这应该算得上是小概率事件导致我们至今没有遇到过。其实我们前端验证的一个问题是我们现在的测试里触发的fase-hit太少了，所以一些这种情况下的bug我们可能还没有考虑到，您说的这种情况其实理论上确实可能发生，我们后续会修复这个问题，感谢您的意见和指导！

Best Wishes!

[ddxoxpp]

感谢大佬回答，在下获益匪浅！

[ddxoxpp]

麻烦再打扰一下，第三个问题是给IFU的时候检查了fallThroughError，并且修正了再给IFU；但是BPU预测target的时候并好像没有检查并修正fallThroughErr，导致BPU与IFU的fallThroughAddr信息不一致。

[Lingrui98]

3. 保证给IFU的不会超过34Bytes.。可以看一下FrontendBundle.scala里关于fallThroughErr的逻辑。

具体参见这几行：

XiangShan/src/main/scala/xiangshan/frontend/FrontendBundle.scala

Lines 409 to 412 in 856013d

	val startLower = Cat(0.U(1.W), pc(instOffsetBits+log2Ceil(PredictWidth), instOffsetBits))
	val endLowerwithCarry = Cat(entry.carry, entry.pftAddr)
	fallThroughErr := startLower >= endLowerwithCarry || (endLowerwithCarry - startLower) > (PredictWidth+1).U
	fallThroughAddr := Mux(fallThroughErr, pc + (FetchWidth * 4).U, entry.getFallThrough(pc))

在FTB生成预测结果时，就对fallThruAddr进行修正

[ddxoxpp]

哦哦，原来是我这边本地的版本没有跟上，不好意思麻烦大佬了！

[Lingrui98]

前一阵子前端代码更新比较频繁，欢迎持续关注最新代码 : )