-
RSA验证签名
一直都没搞明白验证数字签名的算法到底叫什么。从RFC8017上看，用RSA算法验证数字签名的方法叫RSASSA-PKCS1-v1_5。 但这里面并没有规定用什么长度的modulus，比如是RSA2048还是RSA4096，是几个质数的算法（经典的RSA是pq两个大素数，但现在PKCS1 v2里有多个大素数的算法）。 hash算法也没有规定。 -v1_5表示的是encoding和padding的方式，比如还有RSASSA-PSS，这个encoding就是带salt的。 encoding和padding就是把要加密的明文，比如是一小串文字，加入padding凑成一个特定的长度。 比如RSA2048里modulus是2048，这个字符串转换成大数的长度也要是2048bits，但要比modulus小。 “RSASSA-PKCS1-v1_5 combines the RSASP1 and RSAVP1 primitives with the EMSA-PKCS1-v1_5 encoding method.” 因为padding有规定的方式，最少的padding也要占11个字节，也就是88个bit。所以RSA2048最大能加密的数据是2048-88=1960， 245个字节。 RSA2048的modulus n是2048bits，d可以是比较小的素数，但3这种太小的就不行，不过可以看出来d不会太大。RSA2048的公钥是n，d放一起，私钥是n，e放一起。 这有个padding的例子，明文比较小的话里面就有大量的FFFFFFFF填进去，同时也以字符的形式写明了hash用的时什么，比如下面这个时SHA-256。这些RFC里都有规定 RFC8017 9.2. EMSA-PKCS1-v1_5。
-
加了req_busy，用来控制data_data_m
自从丢掉cache，自己写core里的axi master，乱套了，x到处都是。。。 bug一个一个的改吧。 现在的情况是只处理data读请求，lsu发data_req过来一个cycle，通过axi向sram读数据。 axi读需要等一个cycle，数据到的时候设置data_data_ok(这个名字太差了，后面改成data_vld)。 lsu发出请求data_req是在_e阶段，后面要把信号名都统一好，应该叫data_req_e。 而data_data_ok应该叫data_data_ok_m。并不是说数据会在下一个cycle就到，而是要在data_req_e +2个cycle准时到。 但既然用了axi协议，数据到达的时间就可以是不确定的，只要rvalid来了，就说明数据到了。 所以_m表示lsu接收数据在_m阶段，如果数据没到，就stall整个pipeline，这时候就一直算做_m里。 (所以data_data_m也要控制stall_ifu的信号。) 现在的思路是： 还是用以前用过的逻辑开关，名字就叫req_busy，表示正在向总线请求数据。 信号的开始位置由data_req决定，由rvalid & rready结束，但data_req（1）的时候可能axi上正好有数据到达，rvalid & rready (1)，所以加个限制，表示data_req的时候绝不可能当前的request就已经完成了。 // // req_busy : ___---_ // // data_req : __-____ // rvalid & rready : _____-_ wire req_busy; wire req_busy_nxt; // ((rvalid & rready) & ~data_req) means (rvalid & rready) should...
-
要设计个core到memory的接口
core到memory的接口要好，这个接口可以是由cache收，也可以是没cache时axi_interface收。 现在cpu7b里还是chiplab里原来的接口样式。 比如， inst_req inst_addr inst_valid inst_rdata data_req data_addr data_wr data_data_ok 现在只用到了简单的几个，能把数据读写出来就行，出错处理的还都没用上。 chiplab的这个接口也是后面改了的。 所以要参考别的代码，自己把这个接口定下来。 现在的想法是 inst_req inst_addr data_req data_addr都是只给一个pulse，由axi_interface负责保存。 给回的inst_valid inst_rdata data_data_ok data_rdata也都只给1一个cycle的pulse，由core保存。 是不是要有个valid ready的机制？