【Loongson】支持AXI总线接口

概述

支持axi接口。但其实没有burst，没有cache，没有tlb，所以仿真起来全是空泡，冲突转发相关功能正确性就测不出来。

从sram改为axi：等待时间从一拍到看信号握手

主要更改/bug处：

• 访存指令（取指令/存取ram）自身
• 跳转指令和访存指令
• 异常处理跳出
• 异常处理跳回
• 异常和访存指令

Bug_Log

1.D级跳转指令未起作用便向下流水

F级等待raddr指令数据时，将PC的写使能禁了，因而此时D级跳转指令无法生效；因为疏忽将D级及以后继续流水，导致跳转指令失去效益，跳转失败。

核心问题：一条指令流向下一级的必要条件是，在当前流水级完成了自己的使命。

感觉随着以后各种延迟等待的加入，以及指令功能的复杂度增加，使用各种顶层信号控制流水线的各级阻塞/运转会越来越麻烦。或许每一级之间是否流水也弄一个握手信号会方便？

2.访存指令时流水线暂停导致F级漏过axi读通道返回的inst指令

F_instr采用wire类型直接接收rdata而无法存储。

当M级发现store/load指令时发出data_req指令，M级前的流水线暂停（写使能置零），但此时F_pc的读指令请求已然发出。若指令返回时data_req未结束，则因为流水线的暂停导致获取的指令无法被存入D级而丢失。

打圈处指令丢失；同时三条蓝线标记分别表示：data_req开始（M检测到store/load指令）、data_req结束（store指令存完/load指令返回）、下一个inst_ok到来（bvalid和bready握手，之后PC可以在下一个上升沿更新）

---

其实根本不需要。这是多个错误杂糅后显现出的表象

个人的F级只有在inst_data_ok时才会往后流水，所以data_req后并不会动，ar会继续发送相同的PC值，所以指令丢失了没关系。

3.误将data_addr_ok当作store指令完成的标志

借用了类SRAM接口中定义的addr_ok，结果看错了，以为store和load指令处理完毕的信号情况是不一样的。其实都是以bvalid和bready是否握手作为判据之一的。

4.整个wdata信号忘记传值了！

太离谱了，直接忘记了写信号，直到0xbfc4_9628处lw指令才发现。

先是从访问ram中值得到XXXXXXXX，百思不得其解啊，前面也有好多lw没问题的；然后对比了下，前面的访存是取1faf_xxxx中的值（也就是外设），而此处是000d_9b68即ram中的值。

比对确认地址有效后，开始看axi各信号的具体情况；（原先指加了几个握手信号）然后发现wdata一直是ZZZZZZZZ，才惊觉忘传信号。。。

这里察觉到，使用soc_lite.v中的信号最佳，cpu_xxx即为本cpu的axi信号，conf_xxx和ram_xxx分别是外设和ram中的axi信号，很清楚。

5.与异常时的跳转不适配

Req相关机制和axi的运作没有适配。

当M级检测到异常指令（PC=bfc6_9f7c）想要跳转时，当前axi接口ar读指令（PC=bfc6_9f80）请求已发出，正在等待返回；若直接跳转到bfc0_0380处，则当bfc6_9f80的指令信息返回时，会被CPU误以为是bfc0_0380的指令而流水，导致：多执行了异常后指令，少执行异常处理首指令。

修正：
源头来自于ar发出的指令覆水难收，于是最直接的想法就是暂停流水级。M级检测到异常必然晚于F级取指的指令发出，因而当Req为1时，暂停M级及之前的流水级，等待rdata正确传回指令（inst_ok）时，启动异常处理跳转的相关机制。

修改时，又注意到CP0设计时Req输出信号的性质：

// In "CP0.v"
assign IntReq = ( (|(HWInt & `IM72)) || (|(`IP10 & `IM10)) || `TI) && ~`EXL && `IE;   //soft cannot write IP72
assign ExtReq = (ExcCodeIn != `Exc_Null) && ~`EXL;     // exception exit & idle
assign Req = IntReq | ExtReq;

而当Req为1时，下一拍`EXL“异常级”位会被置1：也即CP0模块的Req信号只会存在一拍。考量到耦合度问题，不应该为了axi接口修改CP0模块内部实现；于是在M_LEVEL模块增设reg Req_delay信号，并传出ReqOut = Req | Req_delay来实现Req信号对外的延迟。

    reg Req_delay;  // for inst_ok
    always @(posedge Clk) begin
        if (Rst == 1) begin
            Req_delay <= 0;
        end else begin
            if (Req == 1) begin
                Req_delay <= 1;
            end else if (inst_ok) begin
                Req_delay <= 0;
            end
        end
    end
    assign ReqOut = Req | Req_delay;

6.与异常处理结束eret跳转不适配

由于跳转延迟槽的存在而eret不设置延迟槽，D级解码出eret指令后，需将下一次延迟槽传来的指令清空。因为axi的缘故，只有inst_ok时才会流水，所以清空延迟槽的操作要等到那时候才行。

关于Clr信号的冗余设置：
所谓清空延迟槽，不过是将应该传入D级的前一级流水pc/inst信号清空，这和Wait信号对本流水级（D）的行为相同，不同处在于，此时D级写使能为1，Wait信号时，写使能为0.

顶层控制流水级寄存器的信号已经过于紊乱了，相关接口开得意义不明！

要对流水级/寄存器的行为进行整合（这些行为不过就是各流水级Rst和En的排列组合）；顶层信号代表总体排列的含义，传入流水级后自行操纵寄存器。

7.异常信号与data_ok的冲突

当异常与访存相关时，如“地址错异常”，data_ok会影响PC_en的改变。

若Req（及其延迟信号）结束时，data_ok尚未置1（load/store指令发出的ar/aw信号为被处理），则此时PC_en不会回到1，下一刻NPC的bfc0_0380将会丢失。

解决：

// Former
wire PC_en = !stall & inst_ok & data_ok;

// Current
wire PC_en = !stall & inst_ok & (data_ok | Req);

其他各级流水的en也存在这种情况，但由于传入了Req信号会设空泡并改PC为bfc0_0380，所以暂停也无妨；至于load/store指令的错误影响已处理无需担心。