【Loongson】支持AXI总线接口

概述

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

image

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

主要更改/bug处

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

Bug_Log

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

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

image

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

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

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

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

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

image

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


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

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

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

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

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

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

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

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

这里察觉到,使用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的指令而流水,导致:多执行了异常后指令,少执行异常处理首指令。

image

修正
源头来自于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;

image

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指令的错误影响已处理无需担心。

posted @ 2022-03-30 14:00  Elucidator_xrb  阅读(18)  评论(0编辑  收藏  举报