-
req和ack
比如ifu向biu发读内存请求ifu_biu_req，一旦仲裁后得到axi总线，biu发回biu_lsu_ack。 但是ack不能参与到req的逻辑里去，会出现combinational loop，通过dff存一次也不行，loop的warning虽然没有了，但实际在fpga上运行的时候会发现能跑到的频率低很多，比如能跑到75mhz的只能跑50mhz。当时没看综合后工具给出的fmax。 现在c7bbiu实现的方式是biu自己记录当前自己是不是busy，如果busy就不接受新请求，而对req要求不是很严。 比如ifu_biu_req可以是----_，一直给high，直到要求的数据接收到rdata_valid。 这样很不好的一个问题就是，如果数据很久不到，ifu_biu_req就一直是high。现在是lsu的priority更高，如果lsu_biu_req一直是high。现在是单发射，所以问题不明显。 见到的req ack的用法是，requestor自己记录biu是不是busy，比如刚发出了ifu_biu_req，并且通过rd_arbitrator后得到ar channel，发回了biu_ifu_ack。这时ifu自己标记biu_busy。 也就是ifu_biu_req的请求不应该有连续两个high的cycle。 这个还要试试才行。 // instruction fetch in progress wire if_in_prog_in; wire if_in_prog_q; wire biu_busy; assign biu_busy = if_in_prog_q; // | others // if inst_cancel, inst_valid_f will not coming, so let if_in_prog_in finish wire if_fin; assign if_fin = inst_valid_f | inst_cancel; assign if_in_prog_in...
-
ifu fetch request logic
现在的问题是：ifu 发出的ifu_biu_rd_req，是按一个cycle触发的。也就是说–_表示ifu发出了2次request。结果就是biu register了这个请求，连着发出了同一addr同一arid的请求，这样发有问题。 这样有问题，以为ifu发出第一个req后，读的数据还没回来，这时候biu不应该接受ifu发出的第2个req。这时候biu可以发lsu的req，因为arid不同。 看了下代码，是对应的axi_ar_ready_ifu还没有实现。 assign biu_ifu_rd_ack = axi_ar_ready /*& axi_ar_ready_ifu*/ & ifu_select; assign biu_lsu_rd_ack = axi_ar_ready /*& axi_ar_ready_lsu*/ & lsu_select; assign arb_rd_val = biu_ifu_rd_ack | biu_lsu_rd_ack; axi_ar_ready_ifu以ifu_select开始，以axi_rdata_ifu_val结束。 改名成axi_ar_busy_ifu。 // scenario 0 // // ifu_select : _-_____ // axi_rdata_ifu_val : _____-_ // // axi_ar_busy_ifu_in : _----__ // axi_ar_busy_ifu_q : __----_...
-
axi channel valid control
原来我是用下面这种方式控制axi channel里的valid，比如ar_valid。 但当结束信号ext_biu_ar_ready和开始信号arb_rd_val_q一起high起来的时候会有问题，后面还需要补偿下 arb_rd_val_q 这个scenario 2我也不记得当时什么场景了， 好像不太对，先这么放着了。 // scenario 0 // // arb_rd_val_q : _-_____ // ext_biu_ar_ready : _____-_ // // ar_valid_in : _----__ // ar_valid_q : __----_ // biu_ext_ar_valid : _-----_ // scenario 1 // // arb_rd_val_q : _-_____ // ext_biu_ar_ready : _-_____ // // ar_valid_in : _______ //...