公開日：2021/03/06

15th Season

#15-5　RISC-Vを試す

　オリジナル16ビットCPUコアMoscoviumが完成目前ですが、ここで比較対象としてのRISC-Vを試してみようと思います。ここら辺の連載をご覧になっている方にとっては、RISC-Vにも興味があるでしょうから、良い機会だと思います。

　今回、後半でオリジナルのMoscoviumコアも完成させますので、そちらもお見逃しなく。

E203コアをコンパイルしてみる

　良い呼び方が思いつかないので、「コンパイル」と称していますが、Verilog-HDLをFPGAボードに書き込むための処理を指しています。正しい表現としては、「論理合成および配置配線」です。長ったらしいので、本HPではしばしばコンパイルと呼んでしまいます。

　最初にFPGAボードを導入した時に長所として挙げた特徴として、「RISC-Vが移植されている」ことを上げました。SipeedのHPから、「MORE ⇒ GitHub repo」と辿ると、「Tang_E203_Mini」という項目が有ります。これが、FPGAボード(Sipeed Lichee Tang Primer)に移植されたRISC-VのE203と呼ばれるコアです。

　調べてみると、RISC-V E203コアは：

• 32ビットRISC-Vコア
• 乗算器：　有り
• 除算器：　有り
• ITCM／DTCM：　有り
• ITCM；Instruction Tightly Coupled Memory
• DTCM；Data Tightly Coupled Memory
• 所謂キャッシュメモリとは異なる、「高速にアクセス可能なRAM」みたいです。

と、かなりリッチなCPUコアの様ですね。

プロジェクトをダウンロード(export)してコンパイル

　まずは、Tang_E203_Miniの下に格納された全ファイルをローカルPCにダウンロードしてください。これには、Cygwinのsvnコマンドを使います。

　　実験サンプル：【 】内はCygwinシェルウインドウからの実行コマンド
　　【svn export https://github.com/Lichee-Pi/Tang_E203_Mini/trunk/】

　これで、GitHub上Tang_E203_Miniディレクトリ下の全ファイルがローカルPCにダウンロードできました。

※Cygwinで「svnコマンドが見つからない」エラーとなった場合は、こちらを参照して「svn」で検索し、適切なコマンドをインストールしてください。

　Cygwinでの作業はこれで終了です。今ダウンロードしたディレクトリ「trunk\」が、Windows上にできているので、TD IDEを使って、以下のファイルを開いてください。

　　trunk\project\e203egmini_new.al

　TD IDEのプロジェクトになっているので、もうこれだけでOKです。TD IDEの「Processメニュー ⇒ Run」でコンパイル(論理合成・配置配線)が実行できます。移植されているだけあって、かなり簡単です。何のエラーもなく、FPGAボードに書き込み可能なe203egmini.bitファイルが完成してしまいました。
　ただし、コンパイルはとても時間がかかります。手持ちの環境(Core-i3-8100 @3.60GHz)では、20分以上かかりました。

　「Physical Summary」を確認したところ、LUT数15k個、F/F数6.6k個と、かなり大きなコアです。最大19k LUTのFPGAボードに何とか乗っかっている、感じです。「Timing Summary」等と含めて以下にまとめておきます。

• コンパイル時間：　約21分
• LUT数：　15,002個　(最大19,600個)
• F/F数：　6,642個　(最大19,600個)
• 9KビットRAMマクロ数：　64個　(最大64個)
• 32KビットRAMマクロ数：　16個　(最大16個)
• PLLマクロ数：　1個　(最大4個)
• タイミング解析(STA)結果：
• clk_16M
• end pointなし。
• 16MHzクロックを使っていないのか、何か制約を当て損ねているのか？詳細不明。
• clk_8388
• Setup Slack：　115.869ns　(MET)
• Hold Slack：　0.663ns　(MET)
• 8.388MHzクロックみたい。ずいぶんと大きなSlackが出ている。
• Setup Slack≒0ns辺りのギリギリを狙ったと仮定すると、150MHz以上は動いている計算。
• slowclk
• Setup Slack：　30491.161ns　(MET)
• Hold Slack：　0.368ns　(MET)
• 32.768kHz辺りを狙った遅いクロック。

　タイミング解析結果については、他人の作ったプロジェクトをそのまま実行してみただけなので、本当にちゃんとCPU(RISC-Vコア)にタイミング制約がかかっているのかどうか、わかりませんｍ（１＿＿）ｍ。このデザインを使う方は、よく吟味してみてください。

E203コア中身の確認

　Tang_E203_Miniプロジェクトを開いたTD IDEで、モジュール階層を確認してみました(下図、抜粋)。



　階層を辿ってみたところ、gpio，uart，pwm，i2c等のモジュール名も見えました。どうやら、単体のRISC-V CPUコアではなくて、SOC(System On Chip)のプロジェクトになっているみたいです。なるほど、この論理構成なら15k LUTとか、コンパイルに20分とか言う規模も納得です。

使える？

　Season 15で作ろうとしているマイコン(MCU)に匹敵するどころか、はるかに超えるリッチなSOCが既に完成しているみたいです。
　これが使えるか？と言うと、使いこなすためには、もう一歩準備が必要となります。このままでは、コンパイルして出来上がったe203egmini.bitファイルをFPGAボードに書き込んでも、動かせません。

　RISC-V上で動作させるためのソフトウェアを、FPGAボード上のデザインにダウンロードするツールが別途必要なのです。

　　RISC-V＋JTAGツールで検索(別ウインドウが開きます)

　残念ながら、アドバイスできるのはここまでです。具体的に何という名前のどんなツール(ハードウェア)がRISC-Vソフトウェアのデバッグ用に使用可能なのか知りませんし、Windows用のツールなのか？Linuxでなければ動かないのか？も知りません。
　ここから先は、興味ある方がご自身で調査して入手してください。

　さらに、C言語で開発したい場合には、GCCのRISC-Vツールチェーンを入手してビルドしてください。これも必要な方の各自対応となります。


　と、言う状態で、手元にはJTAGデバッガ(ハードウェア)も無いので、RISC-Vではこれ以上先に進めないことが判りました。やはり、自分でCPU作って使うのが一番手っ取り早くて確実な様です(筆者にとっては（１＾＾；）、です)。

　よし、Moscoviumを完成させよう。

Moscoviumを完成させよう

　前回、以下CPUブロック図に従って、MEM，RGF，ALU，FCHブロックの基本設計を終了しました。



　残るは大物、制御CTLブロックです。
　何しろ、前回基本設計を終了したMEM，RGF，ALU，FCHブロックは単なる従属モジュールで、外部回路からの指示(コマンド)に従って言われた通りに動くだけの回路だったのですが、CTLブロックはその「指示を出す側」のモジュールなので、ちょいと格が違います。

　基本的にはステートマシンとなるので、「#15-2　論理回路を設計する」で作成した、Excel表からVerilog-HDLに変換するスクリプト(tab2v.olv)を使います。
　作成したExcel表は以下の様な感じです。



　ほんの一部抜粋です。casexコマンド部分の入出力信号数とか、テーブルの行数とかに着目して見てください。
　テーブルの入・出力信号について使い道を簡単に説明しておきます。

• casex
• ir_opc15
• ir_opc_ribr[3:0]
• ir_opc_rr[4:0]
• ir_opc_r[2:0]
• ir_opc_np[10:0]
• 命令レジスタir[15:0]のフィールド。こちらで示したフィールドに対応。
• これらの値を使って命令コードを復号する。
• sr_n
• sr_c
• sr_v
• sr_z
• RGFブロック内ステータスレジスタsrからもらった演算フラグ(N，C，V，Z)信号。
• 分岐命令の条件判定で使う。
• sr_nv
• 符号付大小比較(bge命令、blt命令)で使う信号：　sr_nv＝sr_n＾sr_v
• mem_brdy
• メモリバスのbrdy信号。
• メモリバスが、CPUの出したコマンドを受け付けたかどうかの判定に使う。
• stat[1:0]
• ステートコード。
• ほとんどの命令は1サイクルで処理が完結するので、ステートS0で回っている。
• 一部、2〜3[サイクル]実行命令のみ、ステートS0→S1→S2と状態が遷移する。
• これだけ見ると、ステート数がほんの数個の小さなステートマシンに見えてしまう。
• しかしある意味、命令コードir[15:0]自体もステートコードの一部なので、そういう意味ではステートコード18ビットほどの巨大なステートマシンを回している事になる。
• output
• dbg_cod[7:0]
• 論理デバッグ時に便利なコード出力。テーブル内の各行にユニークなコードが割り当ててある。
• どこにもつながっていないので、ゲートレベルの最適化で論理は消滅する。
• RTLシミュレーションで、今、CTLブロックがテーブル内のどの行を実行しているのか？この数値をモニタするとわかる。
• stat_nx[1:0]
• 次のサイクルで遷移すべきステートコード。
• clk↑で受けてstat[1:0]となる。
• ff stat[1:0] clk stat_nx[1:0] !rst_n S0
• ctl_fetch
• FCHブロックへの指示で、「フェッチせよ」。
• FCHブロックはctl_fetch＝1の時、命令レジスタirに、読み出した命令コードをラッチする。
• ctl_bcmdr
• ctl_bcmdw
• ctl_bcmdb
• メモリバスのアクセスコマンド出力。
• MEMブロックが受け取って、メモリバスへのコマンドbcmd[2:0]として出力する。
• ctl_acmd[3:0]
• ALUの演算コマンド出力。
• ALUブロックが受け取って、指示された演算を実行する。
• コマンドコードの割り当ては前回確定済み。
• ctl_sela[2:0]
• ctl_sela_rn[2:0]
• RGFブロックに対して、Aバスへ出力すべきレジスタを指示する信号。
• ctl_selb[2:0]
• ctl_selb_rn[2:0]
• RGFブロックに対して、Bバスへ出力すべきレジスタを指示する信号。
• ctl_selc[2:0]
• ctl_selc_rn[2:0]
• RGFブロックに対して、Cバスからラッチすべきレジスタを指示する信号。
• ctl_sr_upd
• RGFブロックに対して、ステータスレジスタsrの演算フラグ(N，C，V，Z)値を、ALUから出力された値に更新することを示す信号。
• ctl_sp_inc
• ctl_sp_dec
• RGFブロックのスタックポインタspをインクリメント(＋2)またはデクリメント(−2)する指示信号。
• スタック操作命令(pushw命令、popw命令など)で使用する。

Moscoviumコアを組上げる

　これですべてのブロックが完成しましたので、最上位モジュールにインスタンスして組み上げました。

• TD IDEのプロジェクトを作る。
• 全てのVerilog-HDLソースファイルを追加する。
• 「Toolsメニュー ⇒ Timing Wizard」で最上位のクロック端子clkに25MHzの制約を追加する。
• 完了。

※プロジェクトの作り方などに関しては、こちらで詳しく解説してあります。


　コンパイル(論理合成・配置配線)してみた結果、以下の様になりました。

• コンパイル時間：　約1分
• LUT数：　1,843個　(最大19,600個)
• F/F数：　575個　(最大19,600個)
• タイミング解析(STA)結果：
• Setup Slack：　9.257ns　(MET)
• Hold Slack：　0.671ns　(MET)
• 25MHzは動きました。クロック周期40nsに対してSlack＝9.257nsなので、20%以上の余裕があります。
• ご参考までに、この時のワーストSlack(クリティカルパス)は、以下のパスでした。
• FCHブロック内命令レジスタir　→
• CTLブロック(復号)　→
• Aバス選択信号　→
• RGFブロックバンク1、Aバス出力　→
• ALUブロック(Vフラグを作っているのは加減算器art、またはバレルシフタsft)　→
• RGFブロックSrレジスタビット5(オーバフロウVフラグ)
• ※配置配線のイタレーションで変わるので、「確認した時はこうだった」と言うエクスキューズ付きです。コンパイルし直すと、異なるパスが見えてくる可能性はあります(団栗の背比べ的なパスが沢山あるため)。

　ちょっと思いの他、論理規模(LUTおよびF/F数)が大きいと感じました。きっと、汎用レジスタバンク(×4組)と、バレルシフタが原因でしょう。TD IDEの論理合成と配置配線は、全階層をフラット化してから実施しているため、階層毎の論理規模を知ることのできないことが残念です。
　`defineマクロによる条件付きコンパイル(`ifdef)で、汎用レジスタバンク数(4バンク→1バンク化)とバレルシフタの有り／無しを切り替えて論理規模をまとめてみました(以下表)。

　思った通り（１＾＾；）。バンク数を減らして、バレルシフタも削除したところ、半分以下の規模まで縮小しました。
　やはり、4バンク＋16ビットフルバレルシフタはやり過ぎなのか？そうなのか（１＠＿＠）💫？

　でも、このまま行きますｏ（１＾ー＾）ｏ、4バンク＋バレルシフタありで。アセンブラによるプログラミングのし易さを前提に考えた仕様ですから。上の情報さえ持っておけば、将来論理規模を縮小して、より小さなFPGAチップに搭載することも可能だということが判るので、今はそれでOK。

　Verilog-HDLソースファイルの行数は以下表の通りです(空行やコメント行も1行でカウントしました、【wc -l *.v】)。

　トータル2,000行に満たない記述量でCPUコアが完成してしまいました。案外簡単でしょう？


　以下ページに、本HPで作ろうとしているマイコンのHDLを公開して行きます。まだCPUだけですが、登録しておきました。

　　


　FPGAなので、自分で好きなように組み上げて、使うことができます。Moscoviumコアはとても小さいCPUコアなので、何なら、2個使い(デュアルコア)で分散処理させても良いし、使い方次第では面白いことが出来ると思います。

後日のアップデート

　ソフトウェアでシフト演算をしたい時、かつ、そのCPUにバレルシフタ(ハードウェア)が搭載されていなくて、1，2，4，8ビットシフト演算命令(例えばLSL，LSL2，LSL4，LSL8)を持っている場合を考えてみました。
　7ビットシフトしたい時は、以下の様になります。

　　LSL　R0
　　LSL2　R0
　　LSL4　R0

　レジスタR0を1＋2＋4ビットシフトしたので、合計で7ビットシフトできました。そうなんですよ、2冪数のシフト演算命令が有れば、その組み合わせで、どんなシフト量でも演算できるんですよね。

　で、ふと考えました(以下図)。ハードウェアで16ビットのフルバレルシフタを作ろうとしています。



　上図左側の様に、Nビット(Moscoviumの場合はN＝16ビット)のフルバレルシフタをハードウェアで作ったのだけど、上図右側の様に、1，2，4，8ビットシフト演算器をカスケードに4個繋げて、各ビット毎に演算した方が、論理規模を縮小できるのではないだろうか？
　こちらで設計時に検討した様に、上図左側のNビットバレルシフタだと、16ビット64 to 1セレクタというお化けになるのだけど、上図右側だと、各シフタ(bsft1，2，4，8)が16ビット2 to 1セレクタで済むので、だいぶ小さいハズ。

　RTLを変更して、コンパイル(論理合成・配置配線)した結果を以下表に示します。

※バレルシフトのオプションしか変えていないのに、F/F数が微妙に増減しているのは、原因不明です（１＠＿＠）。

　上の本文中で示したLUT／F/F数(1843／575個)と比べて、微妙に数が異なっていますが、ちょいちょいRTLの修正をしているからです。多少の差分は無視して、上表で考察を進めます。

• 従来版バレルシフタの論理規模LUT数＝1,946−1,456＝490個ほどと見ることが出来る。
• 改修版バレルシフタでは、LUT数＝1,596−1,456＝140個ほどに減少した(70%減、Good！)。
• 信号の伝搬速度としては、改修版の方が遅くなっていると推察できる。
• ただし、バレルシフタはクリティカルパスではないため、具体的な遅延時間は不明(確かめてない)。
• 少なくとも、fcpu＝24MHzでは、改修版バレルシフタでもタイミングはメットしており、問題なし。

　以上より、Moscovium ver.0.92以降では、改修版バレルシフタを搭載することにしました。