差分
この文書の現在のバージョンと選択したバージョンの差分を表示します。
次のリビジョン | 前のリビジョン | ||
altera:qsys:epcsインターフェース [2013/01/27 03:06] kimu_shu 作成 |
altera:qsys:epcsインターフェース [2014/09/20 02:10] (現在) kimu_shu [CycloneIII/CycloneIVの場合] |
||
---|---|---|---|
ライン 1: | ライン 1: | ||
====== EPCSインターフェース ====== | ====== EPCSインターフェース ====== | ||
Embedded Peripheral IPマニュアルでは詳細が記述されておらず、HALドライバを使ってね、とある。 | Embedded Peripheral IPマニュアルでは詳細が記述されておらず、HALドライバを使ってね、とある。 | ||
- | {{:altera:qsys:epcs_table5-1.jpg?300|}} | + | |
+ | {{:altera:qsys:epcs_table5-1.jpg|}} | ||
+ | |||
+ | 気になるではないか。中身はどうなっているのだ? | ||
+ | |||
+ | ===== 基本はSPIインターフェース ===== | ||
+ | EPCSのデータシート(http://www.altera.co.jp/literature/hb/cfg/cyc_c51014.pdf)や生成されたHALドライバのソースを見れば、 | ||
+ | SPIであることが容易に分かる。 | ||
+ | |||
+ | 実際、説明無しレジスタのうち(Read Data~Slave Enable)は、SPI Coreのレジスタと同一になっている。 | ||
+ | ^オフセット((Cy1とCy2除く))^レジスタ^R/W^説明^ | ||
+ | |0x000 .. 0x0FF|Boot ROM Memory|R|先頭256bytesのデータを直接読めるエリア。\\ ブート領域に使うため。| | ||
+ | |0x100|rxdata (Read Data)|R|SPI Coreのレジスタ(0~5)と同じ| | ||
+ | |0x101|txdata (Write Data)|W|:::| | ||
+ | |0x102|status (Status)|R/W|:::| | ||
+ | |0x103|control (Control)|R/W|:::| | ||
+ | |0x104|reserved| |:::| | ||
+ | |0x105|slaveselect (Slave Enable)|R/W|:::| | ||
+ | |0x106|End of Packet|R/W| | | ||
+ | |||
+ | ===== デバイスの識別 ===== | ||
+ | Read Silicon IDコマンド(0xab)を送信((後ろに3byteのダミーwriteも必要))すると、1byteのIDが返ってくる。IDにより、容量等を判断可能。 | ||
+ | ^ID^型番^容量^ブロック数^ブロック長^ | ||
+ | |0x10|EPCS1|1Mb|4|32768| | ||
+ | |0x12|EPCS4|4Mb|8|65536| | ||
+ | |0x13|EPCS8|8Mb|16|65536| | ||
+ | |0x14|EPCS16|16Mb|32|65536| | ||
+ | |0x16|EPCS64|64Mb|128|65536| | ||
+ | |0x18((これはRead Silicon IDではなく、Read Device IDコマンド(0x9f)で読み取れる))|EPCS128|128Mb|64|262144| | ||
+ | |||
+ | ====== コンフィグレーションデータ長の読み方 ====== | ||
+ | FPGAのコンフィグレーションはEPCSの先頭(オフセット0x0)に置かなければならない。従って、EPCS上にNiosIIのコード等を格納する場合は、 | ||
+ | コンフィグレーションデータより後ろに配置する必要がある。もし、コンフィグレーションデータの直後に置く場合には | ||
+ | コンフィグレーションデータの長さが知りたくなるが、どうやって読み取るか。 | ||
+ | |||
+ | ===== CycloneIII/CycloneIVの場合 ===== | ||
+ | - 0x27~0x21バイト目のbit3を繋げる→長さ情報のbit31~25の値。<code> | ||
+ | 0020: 6A F7 F7 F7 F7 F7 F7 F3 FB F2 F9 FA F9 F1 F8 F8 | ||
+ | (bit3) ^0 ^0 ^0 ^0 ^0 ^0 ^0 | ||
+ | (位置) 25 26 27 28 29 30 31 | ||
+ | </code> | ||
+ | - 0x48~0x30バイト目のbit2を繋げる→長さ情報のbit24~0の値 <code> | ||
+ | 0030: FC F8 F9 FA FF F9 FC F8 FB FB FF FF F9 FD FD FC | ||
+ | (bit2) ^1 ^0 ^0 ^0 ^1 ^0 ^1 ^0 ^0 ^0 ^1 ^1 ^0 ^1 ^1 ^1 | ||
+ | (位置) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 | ||
+ | |||
+ | 0040: F8 F8 FC FC FA FE FA FA FA 2B 88 FF FF FF FF FF | ||
+ | (bit2) ^0 ^0 ^1 ^1 ^0 ^1 ^0 ^0 ^0 | ||
+ | (位置) 16 17 18 19 20 21 22 23 24 | ||
+ | </code> | ||
+ | - 繋げると、0b00000000_00101100_11101100_01010001 → 0x002cec51 | ||
+ | - この値はビット単位なので、8で割ってバイト単位にする。→ 368010.125 | ||
+ | - 切り上げたら完成。→ 368011 | ||
+ | - ためしに、ツールで読み取ったサイズと比較してみる。<code> | ||
+ | $ sof2flash --input=mruby.sof --output=mruby.flash --offset=0 | ||
+ | $ nios2-elf-size mruby.flash | ||
+ | text data bss dec hex filename | ||
+ | 0 368011 0 368011 59d8b mruby.flash | ||
+ | ↑合ってる! | ||
+ | </code> | ||
+ | - なお、rbfのファイルサイズともぴったり一致する。 | ||
+ | |||
+ | ===== 圧縮時の注意 ===== | ||
+ | Compressionを有効にすると、上記のルールで読み取ったサイズよりも1バイト大きくなる模様。 | ||
+ | 最終サイズが偶数のときも奇数のときもあるので、バウンダリの関係でもないようだ。 | ||
+ | ヘッダから圧縮の有無を判別する方法が分からないので、コンフィグレーションデータの末端数十バイトが0xFFであることを利用して判別するしかなさそう。 |