<   2018年 02月 ( 19 )   > この月の画像一覧

17年8月号の焼き直しだそうな… 気づかずに買ってしまった。
まぁ、持っている訳じゃないから良いんだけど、もともと1000円が2600円って…
目次を見ただけだけど、内容は面白そうです。
f0054075_20264269.jpg


[PR]
by tom01h | 2018-02-28 21:26 | 本・映画など | Trackback | Comments(0)
8bit 内積命令を仮実装して、推論プログラムに組み込んで試してみました。
まだ、Imm を使ってパラメタメモリのアドレスを指定する機能も実装していないし、固定小数点の位置も選択できません。そして、演算精度不足なのか、バグなのか、正しい結果が出ているか良く分からない誤差が出ています。
でも、第1層までアクセラレータ対応にすると、結構見栄えの良い結果が出ました。
これでも、データやアドレスを生成するための時間が結構かかっているようなので、Imm を使えるようにしてたうえでソフトを最適化すると、さらに高速になると思います。
[本当はbinアクセラレータをip8アクセラレータよりも前に作ったのですが、絵的に美しくないので鉛筆なめた数値でグラフ化しています;-p]
f0054075_21573695.png


[PR]
by tom01h | 2018-02-27 22:44 | PCとか | Trackback | Comments(0)

八方尾根

お蕎麦屋をやっている宿に泊まって、八方尾根にスキーに行きました。お腹いっぱいそばを食べました。
f0054075_21114373.jpg

[PR]
by tom01h | 2018-02-25 21:15 | スキー | Trackback | Comments(0)
せっかくの内積命令が BNN にしか使えないのはもったいないので、もう少し汎用性のある仕様を考えてみます。
普通なら R4-Type を使いたいところですが、R-Type に無理やり詰め込んでみたいと思います。
f0054075_20263836.png
また、BNN アクセラレータと同様に、内蔵メモリからフィルタ用データ(8bit×6セット)を読み出すのを前提とします。

A0 = 1st 8bit of rs1
A1 = 2nd 8bit of rs1
A2 = 3rd 8bit of rs1

Imm[8:0]={funct7[4:0],4'h0}
B00 = 1st 8bit of @(4th 8bit of rs1+Imm)
B01 = 2nd 8bit of @(4th 8bit of rs1+Imm)
B02 = 3rd 8bit of @(4th 8bit of rs1+Imm)
B10 = 4th 8bit of @(4th 8bit of rs1+Imm)
B11 = 5th 8bit of @(4th 8bit of rs1+Imm)
B12 = 6th 8bit of @(4th 8bit of rs1+Imm)

C0 = 1st 16bit of rs2
C1 = 2nd 16bit of rs2

ShiftMount = (funct7[6:5]==0) ? 0 : 2^(funct7[6:5]-1)
IP0 = ((A0*B00+A1*B01+A2*B02)>>(ShiftMount))+C0
IP1 = ((A0*B10+A1*B11+A2*B12)>>(ShiftMount))+C1
[追記 ここは飽和演算にするのが良い気がしてきた。]

rd = {IP0,IP1}

BNN コアには上の結果を2個のaccレジスタに読み込む命令を追加すれば、その先のプーリングにつながると思います。

[PR]
by tom01h | 2018-02-22 20:27 | PCとか | Trackback | Comments(0)
PULP プロジェクト が凄くたくさん更新されていました。
本家 UCB と違って、こっちは SystemVerilog 記述なのがとっても嬉しいところです。
ただ、高度すぎる SystemVerilog 記述を使っているようで、Verilator や Yosys ではサポートされていないところもあるようですが…

CPUコアは、従来の RI5CY,zero-riscy に加えて Ariane が追加されました。
名前は、欧州で共同開発しているロケットからきているのかな?
Arianeは、64ビットのRISC-V命令セットを実装する6段パイプラインの単一命令発行のインオーダーCPUです。
って書いてあるけど、どう見てもアウトオブオーダなんですがそれは…
演算パイプが1段しかないのが気になりますが、ここは必要に応じて伸びていくのかな?
今のところ FPU は載っていないみたいですが、これはこれで 開発中 の模様。
[追記 このFPUはRI5CY用かも。単精度専用だしね。]

サブシステムは、従来の PULPino に加えて(代えて?) PULPissimo が追加されています。
PULPissimoは、メモリをRI5CYコアと共有し、メモリマップ上にプログラムされたハードウェアアクセラレータ(ハードウェア処理エンジン)の統合もサポートしています。
アクセラレータのサンプルは、どいつもこいつも感がありますが、Hardware MAC Engine のサンプルがあるようです。
ここ にあるドキュメントが参考になるのかな? こっち にも依存している模様。
正直なところ、Rocket のアクセラレータインタフェースのような疎結合アクセラレータなら、命令追加の Rocket 方式よりも、メモリマップしたこっちの実装のほうが好きです。

[PR]
by tom01h | 2018-02-21 20:10 | Trackback | Comments(0)
昨日も書いたように、8bit乗算結果3個を足しこむ内積演算器を使ったアクセラレータ化を考えています。
まずは回路遅延も回路規模も気にせずに正しく計算できることを確かめるバージョン。
内積演算器を32個も積み込んでいます。
演算精度不足なのか、どちらかのバグなのか?
昨日作ったcのプログラムの認識精度は71.8%でアクセラレータを使うと71.9%です。
間違う場所も結構違っている模様…

[PR]
by tom01h | 2018-02-20 23:00 | Trackback | Comments(0)
前回は第1層をアクセラレーション対象外にしたことで、推論アクセラレータの効果が面白くない結果に終わってしまいました。そんなわけで、第1層もアクセラレータに対応すべく、探りを入れてみます。
ハードウエア構成に関しては、あまり細かなところまでは考えていないのですが、32bit乗算器をちょっと改造することで、8bit乗算3個を足しこむ内積演算を2個並列実行できる予定です。
まぁ、zero-riscy は32bit乗算器を持っていない(16bit乗算器を4回使う)ので、まずはそこからの改造になるのですが、その前に第1層を8bit乗算としても精度を維持できるのかを探ってみました。
結果、認識精度は72.3%から71.8%へ低下しました。まあこの程度なら、このまま進めてみようかと思います。

[PR]
by tom01h | 2018-02-19 23:20 | Trackback | Comments(0)

LED 蛍光灯

こっちは蛍光灯だけ交換するタイプ。点灯管を外します。安定器をバイパスするとより低消費電力になるらしいですが面倒なので…
f0054075_10355234.jpg
[追加 amazonを見ているとすごく明るくなったってコメントとあまり変わらないってコメントが両方あるけど、自分の感覚ではあまり変わらないように感じました。]

[PR]
by tom01h | 2018-02-18 13:35 | Trackback | Comments(0)
zero-riscy の vivado ip 化が出来たので、今度は ARTY Z7 の Zynq の上で動くようにしたいと思います。
下の図のように、Zynq PS の UART を使います。なんでこんな面倒なことをするかというと、PL に作った UART からでは、MIO ポートに接続された ARTY Z7 ボード上の USB-UART を使えないためです。PMOD に USB-UART 拡張基板をつないで、PC とはプログラム用と UART 用の 2本の USB をつなぐなんてスマートじゃないですからね。まぁでも、Zynq で Arm を使わないっていうこと自体が…
f0054075_23472547.png
ブロックデザインは下みたいな感じ。この構成で DDR にアクセスできそうな気がしないでもないですが、まだ試していません。[追記 HP か ACP につながないと無理だよね。]
f0054075_23501551.png
これですんなり動くと思ったのですが甘かった…
どうやら、PS の設定用のプログラムを自前で用意しないといけないらしいです。TRM を読みながら頑張ってみたけど無理でした。
で、一度 SDK で作った Hello World プロジェクトを実行後に、もう一度 Bitstream を書き込んであげる方法を試してみると動きました。
ps7_init.c を zero-riscy 上で実行すればこんな手順要らなくなるのかな?まぁ、ちょっと面倒だけど、まずはこのままでいい事にしておくか。

[PR]
by tom01h | 2018-02-17 23:59 | PCとか | Trackback | Comments(0)
zero-riscy を ARTY 用に合成すると、100MHz ターゲットで 6ns 以上の違反が出ます。まぁ、実際は動いちゃうみたいですが、対策を考えてみました。
vivado のタイミングレポートはとっても見難いのですが、どうやら aluの加算器を除算の時にも使っているのが原因の模様。multdiv で作ったオペランドが alu に入って、(加算器を共有しているために)条件分岐の判定結果を経由して SRAM まで行きます。面積削減が目的なのでしょうが、ここをワーストにするのはちょっと格好悪い気がするので、multdiv の中に加算器を持ってしまうことにしました。
結果、乗算器を通るパスがぎりぎり 4ns を切れないくらいのワーストパスに。乗算器は BNN アクセラレータ命令のついでに全面見直しをしようと思います。

[PR]
by tom01h | 2018-02-16 22:26 | PCとか | Trackback | Comments(0)