Open-Source-Hardware on ニコ技深セン / Nico-Tech Shenzhen website

BIO：Bao I/Oコプロセッサ（bunniestudioブログ翻訳）

Mon, 01 Jan 0001 00:00:00 +0000

BIOはBaochip-1xに搭載されているI/Oコプロセッサだ。Baochip-1xは僕が設計をした、ほとんどがオープンソースの22nm SoCである。Baochip-1xの背景についてはこちらの記事で詳しく説明しているし、評価ボードはCrowd Supplyで入手できる。

この投稿では、BIOの成り立ちについて話そう。まず参考としてRaspberry Pi PIOを詳細に研究したところから始め、その後BIOのアーキテクチャに深く掘り下げていく。さらに、BIOのプログラミング例を3つ紹介する。うち2つはアセンブリ、1つはC言語だ。BIOの使い方だけに興味があるなら、背景の詳細は飛ばして、記事の後半にある「Design of the BIO」というセクションまでスキップしてもいいし、コード例に直接進んでも構わない。背景I/Oコプロセッサは、I/OタスクをメインCPUコアからオフロードする。メインCPUは何らかのマルチタスク方式を使って複数の優先度を処理しなければならず、それが応答時間の予測不能さにつながる。この予測不能な応答は、クリティカルな応答における望ましくないジッタや遅延として現れる。I/Oタスクにコプロセッサを専任させることで、汎用CPUの柔軟性を維持しながら、専用ハードウェアのステートマシンに迫る決定性を実現できる。

I/Oコプロセッサのよく知られた例が、Raspberry PiのPIOだ。PIOは4つの「プロセッサ」から構成され、それぞれが9命令を持ち、32ワードの命令メモリを備えている。GPIOのサイクル単位での正確な操作を容易にしながら、高い柔軟性を発揮するよう高度に調整されている。例えば、クロック、イン、アウトを備えたSPIの実装は、コンフィギュレーション修飾子と、わずか2つの命令で実現できる。これらはPIOのコンフィギュレーションで利用可能な副作用（コードの自動ラップアラウンドやFIFO管理など）によって「実質的なループ」として実行される： “.side_set 1”, “out pins, 1 side 0 [1]”, “in pins, 1 side 1 [1]",僕はBaochipに何らかの形のI/Oコプロセッサを欲しがっていたので、PIOを自分が知る最善の方法 — — つまりコピーすること — — で研究することにした。Lawrie Griffithのfpga_pioをフォークして出発点とし、欠けていたコーナーケースをすべて洗い出すために、大量の回帰テストと詳細なシミュレーションを行った。その結果、RP2040世代のPIOコアにかなり近い、仕様に完全に準拠したものができたと思う。このgithubリポジトリで公開している。PIOから学んだ教訓PIOクローンを構築してFPGAにコンパイルしてみて、僕は驚いた。PIOが驚くほど多くのリソースを消費するのだ。FPGAで使うことを考えているなら、PIOはスキップして、やりたいペリフェラルをRTLで直接実装したほうがいいだろう。

上記はXC7A100 FPGAをターゲットに配置配線したPIOコアの階層的リソースマップだ。PIOが占める部分をマゼンタでハイライトしている。FPGAの半分以上を消費しており、RISC-V CPUコア（右側の「VexRiscAxi4」ブロック）よりも多い！わずか9命令しか実行できないにもかかわらず、各PIOコアは約5,000のロジックセルで構成されている。比較すると、VexRiscv CPUは、IキャッシュとDキャッシュを除けばわずか4,600ロジックセルしか消費しない。

さらに、PIOコアのクリティカルパスはVexRiscvの少なくとも2倍悪い。FPGA設計ではVexRiscvだけであれば100MHzのタイミングクローズは容易だが、PIOコアが入ると50MHzでのタイミングクローズすら困難になる。

Vivadoのタイミング解析結果をざっと見てみると、何が起きているかの手がかりが得られる。

上記は設計中の最も長い組み合わせパスのひとつとして特定されたロジックパスであり、下記はそのセルの詳細レポートである。

問題は、コンピュータアーキテクチャそのものと同じくらい古い論争、すなわちCISC対RISCの議論に行き着く。PIOは「たった」9命令しか持たないが、各命令は信じられないほど複雑だ。単一の命令で、以下のすべてを1サイクル内に実行できるように調整されている：何らかの通常操作（JMP、WAIT、IN、OUT、PUSH、PULL MOV、IRQ、SET）プログラムカウンタのインクリメント……さらに、特定の条件に達したらプリセットされた場所にラップバックする32ビットバレルシフタを通じてデータを回転させ、潜在的な宛先/ソースとの間でやり取りするしきい値をチェックし、入力/出力FIFOを補充するかどうかを決定する（結合されている場合とされていない場合がある）別のピンをサイドセットする可能性割り込みフラグを計算し、結果に基づいてプログラムカウンタを変更する可能性複数のマシンが共有リソースにアクセスしようとした場合の優先度の競合を解決するロジック面積の多くは、ピンマッピングオプションの柔軟性を処理するために必要なシフタによって消費されていることがわかる。PINCTRLレジスタを見ると、4つの「ベース」セレクタがあり、これは4つの32ビットバレルシフタと、シフタの末端に取り付けられた構成可能なラン長を意味する。基本的に、PIOの「回転＋マスク」部分は、ステートマシン自体よりも多くのロジック面積を消費しており、これら一連の回転マスクとクロック分周、FIFOしきい値計算を1サイクルに押し込むことは、時間的にも非常にコストが高い。PIOのオプションの柔軟性は、基本的にFPGAの上でFPGAのような配線ネットワークをエミュレートしていることを意味し、それが非効率性の原因だ。

おそらく僕のPIOの実装には、もっと効率的にするための最適化が欠けているのかもしれない。しかし、僕はサイクル精度を維持することにかなり注意を払っており、その過程で、たとえタイミングクローズを改善できたとしても、忠実性に影響を与える最適化は避けなければならなかった。

FPGA研究から得た教訓は、ASICフローにも引き継がれた。Baochip-1xの生成に使用したのと同じツールチェーンにコードベースを通したところ、ゲート数と遅延も同様に大きく、そして「遅い」ことがわかった。「遅い」と引用符を付けたのは、GPIOのビットバンギングという本来の用途には十分な速度だからだ。ASICで可能なことに比べれば遅い、というだけの話だ。PIOユーザへの注意事項どうやらPIOには少なくとも1つの特許が関わっているようだ。方針として、僕は特許を読まないことにしている。したがって、この再実装が特許を侵害しているかどうかについて意見を述べることはできない。しかし、これはRaspberry Pi財団が自社ブロックのオープンソースによる再実装を歓迎していないというシグナルだ。彼らは僕に対してこのブロックのソースコードを削除するよう強制していないが、この共有したリファレンスコードを使用しようとする人は誰でもこの問題を認識し、製品に組み込むリスクを考慮すべきだ。別のアプローチ僕の専門的な訓練とキャリアの影響は、コンピュータアーキテクチャにおけるRISC陣営にしっかりと位置づけられている。博士課程の指導教官だったTom Knightは、ハードウェアアーキテクチャについて考えるとき「重要なのは配線だ、バカ」とよく言っていた。複雑さは将来の負債になること（別の言い方をすれば「シンプルな設計は新しいプロセスへの移植が容易だ」）、ハードウェアの目新しさは優れたソフトウェアツールなしでは無価値であること、を彼は教えてくれた。

その結果、PIOは抽象的な思考概念としてはなかなか面白いが、実装者としては本当に気になる存在だった。バレルシフタはハードウェア的に高コストだ。バレルシフタにはたくさんの配線があり、僕は配線を慎重に使うように訓練されてきた。さらに、カスタム命令セットはコーディングが難しく、特に命令実行に影響を与える帯域外の設定があるとなおさらだ。数ヶ月を費やして大量のPIOコードを書いた後でも、僕はまだ最初のトライで動かすことに苦労し、カスタムPIOコードをデバッグするためにVerilatorシミュレーションに大きく依存していた（他のPIOプログラマーがどのようにデバッグしているのか、僕には見当もつかない。しかし、もし何かあるとすれば、PIOの再実装の最大の利点のひとつは、Verilatorを使ったシミュレーションで実際にPIOコードをデバッグできることかもしれない）。

結論として、この作業をすべて終えた後、僕は力を得たというよりも疲弊していると感じた。PIOは、僕が期待していたほど楽しくなかったのだ。

そこで、ふと思いついた。PIOのオールRISCバージョンがあったらどうだろう？こうして「BIO」が生まれた。ひねりのあるRISC実のところ、RISC-V 32ビットコアは非常にコンパクトにできる。Claire Xenia WolfのPicoRV32はその好例だ。このコアは、Xilinx 7シリーズFPGA上で761スライスLUTまで縮小し、200MHz以上の速度を達成できる。それにもかかわらず、完全なRV32I命令セットを実行できる。つまり、RISC-Vエコシステムで利用可能な優れたソフトウェアツール群を活用できるのだ。

もちろん、欠点もある。ひとつは、I/Oを決められたタイミングで切り替えたい場合、サイクルカウント地獄に陥ることだ。もうひとつは、単にコアをロード/ストア命令でI/Oレジスタに配線すると、4つのコアがGPIOレジスタのバンクを競合することになり、多くの非決定性やウェイトステート、その他の複雑さが生じる。つまり、4つのPicoRV32コアをAXIバスに接続してGPIOをビットバンギングすればPIOのような結果が得られる、という単純な話にはならない。

幸い、僕には秘策がある。数十年前、博士論文のために「ADAM」と呼ばれるCPUアーキテクチャを設計した。詳細のほとんどはここでは関係ないが、ひとつのトリックだけは重要だ。レジスタファイルに通常のレジスタだけを置くのではなく、その一部をキューにマッピングし、アーキテクチャレベルでfull/emptyのブロッキングセマンティクスを持たせるのだ。このトリックにより、軽量な命令レベルの並列性から、プロセッサとI/Oリソース間の高速で低レイテンシな通信まで、多くのことが可能になる。ここで使うのは後者の特性だ。BIOの設計BIOの設計は、RV32Eとして構成されたPicoRV32から始まる。このモードでは、完全な32レジスタ（ゼロレジスタを含む）の代わりに、16レジスタ（r0～r15のみ）がRV32E仕様の正式な部分となる。そして僕は、r16～r31を悪用して、一連の「レジスタキュー」とGPIOアクセス、同期プリミティブをマッピングする。下図は、4つのRV32Eコアそれぞれで公開される最終的なレジスタセットを示したものだ。

（上図で、ベージュ色の長方形は通常の読み書きセマンティクスを持つレジスタ、ラベンダー色の長方形は様々な条件に基づいてCPU実行をブロックできるレジスタである。）

テキストでの「上位バンク」レジスタの説明：FIFO - 8段FIFOの先頭/末尾アクセス。コアはオーバーフロー/アンダーフロー時に停止する.

x16 r/w fifo[0]
x17 r/w fifo[1]
x18 r/w fifo[2]
x19 r/w fifo[3]

Quantum - ホストが設定したクロック分周パルス、またはホストが指定したGPIOピンからの外部イベントが発生するまでコアは停止する .

Baochip-1x：高信頼性アプリケーション向けの「ほとんどオープンな」22nm SoC (ブログ翻訳）

Mon, 01 Jan 0001 00:00:00 +0000

僕の最新プロジェクトのひとつがBaochip-1xだ。これはTSMC 22nmプロセスで製造された「ほとんどオープンな」フルカスタムシリコンチップで、高信頼性（high assurance）アプリケーションを対象としている。セキュリティチップではあるが、他のどのセキュリティチップよりもはるかにオープンだ。また、Raspberry Pi RP2350（Pi Pico 2に搭載）とNXP iMXRT1062（Teensy 4.1に搭載）の間を埋める、汎用マイクロコントローラとしての側面も持っている。

このプロジェクトはBetrustedイニシアチブの最新の一歩であり、8年前にエド・スノーデンと共に「国家レベルの敵対者による大量監視という文脈において、ぼくらはハードウェアが私たちを裏切らないと信頼できるのか」という問いに答えようとした作業から生まれた。Baochip-1xのCPUコアは、僕が作ったセキュリティデバイスPrecursorの内部で使用されていたFPGA SoCから直接派生している。また、僕が開発を支援した純Rust製の組み込みOSであるXousを実行するために明示的に設計されており、シリコンの正しい構築を非破壊で検査するために僕が先駆けて開発した手法であるIRIS検査との互換性も意図的に持たせている。

簡単に言えば、Baochip-1xは、350MHz Vexriscv CPU＋MMUを搭載し、4つの700MHz PicoRV32を備えたI/Oプロセッサ（「BIO」）、4MiBの不揮発性メモリ（RRAM形式）、および2MiBのSRAMを組み合わせたSoCだ。さらに、TRNG（真性乱数生成器）、各種暗号アクセラレータ、セキュアメッシュ、グリッチ検出器、ECC保護RAM、ハードウェア保護されたキースロット、単方向カウンタなど、通常はセキュアエレメントにのみ搭載される機能もこのチップに詰め込まれている。

このチップは、専用のマスクセットを使用して、完全に量産認定されたTSMCプロセスで製造されている。つまり、これは限定生産のMPW（マルチプロジェクトウェハー）による試作品ではない。Baochipのサプライチェーンは、もし需要があれば数百万個のチップを生産できる能力を持っている。

このチップは、専用のマスクセットを使用して、完全に量産認定されたTSMCプロセスで製造されている。つまり、これは限定生産のMPW（マルチプロジェクトウェハー）による「お試し」チップではない。Baochipのサプライチェーンは、そのような需要が現れれば数百万個のチップを生産できる能力を持っているのだ。高信頼性ソフトウェアを実行するために構築されたハードウェアBaochip-1xの重要な差別化要素は、メモリ管理ユニット（MMU）を搭載していることだ。僕の知る限り、この性能・統合度のクラスのマイクロコントローラでMMUを搭載しているものは他にない。OS専門用語に詳しくない方のために説明すると、MMUは、スマートフォンやデスクトップで動作するソフトウェアと、トースターで動作するソフトウェアを分けているものだ。MMUは各アプリケーションを独自の仮想メモリ空間に配置することで、安全でロード可能なアプリケーションを実現する。

MMUは1960年代にまで遡る由緒ある技術だ。ページベースのメモリ保護方式は十分に理解されており、時の試練に耐えてきた。僕はその原理を何百人もの学部生に教えてきたが、今なお現代のOSの基盤であり続けている。

（上記：Kilburnらの論文「One-level storage system」（IRE Transactions, EC-11(2):223–235, 1962）に示された初期の仮想メモリ方式の図）セキュリティ指向の機能を評価する際、古いことが必ずしも悪いわけではない。むしろ、時の試練に耐えていることは肯定的なシグナルだ。例えば、AES暗号は約26年前に登場した。コンピュータ技術としては古く思えるかもしれないが、多くの暗号研究者は、何年にもわたって各国の代表を含む何百人もの暗号研究者が解読を試みてきたという実績があるからこそ、新しい暗号よりもAESを推奨している。

僕はCHERI、PMP、MPUといった新しいメモリ保護技術についても知っている。技術者として、こういった技術について考えるのは大好きだ。実際、僕の博士論文では、新しいCPUアーキテクチャにおけるCHERI型のハードウェア機能とタグ付きポインタの使用を提唱した。

しかし、実践的なシステムアーキテクトとして、MMUをこれらに取って代わられるべきものと見なす理由はない。実際、MMUはこれらすべてのプリミティブと組み合わせることが可能だ。同じRISC-V CPUにPMPとMMUの両方を搭載することは有効だ。また、CHERIのような技術をポインタのハードウェアによる境界チェックに使用していたとしても、それだけでは透過的なアドレス空間の再配置は実現できない。ページベースの仮想メモリがなければ、各プログラムはコンパイル時に物理アドレス空間の重複しない領域にリンクする必要があり、スワップメモリを使用することもできない。

ここで疑問が生じる：MMUがそれほど明らかに良い追加機能であるなら、なぜもっと普及していないのか？そんなに明白な選択なら、なぜもっと多くの企業が自社のチップに搭載しないのか？

組み込みSoCに見られるような「小型」CPUは、その誕生以来ずっとこの機能を欠いてきた。この慣習は、1990年代にARM7TDMIコアが登場したことにまで遡ると考えられる。当時、トランジスタは貴重であり、メモリはさらに貴重だった。そのため、ページテーブルを保持するだけの容量さえもない数キロバイトのRAMしか持たないデバイスにとって、仮想メモリは製品と市場の適合性が高いものではなかった。ARM7TDMIコアの効率性と低コストは大成功を収め、10億個以上が出荷され、ARMを組み込みSoC分野の支配的プレーヤーとして確立した。

それから30年が経ち、ムーアの法則は私たちに数万倍もの能力をもたらした。今日では、小指の爪よりも小さいシリコンの一片に、1990年代のフルサイズのPCデスクトップよりも多くのトランジスタが詰まっている。この進歩にもかかわらず、これらの小さなシリコンの一片は、1990年代に確立されたパターンに従い続けている。小型システムは、アドレス分離のないフラットなメモリ空間を持つ、というパターンだ。

（上記：現代の22nm SoCのダイショット。このシリコンの一片は一辺約4mmで、1990年代のデスクトップPCよりも多くのトランジスタを含んでいる。ロジック領域が、シリコン面積の観点ではアクティブゲートよりも空きスペースが多いことに注目してほしい。）根本的な原因は、MMUがあまりにも価値が高いからであることがわかる。MMUがなければ、Linux、BSD、Machを実行することはできない。そこでARMがIPポートフォリオをAシリーズ、Rシリーズ、Mシリーズに分割した際、低コストのMシリーズコアには、高級なAシリーズコアの価格侵食を防ぐために、MMUの搭載が禁止された。その代わりに「MPU」として知られる独自仕様のハックが導入され、ある程度のメモリセキュリティが提供されたが、スワップメモリやアドレス空間の再配置といった利点への簡単な道筋はなかった。

僕らはこの慣習に長く縛られすぎて、その前提に疑問を投げかけることを忘れてしまっていたのだ。

RISC-Vのようなオープンなアーキテクチャ仕様と、VexriscvのようなRISC-V仕様の完全にオープンな実装のおかげで、私は「何をSoCに搭載してよくて何がダメか」という誰かのルールに縛られることはない。だから、僕は自由に、Baochip-1xにMMUを搭載するという選択をすることができた。

これにより当然、愛好家たちはBaochip-1x上でLinuxを動かそうと試みることができるようになるが、僕ら（主にSean “xobs” Crossとぼく）はすでに「Xous」と呼ばれる純Rust製のOSを書いている。これはMMUを組み込みながらも、Baochip-1xのような小容量メモリのデバイスを明確にターゲットとしたフレームワークだ。Xousの詳細はこの投稿の範囲を超えるが、興味があれば39C3で行った講演をご覧いただきたい。「今」こそ、よりオープンなフレームワークを選ぶべき時これは、「なぜ『ほとんどオープンなRTL』のSoCがこの時代に適切なのか」という核心的な議論につながる。オープンソース技術の断固たる支持者として、僕はファブから上まで完全にオープンなシリコンスタックが実現することを切望している。この問題の解決に取り組む複数のイニシアチブがあることに心強く思っているが、これは難しい問題だ。経済的に競争力のあるSoCを市場に投入できるほど堅牢なオープンソースシリコンエコシステムが整うまでには、10年以上かかる可能性があると見積もっている。

今日、組み込み製品を作ろうとしている人々にとって、残された実用的な選択肢はひとつだけだ。Cortex-M ARMデバイスを使い続けること、そしてハードウェアによるメモリ保護が必要な場合は、ソフトウェアを彼らの独自仕様のMPUに合わせて調整することだ。これは、僕らのコードベースをさらに独自仕様の標準に深く埋め込むことを意味する。本当に僕は、XousをARMの独自仕様のメモリ保護方式に移植することに時間を費やしたいのだろうか？もちろん答えはノーだ。

だからこそ、僕は、完全にオープンソースなPDK（プロセスデザインキット）が登場するのを待つ余裕はまったくないと主張する。完全にオープンな完璧なソリューションを待つよりも、今日、部分的にオープンなRTLのテープアウトを行う機会を得ることの利点は、僕には明確に理解できる。

今日利用可能な部分的にオープンなSoCは、ハードウェアの専門家でない人々も含め、オープンソースの未来に関心を持つより広範なコミュニティにとって力となる。より大きなコミュニティとして、僕らはARMからの依存脱却のプロセスを共に開始することができる。そうすれば、経済的に実現可能な「真にオープンな」シリコンの代替品が市場に登場したとき、それらは成熟したアプリケーションスタックに直接組み込むことができる。何しろ、シリコンへの需要を生み出すのはソフトウェアであって、その逆ではないからだ。

良いニュースとしては、Baochip-1xでは、データに対して「計算」を行うことができるものはすべて、シミュレーションと検査が可能であり、すでにGitHubで公開されている。クローズドソースとなっている部分は、AXIバスフレームワーク、USB PHY、PLL、電圧レギュレータ、I/Oパッドなどのアナログコンポーネントだ。

したがって、Baochip-1x SoCの特定の部分はクローズドソースだが、それらのいずれもデータの変換に関与していない。言い換えれば、クローズドソースのコンポーネントはすべて実質的に「配線」だ。一方から入ったデータは、もう一方から出てくるデータと一致するはずだ。これは「絶対的な信頼」という観点からは不満が残る（ブラックボックスである配線内のバックドアの可能性を完全に排除することはできない）。しかし、その境界を検査し、広範な可能性に対して正しく動作することを確認することは可能だ。完全な透明性ではないが、現在秘密情報の処理に使用している完全にNDAで囲まれたSoCよりもはるかに優れており、さらに重要なことに、オープンアーキテクチャ向けのコードを書き始めることができ、最終的には完全にオープンなシリコンからソフトウェアへの未来への道を切り開くことができる。ヒッチハイクで勝利を掴む半導体に詳しい方ならお気づきかもしれないが、このようなチップを製造するのは決して安くはない。にもかかわらず、僕はベンチャーキャピタルから1ドルも調達していない。また、僕は一人でこれができるような富裕層でもない。では、どうしてこれが可能なのか？

簡単に言えば、僕はCrossbar, Inc.が主に設計した22nmチップに「ヒッチハイク」したのだ。彼らが設計しているチップのフロアプラン上の未使用スペースに、僕が選択したCPUといくつかの追加機能を組み込むことができた。どのCPUをアクティブにするかを切り替えることで、実質的に1セットのマスク代で2つのチップを得ることができる。

上記：Baochipのフロアプラン。5つのオープンソースCPUコアの位置と相対的なサイズを示している。System-on-Chip（SoC）の内部を覗いたことのない方のために説明すると、現代のSoCのコストは主にペリフェラルとメモリによって決まる。CPU自体は面積のごく一部に過ぎず、Baochip-1xの場合もわずか数パーセントだ。さらに、すべてのペリフェラルは「メモリマップド」方式を採用しており、例えばLEDを点灯させる場合も、メモリ上の特定の場所にアクセスするだけで実現できる。

この「アクセス」を誰が行うかは重要ではない。ARMでもRISC-V CPUでも、あるいはステートマシンでも、ペリフェラルは同じように応答する。したがって、同じ「身体（ボディ）」に異なる「個性（パーソナリティ）」を与えることができる。つまりCPUコアを交換することで、同じ物理的なシリコン上で全く異なるコードベースを動作させることが可能になる。

長い答えは数年前に遡る。Crossbarは、いくつかの点で差別化された高性能なセキュアエンクレーブを構築したいと考えていた。特に、他のセキュリティチップと比較して比較的先進的な22nmプロセスで製造すること、そして不揮発性ストレージに自社のRRAM技術を使用することだ。RRAMはフラッシュメモリと同様に電源を切ってもデータを保持するが、書き込み時間が速く、ページサイズも小さく（32バイト）、40nm以下へのスケーリングが可能だ — — フラッシュがスケーリングできなくなった限界以下である。

プロセスの優位性を活かすことに加えて、Crossbarは設計について実用的なオープンソースであることで差別化したいと考えていた。セキュリティチップは、ユーザーからの透明性の要求にもかかわらず、伝統的にNDAの背後に包まれていたからだ。

逆説的だが、オープンソースのセキュリティチップは認証がより難しい。なぜなら、コモンクライテリアのような認証基準は、クローズドソースの欠陥をオープンソースの欠陥よりも「安全」と評価するからだ。私の理解では、その論理はおおよそ次のようなものだ。「ハッキングは難しいのだから、チップを悪用するための初期コストに少しでも障壁を加えられれば、チップ全体の実効的なセキュリティは向上する」。基本的に、セキュリティ評価を行うペネトレーションテスターが、ソースコードが公開されていればバグをより簡単に発見でき悪用できると判断した場合、ソースコードを共有することはスコアを下げることになる。その結果、オープンソースのチップの認証スコアは、クローズドソースのチップよりも悪くなる可能性が高い。そして、認証なしでは大口顧客にセキュリティチップを販売することはできないため、セキュリティチップは結局ほとんどがクローズドソースになってしまう。

なかなかクレイジーなシステムだと思わないか？しかし、大量のセキュリティチップを購入しているのが銀行や政府のような機関であり、そこにはリスク管理を主な関心事とする非技術系の管理者がいて、しかも技術的評価は外注しているということを考えれば、現状も少しは理解できる。銀行員がチップのソースコードをどうするというのだろう？

Crossbarはこの流れに逆らい、セキュリティチップにおけるオープンソースの透明性を求める声に応えたいと考え、私に戦略アドバイスを依頼してきた。私は彼らの支援に同意したが、ひとつ条件を付けた。私が選択したCPUコアを追加し、そのバージョンのチップを自分のブランドで販売することを許可することだ。理由のひとつは、Crossbarがリスク低減の観点から、独自仕様のARM CPUを採用したいと考えていたからだ。以前にチップ設計を経験した者として、テープアウト実績のあるコアを採用してリスクを低減したいという思いは理解できる。

しかし、オープンソース戦略アドバイザーとして、私はオープンソースを肯定的な機能と見なすユーザーは、少なくともCPUはオープンソースであることも期待するだろうと主張した。そこで私は、Precursor SoCから実績のあるVexriscv CPUコアをテープアウトに追加することを提案し、たとえ動作しなくてもそれを無効にすればチップの消費電力と面積の予算への影響は最小限に抑えられるという方法で実装することを約束した。

Open-Source-Hardware on ニコ技深セン / Nico-Tech Shenzhen website

BIO：Bao I/Oコプロセッサ （bunniestudioブログ翻訳）

Baochip-1x：高信頼性アプリケーション向けの「ほとんどオープンな」22nm SoC (ブログ翻訳）

BIO：Bao I/Oコプロセッサ（bunniestudioブログ翻訳）