新たに、スタックマシンと呼ばれる方式の、新規CPUコアを設計している所です。
本HPにて、Cmod A7ボード(FPGA)を使って開発しているオリジナル16ビットCPUコアMoscoviumは汎用レジスタを使って処理を進めるCPUなので、汎用レジスタマシンと呼ばれます。スタックマシンは汎用レジスタマシンとは異なる考え方に基づくCPU方式です。
最終号では、コンパイル(論理合成・配置配線)して論理規模を確かめたり、STAによるタイミング検証結果を精査した後、Shrike-LiteのFPGAへ書き込んで、実動作を確認して行きます。
Go Configureを使い、SamariumによるLチカ回路をコンパイル(論理合成・配置配線)して見た結果を以下に示します。
コンパイル結果：
LUT数としては613LUT(最大1,120LUT)、使用率約54.73%でしたので、まだ余裕がありますね。
と、思いきや、ほんの少し論理を追加すると、配置配線がエラーで停止してしまいます。エラーの内容は、「素子が足りない」とのこと。どういう訳だろう？ちょっと感覚と合わない……。
改めて上図の結果を見てみると、LUTは使用率54.73%と余裕があるのですが、CLBの使用率99.29%と、ほぼ使い切っています。つまり、「CLBが足りない」って事らしいです。CLBって何だ？LUTとの関係は？？
SLG47910のデータシートによると、CLB(Configurable Logic Block)の中に、8個のLUTが内蔵されている様です(下図)。
つまり、LUTペアの活用率が鍵、なのですが、どうも、このLUTペアが使い切れていない様に思えます。Samariumの論理合成・配置配線結果を見返してみると、LUTペアの活用率は僅か約55.1%(≒613LUT÷(139CLB×8LUT))と、低い値に留まっています。LUTペアの活用率が半分強ですから、つまり、ペアになったLUTの片方しか使えていない！
この結果だけ見ると、SLG47910には1,120LUTなんて性能は無くて、実力的には140CLB×8LUT×約55%≒約616LUT相当だとしか見えません。
そのくらいの、絶妙な境界線を跨いでいますねぇ……。それ故に少し残念です。スペックが先行して実力が伴っていない、ガッカリ製品の典型例ではありませんか。もう少しLUTペアの活用率を上げられなかったのだろうか？？(メーカの実力不足？)
論理規模がギリギリの線である事は、ひとまず棚に上げて先に進みます。シミュレーション検証が合格し、論理合成・配置配線、STAもメットと、ここまで来たらもう一息です。Shrike-Liteに書き込んで動かしてみたいと思います。
こちらの実験手順で、FPGAへ書き込むビットストリームデータを、前節でコンパイルしたデータに差し替えてみました。
アレっ？おかしいゾ。動かない〜！
何でだ？これまで、中華FPGA → Cmod A7ボード(FPGA)と使ってきた経験上、シミュレーションが動いてSTAがメットしていれば、実機(FPGA)でもシミュレーション通りに動作してきました。何故動かないのだろう？
常日頃、「一番信用できないのは自分自身」だと思っているので、どこか論理設計が間違っているのだと、しばらく悩んで嵌まってしまいました。
色々手を尽くしてデバッグして見たのですが、どうも、現象が不安定で原因がつかめません。しかも、論理合成・配置配線の所で指摘した通り、論理規模的にギリギリ載っている状態なので、デバッグ用に少し論理をいじるとCLB数不足のエラーが発生してしまい、デバッグも捗りません。
少し違う角度から検証してみよう。そう思い立って、慣れ親しんだCmod A7ボード(FPGA)へ、SamariumのRTLを持ち込みました。全てRTLなので、ほぼそのままCmod A7ボード(下図)のVivadoに移植できました。
Cmod A7ボードに書き込んで動かした結果が以下動画です。
動くじゃんか！
ああ、Shrike-LiteのFPGAチップ、SLG47910または、そのツールGo Configureのバグ🪳なんですね。動かなかったのは、筆者の設計技術の性では無かったと証明されました。
あまりFPGAメーカとして名を聞かない三流FPGAメーカだったので、正直、懸念は持っていました……。それにしても、高々600LUT程度の小規模論理回路も、まともに動かせないとは、中華FPGAを使っていた時にも遭遇しなかった酷い状況です。
中華FPGAのサポートに嫌気がさして、老舗のXilinx(Cmod A7ボード)に乗り換えた経験を経て来たというのに、またしても三流FPGAメーカにダマされて嵌まってしまいました。お恥ずかしい。
年寄りが新しい物に飛びついても、ろくなことになりませんねぇ……。
図らずも、Shrike-LiteとCmod A7ボードの両方で、同じ論理回路(RTL)をコンパイル(論理合成・配置配線)する事になったところで、良い機会ですので両者の結果を比較しておきましょう。
ですので、
これを踏まえて、コンパイル結果を以下表で比較してみます。
| ボード | FPGA | LUT数 | FF数 | CLB数 | 備考 |
| Shrike-Lite | SLG47910 | 613 | 96 | 139 | 5入力LUT |
| Cmod A7ボード | XC7A35T | 346 | 100 | − | 6入力LUT |
上表の結果では、Cmod A7ボードの346LUT6≒Shrike-Liteの613LUT5×56%だと解ります(※)。さすがは、Xilinx Artix-7 FPGAと言ったところ。三流FPGAメーカとは格が違います。
当初からCmod A7ボードのLUT数を念頭に検討してきたので、CPUの論理規模346LUTは、目標とした「500LUT未満」に関して余裕で達成しています。考え抜けていたのはLUT6とLUT5の実力差でした。これほどの差が付くとは……。
※Xilinxのデータシートによると、「LUT6≒1.6×LUT5程度(論理規模)」との記載があります。LUT数としては逆数なので、1÷1.6＝62.5%ですから、上表の結果(約56%)と一致していると考えて良いでしょう。Xilinxは、看板にも偽り無しです。
それ以前に、三流FPGAメーカのSLG47910は、ちゃんとRTL通りに動く回路を実装しなさいよ。それができないFPGAは、単なるごみです。
予定外でしたが、Vivadoでのコンパイル結果が得られたので、他のオリジナルCPUコアとの論理規模も比較しておきたいと思います(下表)。
| CPUコア |
データパス ビット幅 |
LUT数 (論理規模) |
F/F数 |
DSP(乗算) マクロ数 |
備考 |
| Nihonium | 32ビット | 5,400 | 950 | 4 | 32ビット符号付乗算／除算 |
| Moscovium | 16ビット | 2,900 | 650 | 1 | 16ビット符号付乗算 |
| Tennessine | 8ビット | 1,300 | 220 | 1 | 8ビット符号付乗算 |
| Samarium | 16ビット | 440 | 84 | 0 | スタックサイズ16段 |
前節の結果は、Samarium＋組み合わせ論理ROMのコンパイル結果でしたので、CPU以外の論理も含んでいます。逆に、未使用論理が最適化されて削除されている可能性もあります。上表のデータはCPUコア単体でコンパイルした結果ですので、その様な影響が排除されています。
結果は一目瞭然ですね。文字通り「(LUT数／FF数の)桁が違う」という結果ですから。手持ちの最小CPUコアであったTennessineと比べてもLUT数で1/3程に収まっています。こちらで取り上げた周辺I/Oユニットの論理規模と並べても、「少し大きいかな？」くらいで、あまり違和感のないサイズではありませんか？
「小さいことが正義」として設計してきたSamariumの真価が立証されました。
CPUを設計すると、ついつい、「あんな機能も欲しい」「こんな機能もあったら良いな」「こうしたら少し速くなる」等と欲が出て、気が付くと論理規模が膨れているのです。Samariumは、その様な欲求を抑えて、「小さいことが正義」という旗印の下、小さく仕上げることに神経を使いました。成果が出たことは、素直に喜ばしいと思います。
「Shrike-Lite搭載FPGA(SLG47910)のバグの為RTL記述通りに動作しない」という前節までの結論を出した後も諦め切れず、Shrike-Liteで色々試していたところ、何と！動きました……。その様子を以下動画でご確認ください。
ダメ元で、スタックサイズを16段→64段に増やしてみたところ動いたのです。論理規模もギリギリ載っている状態だったし、ずっと「論理が大き過ぎて動作しないのか？」と、疑ってデバッグしていました。ですから、逆にスタックサイズを大きくしたら動くなんて全くの想定外だったのです。
スタックサイズ設定と、動作検証結果：
| スタックサイズ | 動作状況 | 備考 |
| 8段 | 動作せず | |
| 16段 | 動作せず | 今までシミュレーションやデバッグに使ってきた設定値。 |
| 32段 | 動作せず | |
| 48段 | 動作を確認 | |
| 64段 | 動作を確認 | 上動画撮影時の設定値。 |
| 96段 | 動作を確認 | |
| 128段 | 素子不足エラー | ここまで大きくすると、CLB不足。 |
ギリギリだった素子数ですが、分散RAMで実装されるスタック回路に於いてはLUTペアが効率良く使えている様で、96段まで増やしても「素子不足エラー」は発生しませんでした。
別角度からも、当方のRTLや設計が正しい事が補強されましたネ。スタックの段数を変えただけで動いたり、動かなかったりするのは、おかしいでしょう？何故なら、シミュレーションでも、Cmod A7ボードでも、16段スタックで正常動作しているのですから。
正しくないのは、いずれも三流FPGAメーカ製の、SLG47910(FPGAチップ)か、あるいはGo Configure(開発環境)の方です！
どちらにしても、こんな不安定な動作では困ります。だって、
「RTLや設計が正しくても、Shrike-LiteのFPGAに書き込んだら動かない場合がある」
事は確かなのですから。動かなかった時に「FPGAの性で動かない」可能性を疑わなくてはならない、なんて、最低です。
悪あがきの末に、めでたく動作は確認できましたが、結局、結論は変わりませんでしたね(ごみはごみ、三流は所詮三流)。
Shrike-LiteのFPGAは、場合によっては正しいRTLを書き込んでも動作しない可能性のある、「ごみ」だと判りました。折角購入したので、ごみはごみなりに活用方法を考えなくてはなりません(でも、もう萎えたな、暫く塩漬け)……。
Samariumに関しては、例え、Shrike-LiteのFPGAで安定して動作したとしてもCLB数不足の為、肝心な周辺I/Oユニットを搭載する余地が無く、Shrike-Liteでの活用は厳しいです。改めてCmod A7ボードで活用する手立てを考えなくてはならない様です。
何でしょうね。わざわざ、新規CPUコアを起こすというリスクを取って、時間をかけて設計したのに、何一つ物になりませんでした……。焦燥感が酷いです。「スタックマシンを作る」テーマは、これにて完遂となります。
