
数字逻辑设计对Verilog使用的记录
分享网站
introduction
进行大作业手撕verilog时会出现很多奇奇怪怪的报错喵,所以我就在这里简简单单整理一下叭。
记录
- 在Verilog中,wire数据类型不能在always块中被赋值,wire类型只能通过连续赋值或模块端口赋值来改变。如果你需要在always块中改变变量的值,你应该使用reg类型。但是当你需要在always块中要对变量p0至p8做清零操作,并且你在setqi a1模块端口中也需要进行赋值操作,这导致了命名空间的冲突。
解决这个问题的一个可行的方案是你可以使用额外的reg类型的变量在always块中操作。这意味着你需要对每个p都定义一个wire和reg配对。在always块中,你可以继续对reg类型的变量进行赋值操作。然后,你可以通过连续赋值语句将wire类型的变量设置为对应的reg类型的变量的值。
1 |
|
- 仿真中需要改变的变量一定是reg类型
verilog基础知识
矢量操作
1 |
|
计组lab记录
lab1
任务一 根据结构图写ALU代码
- 变量前后不一致很关键,如果发现仿真时有不确定变量一定要注意变量
(大小写或者0和O很容易混淆)
lab2
- 进行cpu测试模块的书写
- 但是最后生成比特流时报了离谱的错误
- 但是连线后面变量仔细琢磨了没有大的问题
lab3
lab3-1 手搓乘法器
- 很重要的一点是要弄明白Verilog语言中always语句的并发执行,这和我们以前接触过的高级语言不同,Verilog代码中的语句可以不按顺序执行,这个有点像多线程,也就是说多个任务同时进行。
上面的代码中共有5个always语句,每个always语句都是时钟信号clk的上跳沿触发,也就是说当clk从0变为1的时候,会触发always语句的执行。
lab4
lab4-2 数据通路的实现
- 这个lab其实最主要的还是连线,但是在第一次仿真的时候我发现Rs1_data和Rs2_data均为0,我还要仔细研究一下。
- 经过debug首先是仿真时对立即数的选择出现问题
- 紧接着发现o2_0的值出现未定义的情况(此时是因为大小写的问题alusrc_b)
- 草,别相信ai了写verilog是真不行
lab4-3 扩展指令的实现
- 首先按照stone佬的建议把各个寄存器的值全部输入到vga上面方便查看
- 但是在下板验证时发现连lui都不对,于是乖乖仿真喵
- 仿真1:出现了alu_out?怎么会经过alu?
- 没改immgen啊 废了–immgen和alu都不仅要在接口上进行扩展,还需要在alu内部增加单元,也需要在immgen的控制信号进行修改。
- 在数据通路中检测无误后,但是下板验证时发现load操作有误,也就是ram存在问题。首先我发现我忘记对ram进行初始化,此后观察warning命令发现端口似乎不匹配?wea貌似不是32位?但是我的顶层模块的定义是32位
- 经过再次分析发现,竟然是control模块的bug,我没有定义jalr
lab5
- 流水线操作,当我在最初仿真的时候,我发现output reg貌似不兼容?
- 第一次仿真,全部都没有被赋值,是哪里有误呢?
- 开始从pipline_if开始,怎么好像add_32有误
- 开始仿真ID,发现alu_control输出为Z,数据的写入没问题,说明regs寄存器没有问题(regs之前少了一位,要注意)再次使用指令但是还是发现当前的alu_control输出为Z(未被驱动)草!符号大小写的问题
- 直接开始进行冒险操作,但是仿真时发现存在Z,怀疑是端口的大小有误
- 但是现在发现单独对Ex进行仿真也出现了一点错误,ALU有误!后来直接用逻辑算符实现ALU
- Immsel的端口实现出现错误,ALU实现时的激励端口出现错误
- 现在基本功能仿真没有太大问题,主要观察冒险时可能出现的错误。(stall的Rs1的addr_id始终为零,把out接成addr导致的!!)
- 继续找错误,怀疑是寄存器的逻辑有误?(但是有一说一,助教哥哥教的在vivado仿真时把各个模块的值直接接进去简直不要太方便 orzorz)接下来就是思考冒险到底是怎样实现的!!valid_out_Exmem并没有变成0
- 还有就是流水线的驱动程序,以及最后的wb是否需要reg变量 ,又是激发信号的错误,这和ALU的错误是一样的(不靠谱的github(bushi))
- 最终进入比特流生成阶段,但是现在突然引脚的led信号显示出现错误。
set_property -dict { PACKAGE_PIN H17 IOSTANDARD LVCMOS33 } [get_ports { LED_out[0] }];
set_property -dict { PACKAGE_PIN K15 IOSTANDARD LVCMOS33 } [get_ports { LED_out[1] }];
set_property -dict { PACKAGE_PIN J13 IOSTANDARD LVCMOS33 } [get_ports { LED_out[2] }];
set_property -dict { PACKAGE_PIN N14 IOSTANDARD LVCMOS33 } [get_ports { LED_out[3] }];
set_property -dict { PACKAGE_PIN R18 IOSTANDARD LVCMOS33 } [get_ports { LED_out[4] }];
set_property -dict { PACKAGE_PIN V17 IOSTANDARD LVCMOS33 } [get_ports { LED_out[5] }];
set_property -dict { PACKAGE_PIN U17 IOSTANDARD LVCMOS33 } [get_ports { LED_out[6] }];
set_property -dict { PACKAGE_PIN U16 IOSTANDARD LVCMOS33 } [get_ports { LED_out[7] }];
set_property -dict { PACKAGE_PIN V16 IOSTANDARD LVCMOS33 } [get_ports { LED_out[8] }];
set_property -dict { PACKAGE_PIN T15 IOSTANDARD LVCMOS33 } [get_ports { LED_out[9] }];
set_property -dict { PACKAGE_PIN U14 IOSTANDARD LVCMOS33 } [get_ports { LED_out[10] }];
set_property -dict { PACKAGE_PIN T16 IOSTANDARD LVCMOS33 } [get_ports { LED_out[11] }];
set_property -dict { PACKAGE_PIN V15 IOSTANDARD LVCMOS33 } [get_ports { LED_out[12] }];
set_property -dict { PACKAGE_PIN V14 IOSTANDARD LVCMOS33 } [get_ports { LED_out[13] }];
set_property -dict { PACKAGE_PIN V12 IOSTANDARD LVCMOS33 } [get_ports { LED_out[14] }];
set_property -dict { PACKAGE_PIN V11 IOSTANDARD LVCMOS33 } [get_ports { LED_out[15] }];我先删掉这段。
后来发现是程序的板子型号选择出现错误 - 今天去实验室上机看了看效果,但是发现控制信号的冲突出现一点问题。仿真发现pc_imm的计算是没有问题的,原来是if的pc_in的接线此时应该接imm_out的pc
体系报错记录
体系lab1
当前控制信号的解码没有问题,但是传入的值存在问题
再进一步研究发现detection的传入值的ID出现错误
最后发现问题的来源是在cpu顶层文件传入参数时出现错误