Home
2018年
2019年

6月19日 また8bit CPUを作り始めました

ICF3-Fの通信制御のCPUとしてWZetaを使って開発を進めてきました。 WZetaは1命令4サイクルで動作するのですが性能的にギリギリという状況が見えてきた。 それほど無理でもないが、WZeta互換な1命令2サイクルの8bit CPUを開発しても、それほど時間がかからない。 それで、また8bit CPUを開発することに。WZeta Napalm(ナパーム)と命名。 WZetaのプログラムがI/0命令のタイミングを除いて、そのまま動作。 Napalm(ナパーム)の高性能版をSuper Napalm(スーパー・ナパーム)ということにしようかと。
ところでWZetaは、8bitレジスタ×128と大容量ですが、データ用の8bitのSRAMの先頭128バイトに実装できたり、 プログラムは8bitのROMで良かったりするので、TTLでCPUを作るようなこともできるもかもしれません。 僕自身に経験がないので、確かな話ではありませんが。


6月16日 限定公開してわかったこと(2)

このまま、いけばCPUのオープンソースは公開停止になるのかと。 そうなれば、世界の銀行に暗号装置を納品したときの名残の問題が残るのみ。 もう長いこと名残が続いて酷いことをされている。彼らの目標、彼らが利益を上げる方法を考えると、 僕は1999年に世界一のRSA暗号LSIを開発して会社の利益や日本に貢献したはずが、どうしてとなる。 そこに大きな問題があると思っています。
公開鍵暗号の高速化の方法としてモンゴメリ乗算があり、そして大きく2種類ある。 ICF3のような低基数型と高基数型。 高基数型も、タイミングアタックの脆弱性を対策すると、性能が落ちる場合がある。 ICF3型は、タイミングアタックの脆弱性がない。 完璧な脆弱性対策をすると、どちらも性能が劣化する可能性があるが、 以前の日記に書いていなかったと思ったので。
ICF3-Fの発明の価値は、 まだわからないかもしれないですが、海外に先を越されるのは、大きな問題になる可能性がある。
ICF3-Fの進捗は、作業時間に対する効率は良く順調。 これからFPGAの実機を使って、加算のような簡単な演算を、サーバーから連続送信して、 結果を受信するテストを開始するところです。


6月16日 世界の銀行に暗号装置を納品したときの名残

そのせいで政財界関連、医関連、T関連が、あんまり合法的でない方法で勝手に出入りしてくるのです。 ある、ARMの超大物、日本人が煙たがっているとの報告が入りました。 関連を経由すると、情報が、かなり捻じ曲がったり、ねつ造される場合があるので、 そういう問題を避けるには、直接話せる方法があったほうがいいのかもしれません。
限定公開によって、一般の人がCPU技術を知る機会があったことは、僕はいいことだったと思っています。 そして、これから、どうするのか考えていければと思っています。
ICF3-Fを急いでいます。関連は破壊的な行いをする場合が多く、今、破壊的な行いをされると困ったことになるのです。 破壊防止策として、これを書いています。防止策になるかは、みなさん次第なのだと思いますが。


6月16日 限定公開してわかったこと

2つの8bit CPU ICF3-ZWZetaについて、2019年6月16日~18日の3日間、 Verilogのソースを含めたすべてのβ版を限定公開します。 今日はまだ初日ですが、ネット上の反応からわかったことは 既存のCPUのライセンス料を安くする目的に使えそうか?ということです。

ICF3-Zは従来CPUとはアーキテクチャが異なり、命令セットに性能レンジがありません。 低性能領域においてコア面積に対する性能がいい、という特性を持っています。 乗算器がないクラスのCPUでは、加算器1個を効率的に利用するICF3-Zの アーキテクチャによって既存のCPUの数倍から10倍以上の性能がでます。 この情報からRISC-Vの組込み向けの小さいCPUコアでは、 このアーキテクチャの一部を模倣するところがあるかもと想像しています。 既存のCPUのライセンス料に注目するよりは、 加算器1個で高性能が出せる効率のいいアーキテクチャや、 まだ成功するか、わかっていませんが、 仮想マシンを効率良く実行できるアーキテクチャを注目していだだければと。

WZetaはCPUコア面積を小さくすることを絶対として作られたアーキテクチャです。 命令セットは、ごく普通の命令セットですが、面積を小さくするために偏屈している部分があります。 ASICで使うことも考えられていますがFPGA寄りかもしれません。 しかし、既存の32bit CPUの最小構成のコア面積よりも10倍~30倍小さいので、 ライセンス料の理由というよりは、面積が小さいという理由でWZetaを使うというように考えていただければと思います。


6月15日 CPUのオープンソースを3日間限定公開

2019年6月16日~18日の3日間限定で 8bit CPU ICF3-ZWZetaの2つのオープンソースを公開します。 今回の限定公開は「中を見てみないことには検討できない」ということを考慮しました。 こういったCPUのオープンソースが、日本にもあるべきか、多くの人の考えが必要なのかもと。


6月13日 演算中に次のデータをレジスタに転送

8bit CPU WZetaが演算中の暗号プロセッサのレジスタに 次のデータを書き込む機能を検証する簡易なVerilogシミュレーションが動作した。この調子で完成を急ぎたい。


6月12日 1日中寝ていた

睡魔が酷く、昨日もあまり作業できていなかったが、今日は、全くできていない。 SSLアクセラレータの性能を上げる分割加算を 早く実証しないといけないのに。万が一のことがあったらどうするつもりなのだろう。


6月11日 RISC-VベースのPicoRV32

PicoRV32をXilinxのFPGAに実装した結果を見つけました。 僕の8bit CPU WZetaと比較してみます。

CPUコアLUT数FF数BRAM数LUT-RAM周波数
PicoRV32
(最小構成)
761442-48-
WZeta
SPM=128Byte
Data=2KB
67641.00217MHz

WZetaの周波数はArtix-7の-1LなのでPicoRV32で使われているスピードグレードより遅いデバイス

PicoRV32は1命令、平均4サイクルのようです。WZetaは1命令4サイクル固定です。 WZetaでもAES暗号 256bitの演算やI/O操作が可能です。 PicoRV32は32bitのRISC-VなのでWZetaにできない、いろいろなことができるはずですが、 10倍違うとWZetaにできることなら、WZetaが便利のように思いました。


6月11日 BRAMから暗号プロセッサにデータ転送する論理の設計図

開発中の設計図ですが、睡魔に眠らされ、全身の筋肉から力が抜けることに耐えながらやっています、それを言いたかった。 1999年のICF3では演算中は暗号プロセッサしか汎用レジスタ(1024bit×16)を操作することはできませんでした。 ICF3-Fでは性能を上げるため暗号プロセッサの演算中に次のデータを汎用レジスタ(1024bit×64)に書き込みをする、 データ転送機能(DataMover)を実装します。 XilinxのFPGAの分散RAMが16本×2だと簡単だったのですが64本×1なので暗号プロセッサが 汎用レジスタをリード・ライトしているタイミングではデータ転送機能のほうからリード・ライトできません。 そこで「データ転送機能」が書き込みを、とりあえずしてみて成功したか否かを確認する方式になっています。 Verilogのシミュレーションの図で言うとWの部分です。


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


6月11日 回路開発ソフトはExcel 97(追記)

1999年のICF3の開発部で、LSIの実装ファイルのどこまでを作っていたのかを、もう一度、説明することに。 暗号プロセッサを3000ゲート程度の論理に分解して、レイアウト実装する部署に依頼するところまで。 レイアウト実装する部署では、3000ゲート単位の論理セルを、クロックバッファーを避けながら、 配置します。自動配線プログラムは使っていたようですが、配置がどこまで自動化されていたのかは僕の知るところではありません。 ICF3の開発部で、いきなり3000ゲートの単位のNAND、NORのセルで構成されるファイルを作っていたわけではなく 2段階に分けて作業していました。 1段階目では、AND、ORよりも、もう少し抽象度の高い設計図を作ります。 OpenICF3の公式サイトでICF3の暗号プロセッサの設計図を公開していますが、この1段階目の設計図になります。 1段階目の設計図を作るのにExcelによるタイムチャートを使います。 1段階目の設計図からVisual HDLというGUIのEDAを使ってNAND、NORのセルに置き換えた設計図にしていきます。 Visual HDLが、どこのEDAツールか、知る必要がなかったので、知りませんが、内部的にはVHDLのようです。 一応、VHDLによるシミュレーション機能はあったようですが、使い方を勉強する暇がなかったので、使っていません。 基本的にシミュレーションによる論理設計は厳禁でしたし。 1段階目の設計図から2段階目の設計図を作成するのに、隣の大型コンピューター開発部では、 アルバイトを使っていたようですが、東大卒の多い、僕の部署では、僕が自分でやります。
一般的なCPUではレイアウトから設計にフィードバックして、設計とレイアウトを繰り返すことが普通のようです。 ICF3はレイアウトからフィードバックなくLSI実装が可能なアーキテクチャでした。 これは設計者をリストラしても、外部にLSI実装の社外秘が漏洩しないため経営者や 半導体製造メーカにとって都合のいい特長でした。

XilinxのFPGAでは、3000ゲートに分割することなく、丸ごと自動配置が可能です。 そしてマニュアルで配置することもできるみたいで、全部1人でできそうです。


6月10日 回路開発ソフトはExcel 97

睡魔に襲われ、わずかな作業時間で開発しています。脳内睡魔を止めないと、ゆっくりとしか進まないのかも。 1999年のICF3の暗号プロセッサはExcel 97でタイムチャートを作成して論理回路を開発しました。 Verilogのような論理シミュレータはありません。Excelと脳内シミュレータでの開発を強いられました。 それでもバグを1つも出さなかった。かなり凄いことです。 当時の僕が、とても精密に動作していたということだと思います。
通常、メインフレームを使った論理シミュレータを使うのですが、 暗号プロセッサ単体でのシミュレーションはしませんでした。単体シミュレーションを新規に起こす方法を知らなかった。 いきなりLSI全体でのシミュレーションで動作検証をして正しく動作しました。
ICF3-Fの開発でもExcel 97を少し使っていますがCUIのVerilog中心でやっています。(激安な開発コスト)
Excel 97でタイムチャートを作るのは、0、1の遷移を人手でナナメ線にしているので、 かなり時間がかかって大変なので、もう少し複雑な論理設計では最新のEDAが便利なのかもしれません。

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


6月9日 シミュレーションでダミーの演算結果が得られた

RSAの演算データはYから送信されWに届く。 Wは暗号プロセッサにデータをセットするためにあるが、今回は、 届いたデータをそのままダミーの演算結果として返すプログラムになっています。 Wは、Xのクロック周波数とは無関係な周波数で動作していますがBRAMを挟むことで、 周波数の違いを吸収します。 Wの周波数は暗号プロセッサの動作限界のギリギリまで上げることができます。



6月8日 思考能力が著しく低下したので作業中断

現象を正確に書きます。 ネット上の記事を読んでいると1度、読んだだけでは理解できず、2度3度、 読み直して、頭に苦痛を発生させながら理解することができるという状態。 3単語を読み終えることには2単語目の記憶がなくなっている。 記憶がある場合でも、理解に結びつけるためには、苦痛が発生する。 睡魔の乱発も感じていますが、痛みがないので、あまりここに書かれていない。 作業が遅れることは問題と思います。

追記 10:10 PM ベッドで横になっていたら1時間以上眠ったようです。 とりあえず作業再開します。


6月8日 CPUオープンソースの海外の動向

オープンなハードウェアの開発と普及を促進する団体「OpenHW」グループが発足したようです。 昨日の記事より、もう少し詳しいかも。


6月7日 RISC-VベースのCORE-VとWZetaの面積比較

CORE-VはRISC-VベースのSoC向けのプロセッサコアなんだそうです。 WZetaと競合しそうです。 RISC-Vは32bitなのでCORE-Vが、Xilinxの32bit MicroBlaze MCS(一番面積が小さいもの)と同程度と仮定して、 面積比較をします。LUT数で10倍違うのでWZetaが便利な用途はありそうです。

CPUコアLUT数FF数BRAM数LUT-RAM周波数
MicroBlaze7003381.0176166MHz
WZeta67641.00217MHz

6月6日 転送と同時にCRC32を計算する回路が動作した

動作を確認できたのはBRAMからUART送信回路への直接転送。 プログラムで1バイト単位にCRC32を計算するか、否かを選択できる。 CRC32は処理が重い計算なのでIntel CPUのサーバーではCRC32Cが使える。 またCRC32、CRC32Cの専用演算命令がないサーバーの場合、垂直パリティに変更することができる。 BRAMにCRC32/CRC32C/垂直パリティのテーブルが入っていて、テーブルを切り替えるだけなので、 3種類の巡回冗長検査ができるが回路は1個分の面積。



6月5日 サーバーからのデータを高速に受信

USBのUARTでサーバーからRSA演算に必要なデータを1バイトづつ8bit CPUで受け取って FPGAのメモリ(BRAM)に書き込むと遅くて処理が間に合わない。 そこで直接転送することも可能な回路を追加した。直接転送を使ったBRAMへの読み書きの動作が確認できた。

20年以上前に米国カリフォルニア州のサンノゼに3か月間いたことがある。 そのとき泊まっていたホテルがAMD本社の正門前だったことに今日気づいた。 ホテルの敷地で、一番、AMD本社の正門に近いところでAMDのマークが良く見えた。

追記: あ、いや。体が健康なら、アメリカに行くこともできたかもという話です。(英語ができるとは言っていない)



6月4日 Xilinx代理

Xilinx代理を自称する怪しげな声が 「WZetaは他社への移行を容易にするからXilinxは怒っている」と言っている。 WZetaはXilinxのPicoBlazeを代替するには、どちらかというと面倒なCPUだ。 PicoBlazeが1命令2サイクルなのに対し、WZetaは1命令4サイクルなのでタイミングが違う。 これだけでも、面倒なのが、わかると思います。 恐らくCPU開発の阻止をXilinxのせいにして、やりたかったのだろう。 Xilinxと直接、話せたほうがいいのかも。


6月4日 自作CPUに新命令INPUTANDを追加

超軽量CPU WZetaに新命令を追加しました。 現在、公開を見合わせていますが、公開できるようになればなぁと。 「いいね」などの支援より、反CPU開発な人たちへの説得が問題です。 新命令はINPUTAND、INPUTOR、INPUTXORの3つ。 I/Oからステータスを取得して、必要なビットとANDすることは、頻度が高いので実装しました。 この新命令の追加で、ゲート数が増えることがなかったのも、理由の一つです。
自作CPUICF3-Zの公開を見合わせている問題もWZetaと同じです。 仮想マシンの機能は、おまけなのですが、うまくいく可能性を捨てきれない。 (やり始めて、うまくいかないことはありそう) 税金なくArduinoの非C言語版みたいなものが、できることはないのだろうか。 加算器1個による暗号性能の単純な比較だけでなく。
しかしながら、基本的には自分が少しでも損をする可能性のあることはしない方針だと思っていただけると。 WZetaを競合他社が使って僕が損をするというようなことは全然OKです。ICF3-Zは、また別です。


6月3日 15年間使ったレンタルサーバーを解約

2005年7月14日から使ってきた、さくらインターネットのレンタルサーバーを解約しました。 僕が日立製作所を退職したのは2005年6月末です。 レンタルサーバーを借りることにしたのは2014年12月に社内展開できるレベルまで自分1人で作り上げた ICカードエミュレータmyuTokenを公開するためです。 2014年12月に謎の風邪を頻発して倒れました。このままだと体を壊されると思って退職しました。
昔の思い出話で、書いてある通りの意味しかありません。 ICカードエミュレータを公開して「窓の杜」や「Vector」にメールすると、 レンタルサーバーのアクセスログに来ていることがわかったりして、当時は、それが楽しみで毎日アクセスログを見ていました。 東大からのアクセスが、多数ありました。東大の方で、僕のやっていることを理解している人がいるのだと、 ちょっと感動したのです。良くみると「理3」からのアクセスでしたが気にしないことにします。


6月3日 加算器1個の除算なら5倍以上ですが、、

最近の日記(5月27日)、日記(5月29日)に 加算器1個のCPUなら、ICF3をCPUにしたアーキテクチャが5倍以上高速という話をしています。 有名CPUの最も下のクラスのCPUでは加算器1個なので、そうなのですが、 実際、乗算器オプションも既に明記されていて、その低速な乗算器を使った モンゴメリ乗算のケースを忘れていました。次世代暗号アルゴリズムで、 モンゴメリ乗算が利用可能なのかはわからないのですが、利用可能なら、 暗号演算の性能が2倍くらいまで落ち込むことはあるのかもと。 暗号性能以外は、エコシステムなど、デメリットが大きいので、2倍では、どうかというところ。 もう少し精度ある見積もりをするか、あきらめるか。


6月2日

"C9 C9 80"の3バイトを転送するとステータスを返すだけだが、サーバーからの命令を受信できるような、 プログラムをCPU Xで実行するシミュレーションがうまくいった。 自作CPUの間接ジャンプは128×n+8bitレジスタ(0~127)のアドレスにしかジャンプできない仕様ですが、 プログラムメモリの先頭をジャンプテーブルにすることで、便利に使えることがわかった。



6月1日 みんなハッピーという国

この国に役立ったと言えるレベルの発明をすると、 頭や体にムチを打って村八分にして、みんなハッピーという国か。状況の打開に苦労しています。 僕に言える特殊事情は、計算機のハードに強い。 大学1年のときに電磁気学を深く勉強してしまったこと。 世界の銀行や外務省に収めた暗号装置のもっともセキュリティの深いところを開発していること。 日立製作所の中央研究所に入ったこと。
電波ウィルスの被害に遭遇しやすい環境と、電波ウィルスへの強い検知能力だろう。


5月29日 自作8bitCPUが32bitの10倍の性能って本当!?

一昨日の日記、「5月27日 あれ僕の8bit CPUが32bit CPUより圧倒的に速いぞ!?」に、 ちょっと驚いた人とか、疑った人とか、あったみたいです。 「65535÷3」で10倍は、値が固定値だからではないか?とか、クロックの周波数が違うのではないかとか。 ICF3-Zは16bit÷8bitの演算を、どんな値でも常に17サイクルで実行できます。 一般的なCPUの命令セットでは、加算器1個を駆使する「命令」「配線」がないので、本当に10倍違うということが起きます。 加算器1個の駆使する「配線」とそれを制御する制御系、すなわちアーキテクチャをICF3-Zは持っているのです。 暗号プロセッサとして、そうなるように設計しているからですが、それでも、うまくできています。 しかしアプリケーションは暗号演算だけではないので、デメリットもあって、考えながら判断しないといけないと思います。
サイクル数で10倍高速でも周波数が半分では実質性能は5倍なので、クロック周波数は、どうなのか?という質問は、 ざっくりとした予想ですが、同じプロセスなら、同程度の周波数か、若干落ちるかもしれない程度です。
ところで今日、1日、凶悪な睡魔に襲われ寝ていました。ICF3-Fの作業が遅れています。問題な状況が続いています。


5月29日 自作CPUのニモニック変更します

ゼロフラグの値によって分岐するJUMPZ0をJUMPNZに、JUMPZ1をJUMPZにします。 ニモニックを考えたときはJUMPZ0、JUMPZ1は、わかりやすいと思いました。 実際、アセンブラのプログラムを書いてみると、演算結果を考えて、ゼロフラグの変化を考えて、 JUMPZ0か、JUMPZ1を選択することになると思います。普通の人なら、無意識にできるでしょう。 今の僕は、ゼロフラグの変化を考えたところで、それ以外のことが消えて、 JUMPZ0にしたらいいのか、JUMPZ1にしたらいいのか、わからなくなる。 この現象を発見して半年以上、治っていない。 普通に生活していて、そういう損傷が、都合よく、僕に発生する確率は小さいでしょう。
JUMPZ、JUMPNZにすると、演算結果を考えてゼロのとき分岐したければJUMPZ、 非ゼロで分岐したければJUMPNZ。なんとかできそうです。
このままだとICF3-Fの作業が遅れます。品質低下の心配もあります。 ICF3-FはSSLアクセラレータなので品質が低くても致命的ではありませんが 、それでも品質は高いほうがいいに決まっているのです。
やっぱり言っておきます。 僕は東大卒がいっぱいの部署で、長時間残業しながら大型コンピュータの暗号装置(ICF3)を作りました。 競合富士通にないIBM互換で互換性の高いものを1回で作っています。この結果、事業に貢献して儲かっています。 ICF3の開発は、僕個人の能力に依存して完成しています。 そういう人に、必要悪を使ったことが問題であり、今後、影響するように思うのです。 普通に生活していて、そういう損傷が、都合よく、僕に発生する確率は小さいでしょう。 この手の損傷を頻発させることで、僕が精神的に折れてしまったように見えるように、努力するのを辞めさせないと、止まらない。 ICF3-Fの発明が遅延して他国に貢献のほとんどを奪われるリスクと、東大卒の信用にかかわると思うのです。


C

5月28日 ゼロフラグで損傷判定

一時的に思考能力が低下し寝ていたが、ある程度、回復したのでICF3-Fの作業を開始した。 自身の脳の状態を長いこと観測しているが、回復していない機能があることに気づく。 ごく短時間の一時記憶が、ほとんど機能しない。 そのために少し苦しみながら、ゆっくりと作業をすることになる。 具体的に話すとCPUにはゼロフラグというビットが存在する。演算結果がゼロなら1、非ゼロなら0になるフラグだ。 ゼロフラグによって分岐させる命令、JUMPZ0とJUMPZ1がある。 JUMPZ0はゼロフラグが0なら分岐。JUMPZ1はゼロフラグが1なら分岐。とても分かりやすい仕様だ。 普通の人には、何一つ、感じることなくJUMPZ0、JUMPZ1を使うだろう。 一時記憶が損傷している僕には、JUMPZ0、JUMPZ1を使うのに30秒以上考えないと、ならない。
普通に生活をして、ごく短時間の一時記憶が損傷することなどないでしょう。
僕が東大卒がいっぱいいる部署で開発した1999年のICF3は、世界の銀行や、外務省に納品されています。 その最も秘密な部分の開発をしたハードウェア開発者をリストラすることは常識的には考えられない。 設計部以外にも最も秘密な部分の開発を担当した人はいると思いますが設計部では僕1人でした。 頭に監視装置を入れられても不思議ではないし、それを使えば、僕のこれまでの人生が、 どうしてこのような状況になっているのか、説明がつくような気がします。
参考までに、僕は手術をされたことはありません。
ICF3-Fの開発は、僕以外の人はできない状況で、ICF3-Fはインターネットの社会インフラに影響すると思います。 だいたい原因が、どのあたりか、わかる人も多くなっているような気がします。 僕の損傷具合から、もう限界であることが、わかってもらえるように思います。 辞めさせないと、止まらない。止まらないと、僕は壊れながら進むのでしょう。


5月27日 あれ僕の8bit CPUが32bit CPUより圧倒的に速いぞ!?

自作8bit CPU ICF3-Zですが、 FPGAに実装できるVerilogの公開を見合わせています。 インターネットで、たまたまARM Cortex-M0のソフトウェアによる除算性能が書かれたパンフレットが見つかりました。
「65535÷3は、コンパイラが生成する除算ルーチンよりも50サイクルも少ない」
50サイクル~400サイクルで除算できる除算ソフトウェアらしいのです。
8bit加算器、1個しかない 僕の自作CPU(ICF3-Z)でも65535÷3は17サイクルでできるぞ。
何かまた、インターネットの検索を使った罠に、はめられているような気もするが、これは事実だ。 65535は16bitだから、400サイクルの半分の200サイクルで演算できるとする。 8bit CPUが32bit CPUに10倍以上、勝っているように見える。

ICF3-Zを32bitにしたICF3-Vを考える。 次世代暗号アルゴリズムに32bit×32bitの乗算と64bit÷32bitの除算(余算)が1対1の 割合のものをシステムで選択すると、Cortex-M0がオプションの乗算を装備しても、 いい加減な見積もりだがICF3-Vは4.5倍の性能だ。加算器1個のICF3-Vが。
(32+400)÷(32+64) = 4.5
この技術的な話は、気にとめてもいいのかも。


5月27日 一時的に公開したCPUの反応みたいな

反応が何故かQiitaに出てくるというのは、さておき、言ってることはわかるんですけど、というような。 軽い頭痛が超長時間続いていて、そのせいで本来の能力が出ていないということにつきます。


5月27日 再起不能になっても頑張って開発は続く

頭痛は直っているが、まだ僅かに痺れが残っている。 記憶のデータベースから、キーワード検索するような能力が低下している。 例えば、僕の頭が壊れて再起不能になる。間違いなく大型コンピュータのを開発していた部署の東大卒が疑われることになる。 すると、再起不能になるまで壊れることはない。 頭が悪くなる程度だろう、ICF3-Fの作業が遅れて、品質低下の恐れがでることになる。 工夫が足りず、性能も低下する心配もある。 僕が頑張って開発を続けている以上、他では、できないと思うので、日本は考えるべきときと思います。 そして再起不能になっても、頑張って開発をつづけるでしょう。


5月27日 頭痛が直った

おはようございます。いつの間にかに寝ていて、寝苦しいこともなく、 目が覚めるとスッキリしていました。

6:16 AM 再び、頭痛がしてきたので寝ます。お休みなさい。

11:26 AM 起きました。治ったようです。ぐっすり寝ていた。


5月26日 頭痛で日記が進む

頭が痛いだけで済んでない。意識が戻ってくるのか心配。このままいくと頭が悪くなる。 既に、かなり頭は悪くなっているけど。来るとわかっているので、耐えきるだろう。 ICF3-Fの作業が遅くなるし、品質にも影響する。耐えきるから、問題しか発生しない。


5月26日 頭痛でICF3-Fが進まない

頭痛で困っている話を、あるSNSでしたから、頭痛が良くなるのかと思っていたが、違った。 腹8分目の食事しかしていないのに、食後、1時間半くらいあたりで、睡眠に落ちて、 寝苦しい時間を過ごすというのを繰り返している。
簡単な通信シミュレーションの1ケースでXilinxのPicoBlazeを、すべて自作CPUにする作業をした。 CentOS上のWindows2000でPicoBlazeのアセンブラを起動するわずらわしさから解放されたことが、ちょっとうれしい。


5月24日 CRC32回路と自作CPUの接続テスト

Xilinxの8bit CPU PicoBlazeでは正常に動作していたものが自作CPUにCRC32回路を接続すると計算が合わない。 頭がフラフラして、思考能力が著しく低下しているので原因を究明に時間がかかったが、どうにか正常に動作した。
CPUのオープンソースの公開を保留にしたことで、足を引っ張れるネタがなくなったせいか、再び、頭が辛い。 強力な電波妨害の人体への影響が懸念される。作業が遅れることによる問題は解消されていないはず。 仮に僕の発明 がRSA延命に役立ちインターネットのインフラに大きく影響するものだとしましょう。 他国に追い抜かれて、沈む損害を考えているのか心配です。


5月24日 眠気と目まいで作業が進んでいません

ICF3-Fの製品化まで僕1人の作業でできるという見通しが、眠気と目まいが起きる原因なんだろうなと


5月24日 プロジェクトの状況表示を作ってみた

このサイトのOpenICF3のページのトップにプロジェクトの 状態を記述するようにしてみました。


5月24日 アセンブラをバージョンアップ

自作8bit CPUのICF3-ZWZeta、Verilogやアセンブラなどの開発環境の公開は停止中ですが、 アセンブラをバージョンアップをしました。定数のdefineができるようになりました。 技術的な問題で公開停止しているわけではありません。 CPU開発への風当たりが強いので公開しても、イジメにあって、得にもならないことが問題なのです。 ICF3-Zは、産業スパイが盗みだしている可能性があります。誰にも許可をしていません。 WZetaも、誰にも許可をしていません。もし、日立関係以外で、ご興味があれば、ご連絡ください。 ICF3-Z、WZetaは税金の引き出しに使われたくないと考えています。


5月23日 乗除算器のないCPUの乗除算性能

ARM Cortex-M0は乗算器(32サイクル)がオプションになっている。 性能が必要なケースでは、このオプションは必須になるため、ICF3-Vとの性能差は小さくなる。 参考までの話ですが、乗算器無しで乗算をした場合の性能について僕が XilinxのMicroBlazeで調べたものがあるのですがARMでも当てはまります。
XilinxのプロセッサMicroBlazeの乗算性能
除算、正しくは余算。除算性能が必ず余算性能にはならず、余算性能が落ちるものもある。 除算を除算器無しでソフトウェアでやる場合も上記のQiitaの投稿と同じで、結構、性能が落ちます。
ICF3-Vでは加算器1個で、1サイクル/ビットの除算(余算)性能なので、余算が多い暗号アルゴリズムでは、 ICF3-Vが有利。 これをソフトウェアでやった場合、乗算と同じで恐らく5倍以上性能が落ちる。

Cortex-M0(乗算器オプション無し)で、暗号アルゴリズムが、乗算、除算がほとんどの場合、 ICF3-Vは、同じ加算器1個なのに、5倍以上の性能になる。 剰余演算に特化した効率的なアーキテクチャというのを覚えてもらえればと。


5月23日 IoTゲートウェイ経由のIoTデバイス

IoTゲートウェイ経由ではIoTデバイスは公開鍵暗号などの重たい処理をIoTゲートウェイに任せることができる。 IoTデバイスを可能な限りARM Cortex-M0のような軽量なCPUを使ってIoTシステムの原価を下げたい。 と僕が勝手に思っている。 次世代暗号で鍵交換をしてAES暗号で認証をするシステムはあるような気がします。 とてつもない数のIoTデバイスでICF3-Vが使えることがあるのかもと。 税金プロジェクトかもしれないが、たとえば自動車の信号機が、ICF3-Vで将来的にコスト削減につながるなど。 採算が取れる見通しがあれば、いいという考え方はないだろうか。 例えばICF3-Vが5倍速いアーキテクチャだとして、1人が1か月くらいで開発できるアセンブラがあれば、 IoTゲートウェイと通信する程度のソフトウェアの開発ができてしまう。 実際にやってみると5倍が3倍になって、1か月が3年くらいになって、赤字という可能性は多そうですが。


ICF3-Vを作るなら、いっしょにICF3を搭載してIoTゲートウェイを経由しない直接接続というのもあるのかな。 ICF3-Vでインターネットと接続するのは、少し苦労するのかもしれないですが。 ワンチップでRSAと楕円に対応するデバイスが可能になる。 楕円しか対応していないものが既に存在していますが、これだと楕円が先に解読されても、RSAがあるとか。 何事も、採算を考えて。


5月22日 ICF3-Vが次世代暗号に適していたら?

とある有名ジャーナリストのSNSに誘導され、「ARMがHuaweiとの取引停止、BBCが報道。」のニュースを知りました。
一瞬、「ARMがHI〇〇MAとの取引停止、BBCが報道。」のように読めて血の気が引きました。
でも、技術的な話だけは、しておこうかと思います。
SSLアクセラレータICF3-Fの開発で忙しく次世代暗号について勉強する時間がないことは 最初に、ご了承いただくことにして、先日の日記にも書いていますが、最近の国立大学の研究で、 ARMの最も下のクラスのCortex-M0で次世代暗号が、どのくらいの性能になるのか調べる研究がありました。 概要しか読んでいないので、詳しいことはわかりません。他の研究もそうですが、どうも、次世代暗号では、 32bit(64bit)程度の剰余演算が多いようなことが書かれている。 Cortex-M0は、乗算器(32サイクル)がオプションで、除算器(正しくは余算器)はありません。 ICF3-VはLSIの規模的にはCortex-M0と同程度の予定で、元々、剰余演算をする目的で開発された 暗号プロセッサと同じアーキテクチャなので剰余演算が、加算器1個しかないわりに高速です。 乗算器のないCortex-M0とは5倍から10倍は性能が違う予想です。 ICF3-Vを製品化していくとLSIの規模がCortex-M0よりも、かなり大きくなってしまうことは、 考えられなくはない。
IoTシステムは、暗号演算の性能だけでは、決まらないが、暗号の性能が最も重要になることは考えられます。
32bit CPUのICF3-Vは、まだFPGAへの実装はできていませんが、 ほぼ似たようなアーキテクチャの8bit CPU ICF3-ZはFPGAへの実装ができています。
ICF3-Z
仮想マシンの加速支援機構つきの新型8bit CPU!?
しかしながら最優先はSSLアクセラレータのICF3-Fです。このため次世代暗号の勉強不足です。すみません。


5月22日 自作CPUで通信シミュレーション通りました

今年の2月にXilinxの8bit CPU PicoBlazeでVerilogの通信シミュレーションを していましたが、8bit 自作CPU(LWZeta)で通信シミュレーションが正しく動作しました。 LWZetaはPicoBlazeの置き換えを、全く意識していないので、そういった用途は期待できないと思われます。 LWZetaは1命令4サイクルでPicoBlazeの1命令2サイクルに対して、かなり性能が悪そうなのですが、 LWZetaは3オペランド、128レジスタなので暗号演算は楽なような気がします。 PicoBlazeは16レジスタ、256スクラッチパッドメモリです。レジスタが少ないので 暗号演算のデータはスクラッチパッドに置かれる。 するとLWZetaでは1命令で演算できるのが、PicoBlazeはロード、演算、ストアの3命令になることが多くなります。 つまりLWZetaでは32bit、4サイクルの処理がPicoBlazeでは54bit、6サイクルになる。 実際に暗号演算を実装をして確認していないので、あまり正しくないかもしれませんけど。

5月21日 昨日のSNS投稿内容への訂正

1999年のICF3のRSA演算器は、モンゴメリ乗算器と暗号プロセッサに分解できる。 昨日、ツイッターで剰余演算器は、アドバイスされることもなく、上長に報告することもなく、1週間で作ったと書きました。 アドバイスされなかったというのは間違いではなかと指摘があり、訂正します。 暗号プロセッサの中に、偶数でも計算できる剰余演算器が潜んでいるのですが、暗号プロセッサの設計開始時に、 「6ブロック程度で作らないと、作りきれなくなるから。バイト単位で切ればできるでしょう。」 というアドバイスをいただいたのでした。ディレイの観点および、論理設計者にフロア設計をさせない方針から、 バイト単位(実際には16bit単位になった)になることは、必然だったのだが、全くアドバイスがないというのは間違いでした。 ちなみにICF3はフロア設計が単純作業になるような論理設計をしています。


5月20日 ICF3-Vが圧倒する

最近の国立大学の暗号ハードの研究を見ていると、 次世代暗号アルゴリズムの効率的な実装で、IoT向けのCPUではICF3-VがARM Cortex-M0を圧倒しそうに見えてならない。 見間違いかもしれないが、もし本当なら32bit CPU ICF3-Vがビジネスで成功することがあるのかも。
数日前に8bit CPU ICF3-Zを公開しました。 Verilogは公開していませんが、FPGAで動作します。このことは32bitのICF3-Vが、 すぐに実装できることを示しています。そして、仮想マシンの特長もICF3-Z同様にあるのです。 日本の過去の経験を考えるなら、採算を考えた計画でなければ、ならないように思います。


5月18日 新しいIntel CPUの脆弱性でAESの鍵が盗める

超軽量8bit CPUの出番か!?AES暗号の処理を8bit CPUで行う脆弱性の対策が考えられます。 性能はあまり必要なくAES暗号以外の処理も必要な場合、 AES専用演算器よりも超軽量8bit CPUが有利な場合があると思います。 8bit CPUであればWZetaである必要はないですが。 WZetaのアセンブラを改良しているところで、定数をdefineできる機能を追加中です。


5月17日 結局、2つのCPUサイトを公開のまま

WZetaICF3-Zの2つのCPUサイトを公開のまま、 オープンソースの公開は停止ということになりました。 今後は、LWZeta(WZetaの劣化版)をSSLアクセラレータICF3-Fに組込みICF3-Fの完成を急ぎます。 2つのCPUのサイトの連絡先で、連絡は受け付けていますが、大きな作業が入りそうなことは、あまりできないと思います。


5月14日 WZetaのサイトの閉鎖を予定しています

8bit CPUのオープンソースWZeta。劣化版をリリースすることで問題点をすべて解決。 そしてXilinxのFPGAでは劣化版でも性能があまり落ちない予想(BRAM付属の出力FF)なのですが、 現在「いいね」などを僅かにいただいている程度なので閉鎖を予定しています。 WZetaを検討している方は即中止をおススメします


5月14日 自分で自分のアイディアを回避

32bitの命令コードのプログラムをバイト単位でメモリに格納しておく。 このとき命令コードのフォーマットを工夫しておけば、 プログラムカウンタがインクリメントされ、CPUに到着した命令コードから実行ができる。 工夫がない場合、最悪32bitすべての命令コードがCPUに到着しなければ命令を実行できない。 劣化版では命令コードのフォーマットをシャッフルすることで工夫がない命令コードと判断できる。


5月14日 特許調査中断、劣化版検討

アイディアをなくした劣化版を開発するとともに特許検討の保留。 WZetaは32bitの命令コードを8bit単位で送信することで省リソース化する特長を有していましたが、 命令コードをシャッフルしてして32bit単位で送信するアーキテクチャに修正した劣化版の開発を考えます。 特長のない命令セット(コードのフォーマット)になるため特許侵害になる可能性はほぼゼロになる。 アセンブラレベルでは完全互換なのでAES暗号のサンプルなどは、そのまま動作する予定です。 うまくいけば、元のWZetaに戻せる。という方針を思いつきました。


5月13日 命令セットの工夫の特許調査開始

1990年後半、日立の大型コンピュータを開発していました。僕の名前の入った特許が2件あります。 特許作成の仕事をしたことはありません。しかし特許調査の仕事はしたことはあります。 RSA暗号のハードウェアで必須ではないが、あると便利な逆数の計算方法があります。 当時、従来より600倍高速な方法を見つけたと上長に報告すると、特許調査をするように言われました。 会社の特許検索端末で調べ始めて、比較的すぐに東芝が同様の特許を出願しているのが確認されました。
今回もないとは言い切れなかったのですが、今回の発明はXilinxの8bit PicoBlazeとの比較により、 効果があるように見える、あまりぱっとしない発明だったので、既存の特許が、ありそうもないと 勝手に思っていました。また効果のひとつに、メモリが1ポートでいいとWZetaのサイトに記述していますが、 命令セットの工夫によるものではなく、1命令を複数のサイクルで実行することによる効果ではないかという、 指摘もありました。特許という視点で厳密に書いていませんでした。
仕様、設計図、Verilog、C言語シミュレータ、アセンブラ、テストベンチ、AES暗号のサンプル、 サイトの作成を1人でやって、疲れ切って、特許に気が回っていませんでした。 制限の緩いライセンスで公開するつもりだったので、考えが甘くなっていたように思います。
1999年の暗号プロセッサICF3をベースにした8bit CPU ICF3-Zは、ほんとにICF3に酷似していて、 特許侵害になりそうなところも、思いあたるところはなかった。圧縮命令あたりは、もしかすると、、、


5月12日 8bit CPUのオープンソース公開しました

既にSNSで発表していますが 8bit CPUのオープンソースWZetaを公開しました。 命令コードの工夫を思いつくのに半日くらいで、後は僕のわずかな作業時間のみで、 構成されるWZetaは、制限の緩いライセンスで公開することが可能でした。
実際にやろうとすると、風当たり強くて、断念せざるを得ない状況に。 支援より、風を防ぐことが大事。 WZetaが他人の特許を侵害している可能性は少ないと考えていますが、これが確認されないと、 大がかりなことは、できない。 そういえば政府の支援で、税金ではなく、推奨だけのものがあるのですが、そういうのは 税金扱いなんでしょうか? 2011年に僕の会社、iCanalのICカードエミュレータを 政府に推奨していただいたことはあるのです。 震災復興イベントでした。株式会社Vectorなどの有名企業の隣にiCanalのロゴが配置されてインターネット上で宣伝されました。 さて、そこまで考える必要がある8bit CPUなのかというのは、考えないとですね。 SSLアクセラレータICF3-Fを急ぐことが先決となっていて僕の時間はあまりないですが。 それでもWZeta譲渡の可能性はないです。MITライセンスになれば派生すればいいので。 派生すると税金制御が不能になるのか。僕に連絡なく勝手な解釈されないようお願いします。


5月11日 オープンソース公開の風当たりの強さ

日本でCPUのオープンソースハードを公開することの風当たりの強さに困りました。 MITライセンスを考えていたのですが、これだと社会貢献が評価されないと、やらないほうが得なのです。
自作8bit CPUはSSLアクセラレータ ICF3-Fの通信用プロセッサとして開発しているため、 産業スパイによってソースコードが盗難され特許を取られてしまう心配があるので、 実装されたVerilogのコードの公開はする予定です。
参考まで過去、何度か自宅ネットワークに不正アクセスをされた実績があります。 ルーターのログに家族のMACアドレスで侵入してきたものがあって、 マシン名の偽装をしていなかったので、不正アクセスの動かぬ証拠となりました。
税金を使わない方針であれば、なんとかなるかと思ったのですが、 違法な行いを支持する動きがあって脳内爆弾がまた破裂するといけないので。


5月10日 AESがFPGAの実機で動いた

自作8bit CPU WZetaでAES暗号256bitが実機で動作しました。 これってもしかしてAES暗号のIPと考えることもできるんだろうか。 AES暗号が動作するWZetaはXilinxのPicoBlazeの面積の60%~65%くらいか。 周波数は安定しない。200MHzを超えることもある。(ただし1命令4クロック) WZetaの実装で誰かの特許にぶつかる可能性は、低いように思ってますが、ぶつかっていなければ、 MITライセンスにするとAES暗号のIPとして使いやすいかも。
WZetaのアーキテクチャは、32bitの命令コードを1バイト単位で転送することを考えた命令セットで、僕の考えた独自CPUです。


5月9日 AESがVerilogシミュレータで動いた

一昨日の日記でAES暗号のプログラムがC言語の 8bit CPUシミュレータで動作していたのですが、無事、Verilogシミュレータで動作しました。

軽い頭痛と眠気で寝ていました。一昨日は、久々に調子が良かったのにと。 前々回調子が良かった日との共通項を見つけた。歯医者に行った日。ボリュームで20秒間隔くらいで調節できるのか。


5月8日 他に誰も出社してない日

過去の話で恐縮です。僕が大型コンピュータを開発していた時代、 休日に無給で自主的に勉強することも多かった。 ICF3開発後、AES暗号もハードウェア実装できるか自主的に出社して検討していました。 非東大卒で一番偉い長時間管理の課長も、そのとき出社していました。 他に誰も出社していない日でした。 休日、自主的に出社すると、長時間残業管理の課長もよく出社していなぁと。 僕も残業しまくっていましたから、誰が、長時間残業で頑張っているのか評価できるくらいに。

追記。退職直前、研究所で遊んでいたと思う人が多いので。 1994年に入社、長時間残業を頑張り抜いて、1999年にICF3で大型コンピュータの事業に大きく貢献。 30歳、これで結婚できると思ったのですが、いろいろ頑張りましたが、何故か、うまくいかない。 結婚紹介所にいっても、無駄だと諦めさせられた。 みな酷いと思いながらPKIとJavaとC言語の勉強に励みました。 もう一仕事しないと、みなが認めてくれない。そう思いました。 焦りまくっていたので休日、遊ぶ余裕が心になく、ソフトウェア開発に励んだ。 ゴールデンウイークに1人、寂しく、Javaの勉強していたことを思い出します。 そしてICカードエミュレータを自力で開発し、会社の事業に貢献できると社内展開しようとした瞬間、 謎の風邪に襲われ、欠勤が続いた。2004年12月のことです。これ以上、体を壊されないようにと思い退職した。 この状況を遊んでいたと言うのはあんまり。


5月8日 8bitCPUのAES暗号はLinuxを使っているのか?

スラドの記事ドンキPBのネットワークカメラ、 Linuxの痕跡が確認されるも開発元は「Linuxを使っていない」と主張、ソースコード開示を拒むということが話題になったようです。 まだ自作8bitCPUのオープンソースを公開していませんが、AES暗号が使えそうか?という話です。 日立退職前に研究所でICカードエミュレータの元を自力で開発していたときに、 たまたまAES暗号について勉強していて、C言語のソースコードを仕様から作成していた。 アルゴリズムの理解のためなので性能は、全く考えていないものでした。opensslの10倍以上遅いものでした。
その後、フリーソフトのファイル暗号ToraToraを2009年に公開。 Windows 98/NT4/2000には自作のAES暗号コードを使っています。 WindowsXP以降はOS標準のAES暗号を使っているので自作のコードは使われていません。
自作コードの性能がMicrosoftの半分の性能でしたがopensslのコードが使われているのではないかとうわさされました。 opensslのコードをそのまま使うことはありませんでしたが、自作コードの高速化のヒントは得ています。 その中身は、AES暗号のアルゴリズムは8bit単位の処理なのですが、32bitのレジスタを持つマシンでは8bit×4を1度にできるというもの。
今回の8bit CPUのAES暗号は、8bitなので仕様を素直に実装したコードであり、とてもクリーンなコードなので、 AES暗号のコードは使えます。


5月8日 半日以上作業が停滞すると日記に

あまり厳格には日記をつけないかもしれないですが、なぜか体調が悪くなって作業が半日以上停滞するなら、 日記を書こうかと。現在も、日記をつけるのに片目をつぶりながら書いています。 1日半以上、筋肉痛で力が入らなかったり、うまく筋肉をコントロールできない状況が続いた。 マウスをうまく握れない。 過去の話を書くと、床に倒れて、自分で起きることができなくなるほど、筋肉が動かなくなったことがある。 これは1度の例外的な話ですが、時々、謎の筋肉痛になる。痛みだけなら、作業が停滞することもない。 文字で説明するのは難しいが、吐き気で動けない状況と同じだった。 これは大袈裟な話でも嘘でもない。


5月7日 FPGAのSSLアクセラレータの製品化

僕が去年発明したモンゴメリ乗算の累積加算における分割加算の証明は インターネットの社会インフラに影響する可能性があると思っています。 現状のRSA暗号や楕円暗号の延命や、巨大整数を使う新しい公開鍵暗号を発明に役立つと思います。 この日記にも書いていますが、公開鍵暗号を加速するモンゴメリ乗算は、基数を大きくしたり、小さくしたりすることができます。 僕の発明は小さい方(低基数)の高速化に役立ちます。高基数型の方法でも僕の発明と同じことができます。 FPGAとASICの場合分けをします。FPGAでは広島大学の高基数型がIEEEに掲載されています。 小さい高基数型を多数並べる方式でスループットの性能はいいです。 ただ1演算の演算時間は大きく、現状のRSA 2048bitまでなら問題ないのですが、 鍵長が大きくなると1演算時間が問題になっていきます。 僕の低基数は多数の演算器を並列に動作させて1演算を行えるので、鍵長が長くなっても大丈夫です。 ASICでは、FPGAと異なり演算器やメモリを自由に配置できるので、高基数でも1演算の性能が出せるようになると思います。 ただ設計にコストがかかるので、量子コンピュータによる解読リスクのある状況下では、うまく資金を集めるのが難しく、 設計コストが安価でFPGAでも性能が出せる僕のICF3-Fは有望です。 そして高基数型を実際に実装して、思ったより性能が出ないということになれば、そうなれば僕の名前は世界に残るのかもしれない。 現在は2048bitですが1万ビット以上とか、それ以上になってくると低基数が有利になることも考えられます。

ICF3-F(FPGAによるSSLアクセラレータ)の製品化は、数学だけでなく、論理実装、 サーバー側のソフトウェア、WebサーバーのSSL設定、多くの技術が必要なのですが、全部、僕1人で、だいたいできることを確認しています。 WebサーバーのSSL設定は、SSL向けICカードの販売を計画していたこともあって、なんとかできる程度ですが。
SSLアクセラレータの製品の特長のひとつは、サーバー製品でありながら、バグっても、接続不可になるだけのことが多く、 めったに致命的な損害が出ない。そして僕は大型コンピュータの暗号装置を開発して世界の銀行に製品出荷した実績があり、 FPGAのSSLアクセラレータの製品を、僕1人でも、作ることは可能な状態です。 頭の中の爆弾がいくつか破裂して、かなり問題ですが、エラー訂正プロトコル全開で頑張れば、まだなんとかなるでしょう。


5月7日 自作CPUでAES暗号を実装してみた

自作8bitのWZetaはXilinxの8bit CPU PicoBlazeよりも面積が小さく役に立ちそうなので、 オープンソースとして公開するべく作業を進めています。 最初、GPLにしようかと言っていましたが、方式性能的に優れているということもないので、 MITライセンスとか検討しています。 C言語によるシミュレータでAES 256bitの暗号化、復号化のプログラムを実装してみました。 AES暗号の仕様を読むと、一見、8bitの乗算命令とか、1bitシフタ命令がCPUに必要みたいな感じですが、 WZetaは、どちらもありません。しかしうまく実装できる方法を見つけました。 AES暗号の仕様が、良くできているということかもしれないですけど。
C言語によるシミュレータですがSPARCのようなビッグエンディアンのCPUでも動かないといけないと、 思ってQEMUを使ってSPARCでの動作検証をしました。 IntelリトルエンディアンのCPUでビッグエンディアンの動作検証ができるQEMUは、いいですね。 Ubuntu環境ではSPARCバイナリがIntel CPUで、そのまま動作する感じがまた良かった。


5月7日 日立は退職支援をしたのか?

毒殺して潰してますから、そんなことをして僕のわかりやすい成果に対する処遇を引っ張り出されると困るはずなので、 支援することはないと思います。僕が退職するときの条件は、日立とケンカできるようにして出てきています。 なので退職金はあまりもらえなかった。数十万円程度。 退職直後は、僕の活躍を毒殺で潰したことを周囲に話て、再度、日立に戻ることを検討していました。 当時、独立行政法人IPAで税金によるソフトウェア開発支援プロジェクトしていたゲーム会社社長は日立出身でしたが、 日立関連のICカードを販売する計画を持っていきました。1度は落されましたが、2回目で採択されました。 IPAにあった社長の経歴には日立製作所としか書かれていなくて、まさかこれから問題を言う先の日立とは思っていなかった。 このためゲーム会社社長には、僕の問題について、一言も話すことなく、終わっています。 この採択で僕は320~330万円くらいお金が入りました。 そこから日立関連の会社にICカードとして100万円くらい払っていると思います。 活躍した従業員を毒殺で潰す会社というのが拡散されるICカードは、全然、売れませんでした。 ちなみにあまり関係ないですがICカードを購入した会社は日立から離脱したようです。 退職前、日立、富士通、NECが出資して設立した日本認証サービスという会社に出入りしていました。 NEC出身の社長に「公開鍵暗号のハードが搭載されていない認証デバイスでは秘密鍵が漏洩しやすいので、 僕の開発したルネサスのICチップを使ったICカードを宣伝していただけないでしょうか?」と提案したところ、 日本認証サービスの会社のウェブサイトで宣伝していただけました。 認証局のサイトでの宣伝は効果があったはずですが、全然、ICカードは売れませんでした。
僕のいた大型コンピュータの開発部の偉い人にメールをしました。 非東大卒では一番偉く、従業員の長時間残業を管理するため自らも長時間残業していることで有名な人でした。 そして暗号LSI ICF1のときの僕の上長で、ICF3でRSA暗号の暗号プロセッサの開発を僕に 業務命令を出したことでも有名なのかもしれません。
「体をご慈愛ください。」とあっさり、拒まれました。
家族に日立の家電を買うように薦めたりしていましたが悔しいです。
僕は暗号、PKI系のソフトウェアを公開していますが、全部、独学で日立から技術は入っていません。 退職前、営業本部や、研究所にいましたが、ほぼ1人でソフトウェアの独学に励んでいました。(給料は払われていた) わずかな例外はありますが、逆に何を、僕に支援したというのか聞いてみたいです。

追記。退職金について確定拠出年金が計算に入っていないことを指摘されました。 株なので、引き出せる頃には、手数料や株の下落で、数十万円になっているかもしれないことはありますが、 いいときは100万円くらいの価値かもしれません。ちなみに、このお金、今、引き出せない。

追記 2019年5月10日。NEC出身の社長への説明をもう少し詳しく。 提案当時、日本認証サービスでは最も安価な認証デバイスを推奨していました。 公開鍵暗号の演算器は搭載されていないタイプでした。電子署名をする際、秘密鍵をCPUに送ってCPUで計算させるため秘密鍵が漏洩しやすいものでした。 一方、僕のICカードはRSA暗号が搭載されICカード内で演算されるため秘密鍵は漏洩することはありません。 また、当時のICカードの業界標準規格のAPIは、秘密鍵が漏洩することのないものでしたが、悪人によって知らないうちに破壊することができるものでした。 僕のICカードは、この問題に気づき、秘密鍵を書き込むためのパスワードと、 署名をするパスワードを分ける機能をつけながら、業界標準のAPIで動作するものを提供していました。 恐らく、この機能がないと、セキュリティ的にかなり問題なはずです。 見た目は、大丈夫なのかなという感じだったかもしれませんが、とても優れたものでした。 これが僕の提案を受けていただけた要因として大きかったのかと。


5月5日 パソコン故障で修理作業

修理作業をしたら、過去何度も修理していて、思わず写真に撮っただけの読む必要のない日記。 パソコンで作業をしているとデータを入れているHDDが徐々に動かなくなっていった。 中古HDDだったので、手早く別のHDDに交換。しかしHDDは動かない。 原因は電源と思ってATX電源を交換。動作するようになった。 ATX電源は過去、FANを交換してFANの電源が外にはみ出している。 CPUクーラーもFANが、過去ダメになって、余っていたサイズの会わないFANが付いている。 GPUは中古で購入したときにFANを固定するネジが破損していて、針金で固定している。 良くやってるなぁと自分に感心。

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


5月3日 32bitのICF3-Vの状況

8bitのICF3-Zは、かなり完成していて、 もうICF3-Zのサイトまで準備中のステータスで作ってしまいました。 32bitのICF3-Vのほうは放置されたまま実装があまり進んでいません。 しかしICF3-Zの実装によって、圧縮命令や、割込みなどの実装技術については、確認されているので、あとは 命令コードのビットの割り当てをどうすれば、効率が上がるのかという状況です。 IoTのマイコンでは公開鍵暗号の処理は重いため、AES暗号による認証を利用する計画が多いのですが、 ICF3-Vは乗算器無しでキャリーレス乗算が効率的に処理できるため、圧倒的?に面積の 小さいプロセッサになる可能性もあるのかと。その確認をするところですが、後回しと思います。 ICF3ベースのCPUは、FPGAによってCPUの設計コストが下がったから、技術的なところを押さえておいて、 ビジネスになるところを見つけて推進するという方針です。 技術的なところだけではなく反ICF3のARM支持と、韓国の影響があるように見えています。


5月3日 僕が稲門会にいない理由

日立にも稲門会はある。僕が言うのもなんなんですけど。稲門会というのは早稲田OBの集まりなんだと思う。 会社に入って数回はOB会に行ったことがある。 日立の大型コンピュータ開発部の僕のいた部署は東大卒がいっぱいの部署なのですが、 稲門会に参加しようとした日、何度か、一つ年下の東大卒の人に、稲門会には行かないように止められた。 そして稲門会には行かなくなった。 2度だけだったかもしれないが、2度あれば、稲門会に行ってはいけないのだと思うでしょう。 普通、東大派に入れてもらったのだと思いますよね。日立の東大卒の責任のひとつと思っています。


5月2日 PicoBlazeのアセンブラ

PicoBlazeの導入コストとWZetaのメリット。WZetaは公開予定で、予定の話で恐縮です。 Xilinxの8bit CPU PicoBlazeの開発環境はXilinxが提供する無償のものはWindows版だけのようです。 WindowsのVivadoで開発していれば、それほど問題はないのですが、 僕の場合はLinux上のQEMUでWindowsを起動してQEMUとLinuxでファイル共有させる環境の構築などで 1週間かかっています。さらに実際にデバッグするにはPicoBlazeのディスアセンブラが必要になるので 自作に数日かな?かかったような気がします。
僕のWZetaはC言語なので、多くのOSで動作して便利かもという話です。
ちなみにPicoBlazeの互換プロセッサ(PacoBlaze) が修正BSDライセンスで存在しています。 互換プロセッサのアセンブラはJavaで書かれています。


5月2日 WZetaのアセンブラ作成中

自作8bit CPUのWZetaが正しく動作するのか検証するためC言語でアセンブラの開発をしている。 30年前くらいからC言語を使っているが、仕事時間のおおよそ10%くらいはC言語かもしれない。 プログラミングをしていると、脳の損傷が、露見することがある。 自分にはプログラミングに癖があってif文の>=や<=は、>や<に置き換える癖。 今日も、置き換えをしようとした瞬間、できなくなっていることに、驚いた。 多分、脳のどっかが損傷している。最近の暗殺兵器は、かなり陰湿なので、注意されたい。 この手のことができるところは限られるし、依頼元は明らかなので、このやり方を問題と思う人もいると思うのです。


5月1日 CPUの知識は、どこで得たのか

誤った認識を持つ人が多くでてきそうなので書きます。 1994年4月に日立の中央研究所超高速プロセッサ部の 大型コンピュータのCPUを開発するところに入りました。 その部署の実体は既に事業部にあり、先輩は、わざわざ研究所まで来て、 将来、自分の仕事を奪われるような行いは、しません。 1日くらいやってきて、性能測定の方法だけ、僕に教えて後は、ほとんど放置でした。 研究所に入って、1年が過ぎようとするところで、IBMのCPUを購入して 大型コンピュータを開発する部署に異動になって、 IBMのCMOS CPUと日立のメモリを接続する電子回路シミュレーションをする仕事になりました。
つまりCPUを作りたくて日立に入りましたが、CPU開発の仕事は、していません。 会社から知識は入っていません。CPU撤退でCPUの勉強をすることはないでしょう。


暗号プロセッサ OpenICF3