[過去ﾛｸﾞ]
Qiita 2 - キータぞ、来たぞ、キータだぞー (1002ﾚｽ)
Qiita 2 - キータぞ、来たぞ、キータだぞー http://mevius.5ch.net/test/read.cgi/tech/1658762410/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
656: デフォルトの名無しさん [] 2023/01/28(土) 14:54:23.83 ID:8J7/cVfu ALU Controlを実装していてパタヘネRISC-V版の誤りに気づいた件 https://qiita.com/zacky1972/items/160d9043c5cec5d083cf > Appendix C: Mapping Control to Hardware の C.2 Implementing Combinational Control Units の記載のFigure C.2.3が誤っていました．どのように訂正するかについては，前述のSystemVerilogのソースコードから察してください． どう間違っててどう書くのが正しいみたいな具体的な指摘をしないのは 墓穴掘りたくないからかな http://mevius.5ch.net/test/read.cgi/tech/1658762410/656
657: デフォルトの名無しさん [sage] 2023/01/29(日) 13:13:36.42 ID:V8aF3j6G >>656 パタヘネのFigure C2.3のOperation0(alu_ctl[0])をそのままVerilogで書くと alu_ctl[0] = (alu_op[1] & (f[3] & f[0])); だけど alu_ctl[0] = (alu_op[1] & (f[1] & ~f[0])); が正しいと言いたいらしい でも、Figure C.2.1の4行目は 1,x,x,x,0,0,1,0 (alu_op[1],alu_op[0],f[5],f[4],f[3],f[2],f[1],f[0]) => 0110 だから最下位bitのalu_ctl[0]は0になるんだけど、 そのコードだとalu_op[1]=1,f[1]=1,f[0]=0だから~f[0]=1になり、 alu_ctl[0]が1 & (1 & 1) => 1になるからおかしいと思う そもそも、パタヘネのFigure C.2.xに出てくるfはなんだかよくわからない f[2:0]はいわゆるFunct3(inst[14:12]で、f[3]はFunct7の6bit目(減算命令とかに 使われる,inst[30])、そのコードでも f = {inst[30], inst[14:12]}; にしているけど、全く使ってないf[5],f[4]は何のためのあるの? http://mevius.5ch.net/test/read.cgi/tech/1658762410/657
659: デフォルトの名無しさん [sage] 2023/01/29(日) 14:03:18.90 ID:V8aF3j6G >>658 一応補足 > だとするとなんでinst[30]がいらないって発想になるんだろう? inst[30]はf[3]ね alu_ctl[0]が加算化減算化を区別する信号線ならinst[30]=f[3]がないといけないのに >>656のコードはf[3]を取り除くコードにしていて、こんな書き換えようと思うこと自体 理解できないという意味 http://mevius.5ch.net/test/read.cgi/tech/1658762410/659
663: デフォルトの名無しさん [sage] 2023/01/30(月) 20:54:31.60 ID:r3bAOQsl >>660 あ、見落としていた パタヘネのFigure C.2.3をVerilogで書くとOperation2(alu_ctl[2])は alu_ctl[2] = (alu_op[0] | (alu_op[1] & f[1])); になっているのを、>>656のコードは alu_ctl[2] = (alu_op[0] | (alu_op[1] & f[3])); に修正している alu_ctl[0]と同様にFigure C.2.1の4行目の 1,x,x,x,0,0,1,0 (alu_op[1],alu_op[0],f[5],f[4],f[3],f[2],f[1],f[0]) => 0110 に従うとalu_ctl[2]は1 修正コードだとalu_op[0]=1,alu_op[1]=1,f[3]=0のときは (1 | (1 & 0)) => (1 | 0) => 1で正しいけど alu_op[0]=0,alu_op[1]=1,f[3]=0のときは (0 | (1 & 0)) => (0 | 0) => 0になるからFigure C.2.1と食い違う Operation1(alu_ctl[1])とOperation3(alu_ctl[3])はパタヘネと同じ 少なくともパタヘネのFigure C.2.1とFigure C.2.3は正しい対応関係だが >>656のコードはFigure C.2.1とは食い違っている http://mevius.5ch.net/test/read.cgi/tech/1658762410/663
665: デフォルトの名無しさん [sage] 2023/01/30(月) 21:58:41.09 ID:r3bAOQsl 間違っているかもしれないけど、なんとなくわかった気がする RISC-Vの条件分岐命令はPC相対で、rs1とrs2間で条件判定を行い、 PC+即値で分岐先アドレスを計算して分岐時に次のPCとしてセットする パタヘネの設計では、条件判定をALUで行い、分岐先アドレスの計算は ALUとは別の加算器を用意して使用する 普通の設計だと、分岐命令もロードストア命令もALUでアドレス計算して、 条件判定回路はALUとは別に用意する 後者を想定してALUを設計するならパタへネのALUの仕様とは噛み合わない >>656のリンク先はパタヘネが後者のALUだと勘違いしたんじゃないかな http://mevius.5ch.net/test/read.cgi/tech/1658762410/665
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.028s