これだけ技術が進んでも、意外と大変な作業となるのが「移植」という仕事です。
開発当初から、「これと、これと、この環境で動作するマルチプラットフォーム開発を行う」等と決めて進めた場合なら、まだ良いのかもしれません。しかし、一旦開発が終了した後で、何らかのソフトウェアを別な環境(別なOS等)に移植するのは、大変骨が折れます。
ハードウェア開発(RTL)では、どうなのでしょうか？
今まで、中華製のFPGAボード(Primerボード)を使って開発していたオリジナル16ビットCPUコアMoscoviumの、新規購入したFPGAボード(Cmod A7ボード)への移植を通して確認して行こうと思います。
ソフトウェア開発の代表としてC言語、ハードウェア開発の代表としてVerilog-HDLを取り上げ、移植に際しての課題や問題点を明らかにしていこうと思います。
C言語は、ANSI(American National Standards Institute)と言う組織が標準仕様を規定しており、多くのC言語処理系は、この規格に準拠しています。
Verilog-HDLは、IEEE(Institute of Electrical and Electronics Engineers)等によって標準化されている様です。
お陰で、ある処理系から別な処理系へプログラムコードを持って行った時、言語仕様の相違などからエラーが発生するようなケースは少なくなっています。
ただ、C言語の場合は以下の様な点によって、「移植」を困難にしています。
その点Verilog-HDLでは新たな型を作り出すことはできないし、ライブラリに相当するコードに依存しなくても、ある程度の回路記述はできるので、C言語などに比べて、ずっと移植しやすい環境にあると考えられます。
C言語の移植で障害となるのは、標準化の進んでいないライブラリなどへの対応だという事を前節で述べました。もう少し詳しく見て行くと以下の様になります。
Verilog-HDLに於いて、この様なライブラリが使われることが全くないか？と言うと、そうでもありません。ハードウェア開発に於いてはハードマクロやIPマクロなどが相当します。
C言語の移植ではOSが変わるとライブラリが変わるので移植は困難となるのですが、Verilog-HDLではFPGAチップが変わることで、提供されるハードマクロの仕様が変わるので、この点に留意する必要があります。
ハードマクロやIPマクロの例は以下の通りです。
上に挙げたマクロはC言語のクラスライブラリ等と異なり、極めて基本的な機能しか持たないマクロであるため、インターフェイス仕様は限定されており、FPGAチップが変わったとしても、C言語でOSが変わった場合ほどのインパクトはありません。ちょっとした小修整で対応可能なケースが多いと思われます。
そう言えば、VivadoのIP Catalogには、AXI(Advanced eXtensible Interface)バスでアクセスするIPマクロが揃っていました。AXIバスは、ARM社が規定したバス仕様です。
この様なIPマクロには、アナログ回路を含まない純粋な論理回路が多いです。IPマクロを使うのは便利なのですが、それに頼りすぎてしまうと、C言語と同様、異なるFPGAチップへの移植に苦労する事になるので、頭に叩き込んでおきましょう。
先々の展開までよく考えた上で、ハードマクロやIPマクロを使った方が良いと思います。
※Moscoviumシリーズは独自のメモリバス仕様で統一してあるので、現状、AXIバス仕様のIPマクロを使う予定はありません。
では次節以降、具体的にMoscoviumマイコンの移植を例に確認して行きましょう。
まずは、Moscoviumを最初に設計し始めた時の最小構成マイコンである、MCOC115MN0408を移植してみたいと思います。
以下に、移植すべきI/Oユニットの一覧を示します(上図で、MCOC115MN0408欄に〇の付いたユニット)。ちなみに、型名の命名規則はこちらです。
移植すべきI/Oユニット一覧：
今回移植しようとしている上述のI/Oユニットで使用しているハードマクロは、以下に示すメモリ系のハードマクロだけでした。
使用していたハードマクロ：
一応、移植と言う状況を想定して、当初より、ハードマクロをRTLモジュール内に埋め込むのではなく、わざわざ最上位のインターフェイスまで引き出して接続する方法を取っていました。移植の際に問題となるであろう、ハードマクロをモジュールの外部に接続することで、RTLの移植性を高める狙いです(下図は、その一例)。
上図は非同期シリアル通信ユニットUART8N1のブロック図です。薄緑色の箱fifoがハードマクロです。水色破線がハードマクロとRTLの境界線で、実際にVerilog-HDLのモジュール(module)の外側に引き出す形でRTLを記述してあります。
通常のROMマクロ／RAMマクロに関しても同様な対応を取っています。
TD IDE(Primerボード)のFIFOマクロと、Vivado(Cmod A7ボード)のメモリ系ハードマクロのI/F仕様を見比べたところ、端子名などは全く異なっているものの、I/F信号のタイミングや動作については、ほぼ同じであることが確認できています。
これらメモリ系ハードマクロの移植作業は、全く問題なさそうです。
ただ、FIFOマクロのサイズがね……、ちょっと失敗だったかも？実は開発当初から、ずっと感じていました。
精々、数100kbpsの通信速度でしか使わないUARTの受信FIFOに、1Kバイトと言うサイズは大きすぎで、本当は数10バイトあったら十分でした。開発当時、TD IDEで使用可能な9KビットRAMマクロ1個を無駄なく使おうとすると、1Kバイト単位でFIFOサイズを作成することになってしまったのが経緯です。
※そもそも、TD IDEのIP Generatorでは、FIFOマクロの最小サイズが512バイトでした。512バイトに設定しても、9KビットRAMマクロ1個を占有使用するため、未使用の512バイトは無駄になってしまいます。この様な無駄を排するため、止むを得ず1Kバイトと言う巨大なFIFOサイズを選択しました。
Vivado(Artix-7ファミリXC7A35T)では更に悲惨で、用意されているのが18KビットRAMマクロなので、これを無駄なく使用しようとした場合、FIFOサイズは2Kバイト単位で増減させることになってしまいます。
移植に際して、「そのまま使える」けど、「大きな無駄」が生じるのです。
「無駄」というなら、そもそも、数10バイトで足りる、UARTのFIFOにRAMマクロを1個占有して使ってしまう事が、もう無駄な訳です。
思えば、FIFOくらいRTLで設計しておけば良かったのかな？
FIFOは動作が結構複雑で、RTL記述も動作検証も手間がかかるため、今まで、楽に使えてしまうFIFOマクロを使ってしまっていました。
まあ、仕方ないですね。ひとまず今まで通り、1KバイトFIFOのまま、移植しておこうと思います。手が空いたところで、もっと小さなFIFOをRTLで手作りすることを検討してみます。
C言語などのソフトウェア設計に於けるライブラリに相当するハードマクロですが、今回の移植で対応する必要があるのは、ROMマクロ、RAMマクロ、FIFOマクロの3種類でした。
TD IDE(Primerボード)とVivado(Cmod A7ボード)のハードマクロに関して比較検討した結果、ハードマクロ名や信号名、タイミング、論理等に多少の違いはあるものの、基本的な制御信号仕様に大きな差は無く、接続を調整するだけでそのまま使えそうだと判りました。
いずれも非常に基本的なハードマクロなので、独自性を発揮する機会が無かったのでしょう。Good！
Primerボードと、Cmod A7ボードでは、用意されたRAMマクロのサイズに以下の様な違いは、あります。
よく、メモリの容量で「○○ビット」という表現を見かけます。1バイト＝8ビットなので、8で割り算すると、バイト数に換算できます。18KビットRAMマクロの場合、1個当たり18Kビット÷8＝2.25Kバイトの容量となります。○○の部分は大抵の場合2冪数なのですが、RAMマクロは何故、非2冪数のビットサイズになっているのでしょうか？
これには宇宙線🌠が関係しています。
※宇宙線：宇宙から地球へ降り注いでいる、中性子線など放射線の総称。
FPGAのRAMマクロは、S-RAMです。本HPでは過去に、D-RAMと言う種類のメモリも扱ったことが有りました。
最初に述べた通り、FPGAチップのRAMマクロはS-RAMなので、電源を切らない限り、データが消えたり、書き換わったりする事は無かったのです(過去形)。
プロセス(LSI)の微細化によって、RAMセルおよび、RAMセルが保持する電荷量(電子数)が小さくなり、1発の宇宙線が衝突すると、記憶していたデータがひっくり返ってしまう(反転する)事があります(現在形)。これをソフトエラーと呼びます。データの反転は、宇宙線が衝突した一瞬だけではなく、そのまま記憶データが書き換わって、静的に保持されてしまいます。
ただし、RAMセル(記憶素子)が物理的破壊に至るわけではないので、動作がおかしくなって「なんか変だな〜」と、リセットをかけると元通り正常動作します。
※素子が物理的(ハード)に破壊されるわけではなく、記憶したデータが反転するだけなので、ソフトエラーと言う表現になっているのだと思われます。
微細化によって見えてきた現象なので、RAMセルが物理的に大きかった昔のプロセス(LSI)では、宇宙線の衝突位で電荷がひっくり返る事は無く、全く問題ありませんでした。
たまたま宇宙線がRAMセルを直撃して、記憶データが反転してしまうソフトエラーの発生は、確率としては小さいです。しかし、ソフトエラーが起きた時の影響の大きさを勘案した上で、エラー検出やエラー訂正等を施すことがあります。
例えば、Primerボードの9KビットRAMマクロは、8ビットデータ＋1ビットパリティでエラー検出して使う事を意図した構成なのです。同様に、Cmod A7ボードの36KビットRAMは、8ビットデータ毎に8ビットデータ＋1ビットパリティで使用し、合わせて32ビットデータ＋4ビットパリティで使用することを意図しています。
これが、切りの良い2冪数のRAMマクロになっていない理由です。
※パリティを使わず、32ビット×1Kワード＝4KバイトRAMとして使う事は出来ますが、この場合、4ビット×1Kワード＝512バイト分のRAMは利用できず、無駄になります。つまり、1バイト(8ビット)区切りのデータアクセスを前提とする場合、36KビットRAMマクロ1個で実現できるRAMサイズは、実質4Kバイトです。同様に、18KビットRAMマクロ1個では、実質2Kバイトとなります。
仮に、パリティビットを追加して使ったとしても、エラー「検出」しかできないので、RAMを読み出した時、「エラーが起きたよ」と例外を発生させるくらいしか使い道がなく、所謂、フェイルセーフ的な使い方が関の山ではあります。
エラー「訂正」までやっておくと、エラーを検出すると同時に訂正もできるので、そのまま処理を継続可能です。その代わり、エラー訂正にはエラー検出よりも多くの冗長ビットが必要となって、その分多くのRAMセルが必要となり、費用が増加します。
システムに要求される信頼度や、費用などを考慮して設計することになります。
ムーアの法則が崩れたとは言えど、このまま微細化が進んで行けば、RAMセルだけでなく、F/Fさえもソフトエラーを起こすようになりかねません。全F/Fが信頼できなくなったら、集積回路の動作なんて一切保証できませんけど……？
では、「ソフトエラーが起きる確率ってどのくらい？」って事ですよね。これをSER(Soft Error Rate)と呼びます。最近の気の利いた半導体メーカは、加速試験で測定したデータを公開していますので、検索してみましょう。
Xilinx製品のSERを検索する(別ウインドウが開きます)
見つかりましたか？
Cmod A7ボードに搭載されているXC7A35TというFPGAチップは、Artix-7ファミリのチップですので、この製品ファミリのRAMマクロ(BRAM)に関する測定結果を見てみると、41〜72[FIT/Mビット]という数値が拾えました。以下、最もコンサバに、72[FIT/Mビット]のSERを使って議論を進めます。
「人生100年時代」と言っても、高々100年です。901年も生きられませんから、まあ、生きている間にソフトエラーと遭遇する確率は相当に低いです。個人で使用する限り、問題ないと思って良いでしょう。
ですが、「な〜んだ、脅かし過ぎ！」って思った方は甘いです。
例えば、自動車などの量産品に搭載した場合、仮に100万台の自動車に採用されたら、出荷した100万台の内、いずれか一台にソフトエラーが発生するまでの時間は、901年÷100万台≒7.9時間にまで短縮されてしまいます。量産適応する場合は要注意な訳です。
※ソフトエラーによる誤動作は、1回発生したら次はずっと先まで起きないので、仮にクレームが上がっても、誤動作を再現することができないためです。万一、重大な事故が発生した場合でも、事故車を調査した結果、「欠陥・故障は無かった」という調査報告書が上がるだけです。怖いですねぇ〜。
しかし、確かなことは、確率(72[FIT/Mビット])によって、必ずソフトエラーは起きる、と言う事です。
こういう諸々を含めて、自動車の制御中枢にかかわるハンドル、アクセル、ブレーキなどは、機械式操作を貫いてきました。つまり、電子回路を経由しない制御です。最近では、ソフトエラーを含めた誤動作対策を何重にも施した上で、電子制御に置き換わってきています。「アクセルとブレーキの踏み間違いによる急発進抑制」等は、電子制御の賜物ですから。
ちなみに、自動運転レベル5(完全運転自動化)なんて、どうなってしまうのでしょうか？！
ところで、自動車1台に何個のマイコンが使われているかご存知ですか？JEITAによると、普通車で30個、高級車では80個に登るそうです。
車に搭載された全マイコンのRAM容量を合計して計算し直してみると、出荷した自動車のいずれか一台の、搭載されたマイコン何れか1個のRAMの内、いずれか1ビットにソフトエラーが起きるまでの時間は、7.9時間より遥かに短いはずですよ……。
確率論なので、ご自分の車に(宇宙線が)当たらないことを願いながら乗車して下さいね。くわばら、くわばら。
※脅かしっぱなしは良くないので、冷静になれる様に追記しておきます。1個のLSIにソフトエラーが発生する確率は、本節で計算した通り、数100年オーダの確率です。そうそう発生する物ではありません。設計者側も、ソフトエラー発生の可能性を念頭に、安全対策を施しているはずです。何でもかんでもソフトエラーのせいにしたり、過度に恐れる必要はありません＼（１＾−＾）／。
PrimerボードからCmod A7ボードへの移植の第一回と言う事でしたが、少し脱線してしまいました……。次回、具体的な対応を進めて行こうと思います。
