タグ:V-scale ( 52 ) タグの人気記事

FDIV モデル 2

FDIV のモデルを作ります。整数除算と丸めはすでに持っているので、くっつけるだけで簡単にできると思っていました。実際、正規化数を扱っているだけなら、今まで作った部品のコピペで出来ました。
また、サブノーマルの出力の方はそれほど難しくなく、すでに持っているサブノーマル出力機能付きのノーマライザを通すだけで出来ます。回路化するときはどうせ共有する部品ですし。
入力はちょっと難しいですが、整数除算を高速化するためのプレシフタとの共通化を視野に入れて考えます。
まず条件として、被除数が大きすぎて除数を引いた後の部分剰余がまだ、除数よりも大きいままだと除算が成立しません。被除数が小さすぎる分には、必要な精度を得るためのループ数が多くなるだけです。それを前提として、回路を節約するために8bit単位の荒いプレシフトをすることにしました。
途中で桁が足りなくなったりして苦労しましたが、とりあえずモデルは完成しました。回路化するときに、もう一度見直そうと思います。

[PR]
by tom01h | 2017-07-08 23:18 | PCとか | Trackback | Comments(0)

FDIV モデル

久々ですが、FPU演算器のモデル設計を再開します。次は FDIV です。整数除算も出来ているし、丸めも別に作っているので、コピペだけで簡単にできました。サブノーマルのことを考えなければ…
ということで、中途のを GitHub に置いておきました。
しかし、サブノーマル入力はどうすればよいのだろうか?
最悪、被除数はそのままでもループ回数さえ増やせば大丈夫なはず。でも、除数が小さいと無理だよねぇ。プレシフト必要かな?整数除算でも使える方式を考えてみるか。
出力はサブノーマル出力ができるノーマライザに、右詰めで答えを入力すれば良いと思います。

[PR]
by tom01h | 2017-07-06 22:42 | PCとか | Trackback | Comments(0)

Vscale-chip 修正

こんな感じに変更します。もともとHREADYは1サイクル遅れで返して、その場合はXbar内に保持したリクエストに差し替えていました。のつもりがあれ?そんな論理どこにも無いぞ??そうするつもりでまだやっていなかったのか?そりゃ動くはずがない。
f0054075_18471537.png
いやいや、ほかにもいろいろ変だぞ。V-scale は HREADY ネゲートのサイクルで前のリクエストを再送している。こんな感じで普通に動いていました。HREADYの次のサイクルに再送じゃないのか?上の図で合っているよね?
f0054075_18500259.png
そんなわけで、Xbar は HREADY を1サイクル早くして、V-scale の中は HREADY を1サイクル遅らして、プロトコル通りになりました。そして命令フェッチストールが1サイクル余分に出る件は、該当論理を削除しただけで一応動いているみたいです。
これで一応、バス周りの既知バグはなくなりました。わかってみると簡単な話ですが、チップのシミュレータを作ったからこそ発見できたのではないかと思います。また、例外キャンセルもめちゃくちゃですが、こっちは見なかったことにします。
元の論理がかなり混乱しているうえに、さらに適当な修正をしたのでめちゃくちゃになってしまっています。というか、今でも原作者の意図は理解できていません。今の構成はスレーブがHREADYを落とすことがないので、それには対応できないかもしれんせん。もう、他人の物は捨てて、1から作り直そうかなぁ。

[PR]
by tom01h | 2017-07-02 00:41 | PCとか | Trackback | Comments(0)
V-scale のコア外は Vivado に任せてみようと思った目論見は失敗に終わりました。AHB Xbar を自力で直すしかないみたいです。
AHB Xbar が難しいことになっているのは、無駄にタイミングを気にしているせいだと気づきました。マスタ→バス→スレーブの転送は許しているのに、マスタ→バス→マスタの調停の信号は1サイクル転送を許していません。このせいでXbarの設計が無駄に難しくなっています。設計を簡単にするために、調停の信号も1サイクル転送を許せばよいかと。
がしかし、HREADYは多分受けてから結構いっぱい使っているよなぁ。遅くなるのは必至です。これはV-scaleを直すべきか?うだうだ考えていたら、リクエストホールド用のREADYとリードデータ用のREADYが混ざっているのが悪いのではないかとの考えに至る。AXI Lite にするとARREADY と RVALID に分かれるのでタイミング設計がしやすくなるかも?

[PR]
by tom01h | 2017-06-26 20:57 | PCとか | Trackback | Comments(0)
続きです。
スレーブIPを2個にしてみました。
f0054075_23511737.png
が、シミュレーションに反映されませんよ。Generate Output Products とやらを選ぶのかな?かなり悩んで試行錯誤の結果、やっと出来るようになったけど…
f0054075_22003597.png
おせ~~~~ なんじゃこりゃ?こんなにレイテンシでかいんじゃ、お手軽自動生成のインターコネクトはめったな事じゃ使えませんねぇ。仕様書にもちゃんと、リクエストのレイテンシは2サイクルって書いてありました。使うの諦めましょう。

[PR]
by tom01h | 2017-06-25 00:48 | PCとか | Trackback | Comments(0)
次のPDFファイル Vivado IP インテグレーターへのカスタム AXI IP の組み込み に従って、AXI Lite のマスタとスレーブIPを作ってみます。vivado のバージョンが違うのでいろいろ違うけど、細かいことは気にしないで進みます。
1つのフォルダで複数のIPを作ると上手く行かない?まぁ、普通はそんな事しないと思うので、IP毎にフォルダを分けてみましょう。
vivadoip/ ← IPを使ってみるプロジェクト用のフォルダ
vivadoip/axi_lite_slave/ ← axi_lite_slave IP 用のフォルダ
vivadoip/axi_lite_master/ ← axi_lite_master IP 用のフォルダ
出来ました。
f0054075_13011785.png
最初は自動で連結してもらったんだけど、バスとか、リセット・クロックコントローラとかいっぱい生成されて大変なことになったので、手で繋ぎなおしました。ちなみにリセットの極性を間違えていたのですが、シミュレーションする以前から、これ反対なんじゃない?って指摘してきました。すげーなぁ。
して、シミュレーションもPDF通りに進めて行けば出来ます。Vivado Simulator は使い慣れないんですが…
f0054075_13281717.png

なんか遅い。これ参考にしちゃうと、すごく遅いIP作りそうだ… 勉強するのもめんどいしなぁ。
ひとまず適当にマスターのライトを速くしてみた。IPを修正しても、全体のプロジェクトには簡単には反映されないみたい。いろいろ試した結果、IPのプロジェクトも開いておいて、変更したら Re-Package IP を押す。全体のプロジェクトでシミュレーションを閉じると、Refresh IP Catalog を押せって言ってくるので押す。更新した IP を選択して、Upgrade Selected を押す。そのあと、シミュレーションのやり直し。
2サイクルかかるのは、スレーブのせいだと思います。ラッチが推論されている気がするけどまぁ良いよね。
f0054075_16541149.png
Vivado 17.2 が出てますね。ダウンロード中…

[PR]
by tom01h | 2017-06-24 17:34 | PCとか
コンパイル後にいろいろと変更するのは格好悪いので…
--- a/bsp/env/freedom-e300-hifive1/link.lds
+++ b/bsp/env/freedom-e300-hifive1/link.lds
@@ -4,6 +4,7 @@ ENTRY( _start )
MEMORY
{
+ spi (rxai!w) : ORIGIN = 0x00400000, LENGTH = 512M
flash (rxai!w) : ORIGIN = 0x20400000, LENGTH = 512M
ram (wxa!ri) : ORIGIN = 0x80000000, LENGTH = 16K
}
@@ -22,7 +23,7 @@ SECTIONS
.init :
{
KEEP (*(SORT_NONE(.init)))
- } >flash AT>flash :flash
+ } >flash AT>spi :flash
以下同様に AT> を変更。最後の1行を取っ払うのはこうかっ。
--- a/bsp/env/common.mk
+++ b/bsp/env/common.mk
@@ -25,11 +25,12 @@ INCLUDES += -I$(PLATFORM_DIR)
TOOL_DIR = $(BSP_BASE)/../toolchain/bin
-CC := $(TOOL_DIR)/riscv32-unknown-elf-gcc
-AR := $(TOOL_DIR)/riscv32-unknown-elf-ar
+CC := riscv32-unknown-elf-gcc
+AR := riscv32-unknown-elf-ar
LDFLAGS += -T $(LINKER_SCRIPT) -nostartfiles
LDFLAGS += -L$(ENV_DIR)
+LDFLAGS += -e 0 ← これ


[PR]
by tom01h | 2017-04-11 00:13 | PCとか | Trackback | Comments(0)
ソフトは論理のリポジトリには含まれてないんじゃないかと疑い始めました。ソフト用のリポジトリ が別にあるようです。
git clone --recursive https://github.com/sifive/freedom-e-sdk.git
またしても gnu-tools を取りに行くので途中で止めます。自前のコンパイラを使わないで済ますためのオマジナイ。
--- a/bsp/env/common.mk
+++ b/bsp/env/common.mk
@@ -25,8 +25,8 @@ INCLUDES += -I$(PLATFORM_DIR)
TOOL_DIR = $(BSP_BASE)/../toolchain/bin
-CC := $(TOOL_DIR)/riscv32-unknown-elf-gcc
-AR := $(TOOL_DIR)/riscv32-unknown-elf-ar
+CC := riscv32-unknown-elf-gcc
+AR := riscv32-unknown-elf-ar
V-scale 用に作ったコンパイラは rv32im なので、a 拡張付きで作り直します。
./configure --prefix=/opt/riscv --with-arch=rv32ima --with-abi=ilp32
sudo make
a を付けるだけなら vscale-chip と共存できると信じてます。
make して software/demo_gpio に移って Intel Hex に変換します。
make software PROGRAM=demo_gpio BOARD=freedom-e300-arty
cd software/demo_gpio
riscv32-unknown-elf-objcopy -O ihex demo_gpio demo_gpio.ihex
これを mcs ファイルの後ろにくっつけるのですが、”:00000001FF” はファイル終了マークなので削除してから連結します。で書き込んでみると… 動かん。ちょっと変更してみると動きました。00400000 が QSPI のローカルアドレスで、 20400000 がシステムから見たアドレスになるのだと思います。最後の1行は必要なさそうなので取っちゃいました。
1c1
< :020000040040BA
---
> :0200000420409A
4098c4098
< :020000040041B9
---
> :02000004204199
5834a5835
> :040000052040000097
[追記 この手変更は 明日の記事 で解決します]
ビルド済みの mcs とは、少しだけ動きが違うようです。
f0054075_22025507.png
同じ要領で dhrystone を試してみたのですが、残念ながら、キー入力を待たないようです。で、デフォルトのループ回数は大きすぎるようなので変更しました。
--- a/software/dhrystone/dhry_stubs.c
+++ b/software/dhrystone/dhry_stubs.c
@@ -11,5 +11,6 @@ long time(void)
// set the number of dhrystone iterations
void __wrap_scanf(const char* fmt, int* n)
{
- *n = 100000000;
+//*n = 100000000;
+ *n = 100000;
}
流してみると…
Dhrystone Benchmark, Version 2.1 (Language: C)
Program compiled without 'register' attribute
Please give the number of runs through the benchmark: ← ここで入力を待ってくれない
Execution starts, 100000 runs through Dhrystone
Execution ends
Final values of the variables used in the benchmark:

Microseconds for one run through Dhrystone: 40.0
Dhrystones per Second: 25000.0

Progam has exited with code:0x00000000
[追記
ちなみにビルド済みの mcs を編集して自前プログラムを走らすには、ビルド済みの mcs から プログラム部分を削除する必要があります。

まずは、mcs (Intel HEX フォーマット) ファイルの解析。
mcs は巨大すぎるので、データの行を取っ払って見通しをよくします。

grep -v ":10" freedom-e310-arty-1-0-2.mcs | less

:020(正確には:02000004)で始まるのがベースアドレスを指定する行

で、:020000040040BA 以降がプログラム部分で、それ以前が回路部分です。
プログラム部分を自前のプログラムと差し替えます。

ちなみにこれはブートアドレスが20400000の場合で、QSPIのベースアドレスを引いたアドレスが00400000で、この指定が:020000040040BAです。]

[PR]
by tom01h | 2017-04-10 00:47 | PCとか | Trackback | Comments(0)
WSL が新しくなっているかもしれないので、chisel のテストも兼ねて Freedom E310 を作ってみます。
Arty 用の E310 のマニュアルは ここ。論理は GitHub
sudo apt install default-jre
sudo apt install default-jdk

git clone https://github.com/sifive/freedom
cd freedom/
git submodule update --init --recursive ← 途中(riscv-tools)で止めたけど
make -f Makefile.e300artydevkit verilog
おや?Verilog 出てるぞ。WSL の問題、修正されたのかな?
調子に乗って FPGA 用のビルドも試してみます。Vivado は Windows 用を使うので、~/bin/vivado のシェルスクリプトを作ってみました。
cmd.exe /C C:\\Xilinx\\Vivado\\2016.4\\bin\\vivado.bat $*
環境変数がないって怒られました。ちょっと強引ですが、vivado に
cmd.exe /C C:\\Users\\tom01\\bin\\vivado.bat $*
vivado.bat に
set VSRC_TOP=c:\Users\tom01\RISC-V\freedom\builds\e300artydevkit\sifive.freedom.everywhere.e300artydevkit.E300ArtyDevKitConfig.v
set EXTRA_VSRCS=C:\Users\tom01\RISC-V\freedom\rocket-chip\vsrc\AsyncResetReg.v c:\Users\tom01\RISC-V\freedom\rocket-chip\vsrc\DebugTransportModuleJtag.v c:\Users\tom01\RISC-V\freedom\sifive-blocks\vsrc\SRLatch.v
call C:\Xilinx\Vivado\2016.4\bin\vivado.bat %*
で、ビルドが出来たみたいです。
つぎに Arty で流してみます。参考にしたのはいつもお世話になっている ここ。動きませんよ。仕方がないので、SiFive の ビルド済みファイル で試してみるとちゃんと動きました。差分を確認してみたところ、ほかにも細かな違いはありますが、大きくは ”:020000040040BA” 以降のデータが自作の方にはごっそり無いみたいです。たぶん論理はちゃんとできたけど、プログラムがないのだと思います。強引ですが、ここら辺の足りない分をコピーしてリトライするとちゃんと動きました。git submodule update を途中で止めちゃったのがいけないのでしょうね。だってとっても時間がかかるんですよ。

[PR]
by tom01h | 2017-04-09 21:33 | PCとか | Trackback | Comments(0)

Vostro にも RISC-V

Creators Update に合わせて、主力のデスクトップにも RISC-V 環境を構築中です。ついでに、Vivado も ModelSim も最新にしようかと思います。
で、ひとつ大事なことに気付きました。巨大な波形ファイルを作ると、ウイルス監視ソフトが頑張り過ぎちゃうみたいです。Verilator を使って vscale-chip をシミュレーションすると、一気に数百メガのファイルを吐き出します。それが原因か定かではないのですが、シミュレーションが終わってからプロンプトが出るまでにとっても時間がかかる。Inspiron でやっていたときは、Defender が勝手に止まっていたみたいです。Defender には監視除外の指定ができるみたいなので、フォルダごと監視から除外の指定をしちゃいました。
それにしても、やっぱり速いPCは良いなぁ。

[PR]
by tom01h | 2017-04-08 14:35 | PCとか | Trackback | Comments(0)