 |
12 |
RISC-Vの調査 (4) |
 |
シミュレーションモデルの波形を観測してみます。テストプログラムは、\$80000000から始まっていますが、シミュレーションは\$1000から始まっています。これはBootROMのようです。BootROMのブロックインが19サイクルかかっています。
図275.1はGtkwaveによるシミュレーション波形で、pcをオレンジ色で塗っています。
Posts Tagged with "Design"
既に発行済みのブログであっても適宜修正・追加することがあります。We may make changes and additions to blogs already published.
|
11 |
RISC-Vの調査 (3) |
|
前々稿の記事において、シミュレーションモデルが生成できましたが、これを実行させてみます。
テストプログラムは、add命令単体テストで、
80000000 <_start>: 80000000: 04c0006f j 8000004c <reset_vector> 8000004c <reset_vector>: 8000004c: f1402573 csrr a0,mhartid 80000050: 00051063 bnez a0,80000050 <reset_vector+0x4> 80000054: 00000297 auipc t0,0x0 80000058: 01028293 addi t0,t0,16 # 80000064 <reset_vector+0x18> 8000005c: 30529073 csrw mtvec,t0 80000060: 18005073 csrwi satp,0 : 80000100 <test_2>: 80000100: 00000093 li ra,0 80000104: 00000113 li sp,0 80000108: 00208f33 add t5,ra,sp 8000010c: 00000e93 li t4,0 80000110: 00200193 li gp,2 80000114: 4ddf1663 bne t5,t4,800005e0 <fail> 80000118 <test_3>: 80000118: 00100093 li ra,1 8000011c: 00100113 li sp,1 80000120: 00208f33 add t5,ra,sp 80000124: 00200e93 li t4,2 80000128: 00300193 li gp,3 8000012c: 4bdf1a63 bne t5,t4,800005e0 <fail> :
のように構成されています。Bsimによるシミュレーションは、+v1で命令トレースが、+v2でパイプラインステージの内容を表示させるようになっています。+v2で実行させた結果をgrepにより計数してみると、表274.1のようになりました。パイプラインの各ステージの出力ステータスの意味は、以下のとおりです。
- EMPTY --- 入力が来ないためアイドルとなっている
- BUSY --- 入力があるが、処理中で出力がレディではない
- PIPE --- 入力があり、パイプラインは正常な出力を行っている
- NONPIPE --- 入力があり、出力は例外的な場合(トラップ等)
| 状態 | StageF | StageD | Stage1 | Stage2 | Stage3 |
|---|---|---|---|---|---|
| BUSY | 1,118 | 0 | 23 | 26 | 0 |
| EMPTY | 22 | 1,094 | 959 | 1,373 | 1,409 |
| PIPE処理 | 743 | 789 | 901 | 484 | 474 |
| 合計 | 1,883 | ||||
- 試験命令数は473命令だったので、CPI(Cycles Per Instruction)は3.98となりました。命令キャッシュミスのためにかなり大きく(悪く)なっています。
- マシンサイクル1,883サイクルのうち、実際に処理しているのは半分くらいであり、主なパイプラインストールは命令キャッシュによるものだと考えられます。
- StageFがBUSYの分だけStageD以降がEMPTYとなり、空いています。すなわち約1,100サイクルがパイプラインバブルとなっています。
- Stage1に対してStage2のPIPE処理が半分なのは、ロードストア命令が半分(レジスタとロードストアが1:1)くらいだからかもしれません。
- StageDに対してStage1のPIPE処理が増加しているのは、マルチサイクル命令のためかもしれません。
これだけ見るとかなり効率が悪そうですが、対象がテストプログラムでループが無いため、基本的にキャッシュミスが頻発します。一般のアプリケーションのようにループがあれば、ずっと効率が向上するはずです。
|
10 |
RISC-Vの調査 (2) |
|
Fluteの階層構造
CPUの階層構造を図273.1に示します。5段のパイプラインは図273.1に示すように、"F"(命令Fetchステージ), "D"(命令デコードステージ), "1"(命令実行ステージ), "2"(メモリアクセス、長レインテンシステージ), "3"(ライトバックステージ)とステージ名が付けられています。なぜステージ"1”,"2",...,"5"でないかと言えば、3段パイプラインのPiccoloとステージを共用しているため書かれていました。Piccoloではパイプラインステージは”1", "2", "3"と名付けられており、Fluteでは、Piccoloの"1"を"F", ”Ｄ”, "1"に分解したようです。
各モジュールがmk〇〇と名付けられているのはBSVのお作法です。モジュールとそのインスタンスは一対nの関係にあり、モジュール名はいわばテンプレート名を意味するため、モジュールからインスタンスがmakeされるということを表しています。例えば上図のmkMMU_Cacheはどちらも同じモジュールですが、それぞれ命令用とデータ用に2個インスタンシエートしています。
キャッシュは上記のように、パラメタライズ可能な命令キャッシュ、データキャッシュの2つがあります。その他に、分岐予測器があります。
|
9 |
RISC-Vの調査 |
|
BluespecのFluteプロセッサ
BluespecのBSVが読めるようになったところで、引き続いてFluteプロセッサの調査を行います。FluteはBluespecの開発したRISC-Vアーキテクチャの5段パイプラインRISC CPUです。それだけでなく、仮想記憶をサポートしているため、Linuxが動作します。(ページ)テーブルウォークはMMU内のハードウェアが実行します。ソースではステートベース設計のFSMで実装されていました。
Githubからダウンロード
$ git clone https://github.com/bluespec/Flute.git
としてGithubからダウンロードします。
RV32ACIMUアーキテクチャのBsimモデルの作成
アーキテクチャには各種ありますが、比較的軽いもの、例えば32bit、Floating無しのマイクロアーキテクチャを選択します。
$ cd builds/RV32ACIMU_Flute_bluesim
として、ターゲットディレクトリに移行します。
$ make all
と実行すると、
: Simulation shared library created: exe_HW_sim.so Simulation executable created: ./exe_HW_sim INFO: linked bsc-compiled objects into Bluesim executable $
このように、bsvで書かれたソースファイルがbscによりコンパイルされ、シミュレーションモデルであるexe_HW_simが生成されます。
RV32ACIMUアーキテクチャのBsimモデルの試験
$ make test
により、出来上がったシミュレーションモデルが、RISC-Vのテストスイートによりテストされます。
$ make test
make -C ../../Tests/elf_to_hex
make[1]: Entering directory '/home/sakurai/src/bsv/riscv/Flute/Tests/elf_to_hex'
make[1]: 'elf_to_hex' is up to date.
make[1]: Leaving directory '/home/sakurai/src/bsv/riscv/Flute/Tests/elf_to_hex'
../../Tests/elf_to_hex/elf_to_hex ../../Tests/isa/rv32ui-p-add Mem.hex
c_mem_load_elf: ../../Tests/isa/rv32ui-p-add is a 32-bit ELF file
Section .text.init : addr 80000000 to addr 80000604; size 0x 604 (= 1540) bytes
Section .tohost : addr 80001000 to addr 80001048; size 0x 48 (= 72) bytes
Section .riscv.attributes: Ignored
Section .symtab : Searching for addresses of '_start', 'exit' and 'tohost' symbols
Writing symbols to: symbol_table.txt
No 'exit' label found
Section .strtab : Ignored
Section .shstrtab : Ignored
Min addr: 80000000 (hex)
Max addr: 80001047 (hex)
:
================================================================
Bluespec RISC-V standalone system simulation v1.2
Copyright (c) 2017-2019 Bluespec, Inc. All Rights Reserved.
================================================================
INFO: watch_tohost = 1, tohost_addr = 0x80001000
1: top.soc_top.mem0_controller_axi4_deburster::AXI4_Deburster.rl_reset
2:top.soc_top.rl_reset_start_initial ...
3: Core.rl_cpu_hart0_reset_from_soc_start
================================================================
CPU: Bluespec RISC-V Flute v3.0 (RV32)
Copyright (c) 2016-2020 Bluespec, Inc. All Rights Reserved.
================================================================
6: D_MMU_Cache: cache size 8 KB, associativity 2, line size 32 bytes (= 8 XLEN words)
6: I_MMU_Cache: cache size 8 KB, associativity 2, line size 32 bytes (= 8 XLEN words)
512: top.soc_top.core.cpu.rl_reset_complete: restart at PC = 0x1000
514: Near_Mem_IO_AXI4.set_addr_map: addr_base 0x2000000 addr_lim 0x200c000
514: Core.rl_cpu_hart0_reset_complete
515: Mem_Controller.set_addr_map: addr_base 0x80000000 addr_lim 0x90000000
515:top.soc_top.rl_reset_complete_initial
instret:0 PC:0x1000 instr:0x297 priv:3
instret:1 PC:0x1004 instr:0x2028593 priv:3
instret:2 PC:0x1008 instr:0xf1402573 priv:3
:
instret:471 PC:0x80000044 instr:0xfc3f2023 priv:3
instret:472 PC:0x80000048 instr:0xff9ff06f priv:3
instret:473 PC:0x80000040 instr:0x1f17 priv:3
2396: Mem_Controller.rl_process_wr_req: addr 0x80001000 (<tohost>) data 0x1
PASS
2397: top:.rl_terminate: soc_top status is 0x1 (= 0d1)
Simulation speed: 2396 cycles, 60915008 nsecs = 39333 cycles/sec
テストスイートのelfを、elf_to_hexにより、asciiのメモリイメージファイルに変換しています。
これはadd命令単体のテストですが、全てのテストを行うには、以下のように実行します。
$ make isa_tests
と実行すると、
: Worker 1: Test: rv32um-p-mul PASS [So far: total 67, executed 34, PASS 34, FAIL 0] Worker 0 executed 33 tests, of which 33 passed Worker 1 executed 34 tests, of which 34 passed Total tests: 67 tests Executed: 67 tests PASS: 67 tests FAIL: 0 tests Finished running regressions; saved logs in Logs/
のように出力され、67個全てのテストが実行され、全てパスしたことが表示されます。
|
5 |
ゲームFSMとサウンドFSMの連携 |
|
Ultra96においてBSVで開発
元々Verilog版では、コマンドバッファに書き込むだけで特に何もしなくても動作していました。今回BSVで再設計する際に、サウンドを4chとし、取りこぼしを避けるために考えたのがサウンドキュー(FIFO)でした。
これはVivadoのFIFOジェネレータで作成したため、最小段数でもかなり深く1024段程度となっています。 実験したところ、確かに取りこぼしは無いのですが、一方、サウンドがゲームとズレて行き、まるでサウンドレコーダのような動作になってしまいました。そのため、FIFOを1段に修正しました。FIFOジェネレータでは1段のFIFOは作成できないのでVerilogで記述しました。1段のためFIFOと呼ぶのはおかしいのでコマンドバッファと呼ぶことにします。
コマンドバッファには、ゲームFSMからコマンドが来たことを示すフラグemptyを設け、書き込むと!emptyとなるようにします。サウンドFSMからは!emptyの時に新たにコマンドが来たと判断し、コマンドを読んだ後にemptyに変更します。
Artyボード移植後
Ultra96ではこれで動作していたのですが、Artyボードに移植後に自機増加音が無視されることに気づきました。サウンドFSMが取りこぼしているのだと推測し、再考すると、ゲームFSMが不必要に速いことに気づきました。DSOを接続して調べたところ、96.4%がウェイトだと判明したので、これを1MHzに落としたところ、動作するようでした。
ところが実験すると、依然として自機増加音(コマンドNo.9)が無視されるようです。そこで、ILAを接続して、
- サウンドコマンド
- サウンドFSMステート
- コマンドバッファemtpy
- サウンドFSM内部フラグ(fNO9)
を観測しました。最後の内部フラグfNO9は自機増加音がプリエンプトされないように割込みを禁止するためのフラグで、コマンドNo.9を受け付けた際にTrueになる信号です。
従って、コマンドの書き込みの際にemptyである場合のみ書き込み、!emptyの場合は捨てる処理を行います(図271.4のマゼンタ矢印の処理を追加)。
QSPIフラッシュへの書き込み
通常ではVivadoからPROGRAM AND DEBUG⇒Open Hardware Manager⇒Open Target⇒Auto Connectとし、Program DeviceによりJTAG経由でFPGAにビットストリームを焼きこみます。しかしながらこれだと電源断によりFPGAのSRAM内容が消えてしまいます。また、FPGAプログラミング用のPCが常に必要です。オンボードFlashにデータを焼きこめばPCを持ち運ぶ必要がなく、電源onでアプリケーションが立ち上がるため、Flashのプログラミングを行います。
binファイルの作成
最初にFlashへ書き込むデータファイルであるbinファイルを用意します。これは、Tools⇒Setting(歯車マーク)⇒Project Settings⇒Bitstream画面で行います。この画面を開くと複数のチェックボックスが表示されます。その中の、-bin_file*のチェックボックスにチェックします。
これを行ってから、通常どおりPROGRAM AND DEBUG⇒Generate Bitstreamを実施するとWrite Bitstreamが完了しますが、同時にbinファイルが生成されています。場所はbitファイルと同じところで'プロジェクト/プロジェクト.runs/impl_1/'です。
binファイルの焼きこみ
binファイルができたら、Add Configuration Memoryにより、Add Configuration Memory Device画面が開きます。Flashデバイスの選択が可能なので、この中で"s25fl128sxxxxx0"を選択します。Search窓にs25fl128を入力すれば、候補が3つ現れますがその真ん中です。
実行
リファレンスマニュアルにはJP1でプログラミングモードが決まるとあります。JP1の位置がどちらでもJTAGからは書き込めるとのことです。初期状態はJP1はショートで、SPI-FLASHのモードとなっており、そのまま電源のOFF⇒ONでSpace Invadersが立ち上がりました。
Arty A7-35ボードの購入
DigilentからArty A7-35ボード(魚拓)を購入しました。このボードはUltra96と比べて本体が約半額と安いだけでなく、(弊社開発の)PMOD変換ボードも不要なので、最も安くSpace Invadersを動かすことができます。
必要な周辺
Space Invadersを動作させるには、Artyボードの他に必要なものは以下のとおりです。
- 12V電源
- PMOD I2Sインタフェース(オーディオDAC)カード
- オーディオケーブル
図269.1 PMOD I2Sインタフェースとケーブル - アンプ付きミニスピーカ
図269.2 アンプ付きミニスピーカ - PMOD VGAインタフェースカード
- VGA/HDMIインタフェース
図269.3 PMOD VGAインタフェースとVGA/HDMIインタフェース - VGA/HDMIインタフェース用5V電源
- HDMIケーブル
- PMOD JOYスティック・スイッチインタフェース(弊社開発)
図269.4 PMOD JOYスティック・スイッチインタフェース - JOYスティック・スイッチ(弊社開発)
図269.5 JOYスティック・スイッチ - Micro-B USBケーブル
図269.6 Micro-B USBケーブル 図269.7に、これら周辺を全て接続したArtyボードの写真を示します。
図269.7 Artyボードに周辺を接続
Arty A7-35ボードへの移植
除算器を引き算に変換
FPGAの世代や遅延、容量は違うものの、基本的には同様に動作するはずです。ところが、一部動作がおかしかったので修正しました。まず、除算器にバグがあるようなので引き算方式に修正しました。スコアを表示する箇所において、各桁表示のため1000、100、10で割る場合がありますが、1000で割った商を誤ることがあるようです。除算をやめ、引けなくなるまで1000、100、10を引く方式に変更したところ、回路規模も小さくなり正常に動作するようになりました。
FSM clockを1/10に変更
ゲームFSMクロックを10MHzで設計し、96.4%がウェイトだと判明したので、FSMクロックを1MHzに落としました。自機増加音が無視されることがあるので、クロックを落としたのですが、原因は異なっていました(後述)。
60Hzクロックの生成
この修正により、FSMの待ち時間が影響を受けます。1tick=60HzのタイミングをとるのにFSMクロック数を数えていましたが、FSMクロックの周波数が変わるため、外部から60Hzを入力するように修正します。60Hzクロックは、上記FSMクロックである1MHzクロックをバイナリカウンタで\$411B回カウントすることで生成します。さらにFSM内での60Hzクロックとの同期は以下のように行います。countはtick(=16.67msec)の何倍待たせるかを示す引数です。
repeat(pack(extend(count))) seq
await(tick == 0);
await(tick == 1);
endseq
60Hzクロックの"L"を待ち、もし"L"であれば次に"H"を待つようにします。これにより60Hzの立ち上がりに同期して動作することになります。
このように変更した結果、FSMの処理時間は10倍の約5msecに増加し、60Hzの周期16.67msecの約30%になりました。図269.2の黄線が60Hzクロック、青線がそれによる実行(Hでウエイト中、Lで実行中)を示します。
|
2 |
FM-7 Z80カードの調査 (3) |
|
引き続き、Z80コネクタへの信号を解説します。また、Z80CPUの高速化に伴い、Z80⇒6809切り替え時にDRAMのRASプリチャージタイム不足が判明したため、その対策も取っています。
EB
EBはZ80のMREQに相当する信号のため、前稿でのライト信号(=$\text{R/}\overline{\text{W}}$, M5 5pin)とCPUの$\overline{\text{RD}}$の負論理ORを取り、EBとしています。信号名は6809のE信号のバッファしたもの(E Buffered)から来ています。
QB
QBは立ち上がりはアドレス有効を示す信号です。また、6809の場合はQBの立下りでデータ確定しますが、Z80は$\overline{\text{WR}}$の立ち下がりでデータ確定します。そのため$\overline{\text{WR}}$の反転をQBとして使用する場合、その考慮が本体DRAM側で必要となります。その理由からFM-7メインボードのDRAMの回路図では、Z80と6809でQBの論理を反転させています。信号名は6809のQ信号のバッファしたもの(Q Buffered)から来ています。
RWB
RWBは、前述のライト信号を後縁を広げてRWBとしています。またデータバスバッファのDIRも後縁を広げて制御しています。この理由は図268.3でも示されているように、ライトサイクル時にZ80からのデータの切れが悪く、MREQがネゲートされていてもまだ出ているように見えるためです。信号名は6809のRW信号のバッファしたもの(RW Buffered)から来ています。
Z80W
しばしば負論理信号と誤解されますが、この信号は正論理の”Z80 wait”の意味であり、すなわち正論理の6809動作中を示す信号です。つまり$\text{6809/}\overline{\text{Z80}}$を表します。waitをバーと読み替えれば理解が容易です。
DRAM RASプリチャージタイム不足
基本的には上記の回路で動作しますが、一点、Z80から6809に戻る時に問題があります。それはZ80のEBにより\$FD05に0をライトすると$\text{G/}\overline{\text{H}}$が1となり、すぐに6809からQが出力されます。そのため、RASのプリチャージタイム$\text{t}_\text{RP}$が不足となり、結果としてDRAM化けが起こります。これを解決するために、Z80から\$FD05にライトする場合には、D0を0とし、EB、QBを出力せずに、6809側のEでライトし、CPUを切り替えるようにしています。
システムバスのEB及びQBが出力されないため、DRAMへのRASが出力されません。従って、RASプリチャージタイム不足が起きず、DRAMデータ化けが防止できます。
本来であれば、このようなトリッキーなことをせずZ80カードがやっているように、6809側で切り替え信号を遅延させてバスアクセスを行えば良いはずですが、時期的に本体側の回路変更ができなかったのかもしれません。
I/O掲載のZ80カード
アーカイブサイトに1985年9月号の月刊I/Oが保存されていました。その中に「FM-7/New7/77 IC9個でできる! Z80カードの製作」という記事がありました。IC9個は簡易回路とのことで、動作が不安定のようです。一方、コンパチ回路は基本的に富士通純正回路のコピーであり、ゲートを組み替えているだけに見受けられます。従って回路は正しく動作するはずですが、記事中に2点誤りがあります。
- Z80Wが負論理となっている⇒Z80Wは正論理です。記事中では負論理のバーがついていますが、Z80Wは正論理の”Z80 wait”の意味であり、正論理の6809動作中を示す信号です。上記のように$\text{6809/}\overline{\text{Z80}}$を表します。筆者はこの$\overline{\text{Z80}}$を$\overline{\text{Z80W}}$と誤認したのかもしれません。ただしこれは表記上だけの問題であり、回路への実害はありません。
- Z80カード側ではCPU(6809)のHALTと誤認する恐れがある⇒BA/BSだけで判断するとDMA(リフレッシュ)の場合と誤認するため、6809が動作中でないことを表すZ80Wとの論理をとっており、誤認しません。そもそも6809がHALT中にはDMAはかかりません。これも回路解釈の誤りだけで、回路への実害はありません。
|
1 |
FM-7 Z80カードの調査 (2) |
|
ライト時のデータバス衝突
FM-8もFM-7も、オプションのZ80カード上のデータバスバッファには、双方向バッファ74LS245を使用しています。245ではDIRにより方向制御を行いますが、6809の場合方向制御は$\text{R/}\overline{\text{W}}$信号であり、ノーマリリードです。ノーマリリードとは、ライト時以外は常にリード方向、すなわち周辺からCPU方向にバスバッファの方向を向ける制御方式です。Z80にも似たような信号であるライト時を示す$\overline{\text{WR}}$があるため、FM-8のZ80カードではこれをデータバスバッファのDIRに接続していました。
ところが、図267.1を見るとわかるように、$\overline{\text{WR}}$はストローブ信号であり、データバスバッファの方向制御に使用すると、
- T1のクロックの立下りからT2のクロックの立下りまで(1クロックのデータセットアップタイム)
- T3のクロックの立下りから立上がりまでの間(0.5クロックのデータホールドタイム)
の2つの期間において、CPUはデータを出力しているにも関わらず、バッファはリード方向となっています。すなわち、Z80と245の間でバスが衝突します。
通常、Z80システムではデータバスバッファのDIRには$\overline{\text{RD}}$を用います。すなわち、Z80はノーマリライトバスアーキテクチャです。
バス衝突の解消
まず、データバスバッファのDIRに$\overline{\text{RD}}$を用いれば、CPUとバスバッファの間のバス衝突は解消できます。FM-7のZ80カードではこの方式をとりました。
次に問題になるのがシステムバスのRWBです。データバスバッファ方向制御が$\text{R/}\overline{\text{W}}$であることから、同じ信号をシステムバスに出力するのが最も容易ですが、一方、これはノーマリライトのバスアーキテクチャであることを意味します。従って、システムバスアーキテクチャの変更にはリスクがあるため、無理やりノーマリリードの信号を作り出しています。
まずM18.4によりリフレッシュでないメモリ要求信号(!RFSH & MREQ)を作成します。
これはリードとライトの両方でアサートされるため、次の図のように$\overline{\text{RD}}$信号で打ち消し、ライト信号を取り出します(M19.8)。これは同時変化の信号の論理を取っているため、M5のDFFを用いてクロックで叩きます。これが基本的に$\text{R/}\overline{\text{W}}$となります。
バス衝突の確認
上記のとおり、バスの方向制御を作成しましたが、残るのはデータバスバッファ(ノーマリライト)と周辺(ノーマリリード)の間でのバスアーキテクチャの食い違いであり、この間でのバス衝突です。以下ではこれを確認します。バッファの衝突の可能性があるのは、
- 周辺バッファはリード方向
- データバスバッファはライト方向
であるから、下図において、M5.5($\text{R/}\overline{\text{W}}$)=Hのときです。さらにEB=Hの時に周辺からデータが出力されます。一方、データバスバッファは$\overline{\text{RD}}$=Hの際に周辺方向になるため、これらをANDすれば、リードサイクルのEBの後縁及び、ライトサイクルのEBの後縁のみであり、DCパスは無いことが確認できました。
|
29 |
FM-7 Z80カードの調査 |
|
FM-7のZ80カード
FM-7のZ80カードは基本的にはFM-8のZ80カードの継承ですが、数点の改良があります。
- 高速化
- DRAMリフレッシュ方式の変更
- ライト時のデータバス衝突の解消
- 切り替え時のDRAM RASプリチャージタイム不足の解消
高速化
FM-8のZ80が2.4MHz動作だったのに比べて、FM-7本体の高速化に合わせてZ80Aを採用し、4MHz動作になっています。ただしM1サイクルが通常のメモリリードライトサイクルに比べて厳しいため、ウエイトをかけています。なお、タイムチャートはここのオンラインツールで作成しました。
$\overline{\text{RFSH}}$リフレッシュ
M1で重要なのが*REFCKの生成です。前稿でリフレッシュタイミングを示しまたが、Z80でも同様に出力する必要があります。DRAMのタイミング要求に合うように、MREQからリフレッシュ時のみを取り出し(M18.10)、前縁を削り*REFCKとして出力しています。
ページ:
