Home

2019年
2020年

1月16日 除算性能 ICF3-Z vs RISC-V

実際に比較しないと、わからない人が多いと思いましたので、小型のRISC-VコアであるlowRISCのibexと比較してみました。 ICF3-ZのZeviosは8bit CPUですが、lowRISCのibexは除算器を持った32bit CPUです。
lowRISCのWebページにXilinxのローエンドのFPGA(7シリーズ)に実装した場合の周波数が50MHzと書かれてありました。 そして除算は37サイクルで動作と書かれています。
Zeviosは同じくXilinxのローエンドのFPGA(Artix-7)に実装した場合、周波数は150MHzになります。つまり3倍の周波数で動作。 0除算などのチェックや演算レジスタへのロード、ストアの補正として3~6サイクル追加しています。

除算

ibex
RISC-V
[サイクル]

Zevios
ICF3-Z
[サイクル]

ibexを1とした
倍率

周波数を考慮した
倍率

16bit÷8bit

37

20

1.85

5.55

24bit÷8bit
条件付き

37

21

1.76

5.29

32bit÷8bit

37

55

0.67

2.02

32bit÷16bit

37

約350

0.11

0.32

ZeviosはXilinxのFPGA XC7A35TICSG324-1Lです。

ibexは2500LUTの面積ですが、Zeviosは400LUTの面積です。 外部I/OなどZeviosに不足しているものがあるかもしれませんが5分の一の面積で5倍以上の性能が出ることは、考えるべき点ではないでしょうか


1月15日 ICF3-Z、Apache Licenseで公開開始

8bit CPU ICF3-Zが正式に、Apache Licenseとして運用が開始されました。 32bit÷16bitの除算のサンプルコードがgithubに追加され、 ダウンロードしてverilogでシミュレーション可能です。
ブログ「8bit CPU ICF3-ZのZeviosの除算性能のメモ」も参考になると思います。


1月8日 8bit CPU AVRとICF3-Zとの違い

ブログ書きました。 「8bit CPU AVRとICF3-Zとの違い」


1月6日 ICF3-Zの別実装の計画

計画ですが、いつごろになるのか、未定です。Zeviosに低速のメモリを接続しながら、 高速メモリ上では高速に動作するような改良。 クロック・イネーブルで作るのか、クロックを2種類使うのか、まだ決めていません。 圧縮命令や割り込みで高速動作に移行、全てのリターン命令で低速モードに移行というルールなら タイミングを除いて完全互換なコアになるかもと。 明示的に高速動作、低速動作させる命令を追加すれば、もっと性能を上げることはできるのかな。
計画の話なのですが、別実装のコアを命名、ZeraCresta。 Terra Creastaという縦スクロールのシューティングゲームがあったので、それに近いものということで。


1月2日 ICF3-Z特許侵害調査

ICF3-Zの公式コア ZeviosをApache License 2.0で公開するべく、他人の特許を侵害していなか調査しています。 ICF3-Zの圧縮命令が、インテルの特許第5984865号 「命令エミュレーションプロセッサ、方法、およびシステム」を 侵害していると疑う人がありそうなので解説します。
ICF3-Zには唯一の命令セットしかなく圧縮命令はサブルーチンコールの一種。 ICF3-Zにエミュレーションか否かの状態を保持する記憶装置は必要ない。 すなわち圧縮命令実行中なのか通常の命令を実行中なのかを保持する記憶装置は必要ない。 公式コア、Zeviosのverilogファイルにそういう記憶装置(reg)は存在しない。

2019年1月2日 0:30PM HL bitは圧縮命令のような16bit長の命令を制御するための記憶装置。 16bit命令を処理した後、次の命令を読み出すのに使われる。 2つの圧縮命令が続く場合、1つめの圧縮命令を処理中、HLビットは1になるが、2つめの圧縮命令を処理中にはHLビットは0になる。 つまりHLbitはエミュレーションのロジックではない。


12月31日 ICF3-Zの互換性の問題と32bit仮想マシン

RISC-Vは命令セットアーキテクチャから、いろいろな実装が作れます。 しかし ICF3-Zは命令セットアーキテクチャが、 ほぼ実装であるため、オリジナルのZevios以外の実装は、あまり存在しないだろうと考えています。 ZeviosはApache License 2.0の予定なのでZeviosを派生させることを想定しています。 互換の問題が生じる可能性がありますが、ZeviosがICF3-Zの仕様と考えています。
Zeviosは、とても小さいコアで、非常にシンプルな作りなので、 問題を起こせる場所の総数も少ないだろうと思っています。 ICF3-Zをスーパースカラにすることもないと思われます。 8bit CPUをスーパースカラにして性能向上させるくらいなら高性能な ARMでいいような気がしています。
趣味かもしれないですがZeviosで動作する仮想マシンを作るのは面白いかもしれません。 仮想マシンで互換性の問題が解決できます。 既存のARMマイコンでも仮想マシンのエミュレータを作れば動作する。
ICF3-Zは8bit CPUですが、仮想マシンは32bitにできるかも。 仮想マシンのレジスタを16本とすると必要なメモリは128バイト。 データメモリより高速にアクセスできるスクラッチパッドが256バイトあるので、 思ったよりも高速な32bitマシンになるか??


12月20日 8bit CPU ICF3-Z、github公開

8bit CPU ICF3-Zを XilinxのFPGAに実装したverilogファイルをgithub にアップロードしました。これまで限定公開したバージョンとほどんど違いはありませんが、 不要なファイルを削除したので、これまでより読みやすくなっていると思います。 Xilinx依存な記述はないのでverilogが使えるシステムなら、使えると思います。 ICF3-Zのオリジナル実装をZeviosと命名しました。 名前の由来は、アーケード版ゲーム XEVIOUS(1983年)のデッドコピーXEVIOSの頭文字XをZにしたもの。 XEVIOUSはBASICマガジンに連載されるなど当時、大人気でした。 CPUは8bitのZ80が3個、使われているそうです。


12月15日 ICF3-Zのライセンスについて

8bit CPU ICF3-Z、お願いつきApache 2.0ライセンスというのを考えています。 ライセンスとしては完全なApache 2.0です。 そこに「できれば日本の税金を使ったプロジェクトでは利用しないでください」という、お願いをつけます。
準備期間として1ヶ月、様子をみて運用を開始します。


12月09日 ICF3-Zは32bit÷16bitできるのか?

8bit CPU ICF3-Z、 本当は、実際にプログラムして確かめるべきなのですが時間の都合で予想の話になります。 結論を先に言うと、除算器のないCPUの普通のプログラムよりは、 ICF3-Zのアーキテクチャによって高速に演算できるのではないだろうか。
ICF3-Zは演算レジスタとして4個の8bitレジスタ(A,B,C,D)を持っています。 1命令でA,B,Cのレジスタを1ビット左シフトしてAとDを比較してA≧Dなら AレジスタにA-Dの結果をセットして、キャリーをCレジスタの最下位ビットにセットすることができます。 これは16bit÷8bitの除算のためにあるのですが、強引に32bit÷16bitの演算のために使うとできるのかも。
できるという根拠は、ICF3(1999年)は1024bitの演算器で4096bit÷2048bit(厳密にはmod)の コードを実際に作って確認したからです。 もし詳細を知りたい方は、僕のブログ「IoTの原価を下げる暗号プロセッサICF3」にあります。
余談になりますが、僕が中学生のころ買ったZ80の本に16bit÷8bitのコードがありました。 以下は、その本の写真です。電波新聞社の創業者さんも現在(2019年)の社長さんも、 僕と同じ「平山」という姓みたいです。全然、関係ないのですが(^^;;


写真をマウスでクリックすると拡大されます


12月05日 命令の組み合わせを変更して24bit÷8bitを演算可能に

8bit CPU ICF3-Zは任意の値の16bit÷8bitを17サイクルで演算できますが、 命令の組み合わせを変更することで24bitの上位8bitが除数8bitよりも小さい場合は、 24bit÷8bitを17サイクルで演算できます。 従来の命令セットでは、 抽象化によってメリットを得ている半面、 ハードウェアの能力を十分に引き出すことができません。 ICF3-Zの命令セットは、抽象化のメリットを捨てることで、 ハードウェアの能力を、最大限引き出せています。


12月01日 ICF3-Zの利権を複数人で管理するとどうなる?

8bit CPU ICF3-Zですが、 正式なオープンソースとしてスタートした場合、運営をどうしていくのか、考えました。 現在、僕1人で管理していますが、リソースの提供と引き換えに管理者を迎え入れるとします。 そして競合他社の潜入2名が管理者として加わり3名で運営すると、 潜入2名がICF3-Zの実用化に対して反対して、ICF3-Zは失敗プロジェクトになる。
つまり僕1人による管理体制でなければ、ならないということを理解しました。
僕1人による管理体制を実現するため、CPUコアのみを管理することを考えています。 まだ考えている段階。つまりデバッグ機能などは、サードパーティによる後付け。 CPUにデバッグ機能を実装するための割込みがありますが、時間がなくて完璧にできることは 実証できていません。ただデバッグ機能が完璧である必要はなく、できるところまでで 実現するという方針にすれば、問題はないように思います。
参考までに、僕のソフトウェアの経験ですがWindowsのデバイス・ドライバを開発したり、 ICカード暗号ミドルウェアを実装したりと、実は経験が結構あるのです。
デバイス・ドライバのデバッグはRS-232Cのリバースケーブルを使って 別のパソコンにデバッグ情報を表示させるのですが、ドライバがバグでクラッシュすると、 クラッシュした地点よりも、かなり前までの情報までしか取得できず、苦労しました。
暗号ミドルは、カーネルモードではなく、ユーザーモードだから安全だと思っていると間違いで、 printf()関数で、可変パラメータの表示をさせると、何故か、そこで終了してしまうとか、 いろいろ経験しています。


暗号プロセッサ OpenICF3