2011年06月29日

MachXO 2280 Breakout ボード

デジキーで 2700円 と安価に購入できる FPGA ボード について。



簡単な説明

    FPGAは、Lattice 社の MachXO 2280 。-- MachXO2 が出ているから、最新のチップというわけではない。といっても 発表は最近で 2011/4 。価格は $29.9 ということになっている。

    このボードには、FT2232H が載っていて、非常に安易に使える。USB に接続するだけだ。Lattice 社の合成ツール Diamond (最新は v1.2)でもサポートしていて、ビルドしてから、2オペレーションで書き込みが可能。

      (1) Tools→Programmer を選ぶと ダイアログが出る。
      (2) (一回設定した後は) Download ボタンを押す。

    FPGA に接続されているデバイスは、(JTAG 以外には) LED x 8 のみ。

規模は小さめで、特にブロック RAM が少ないのが苦しいが、気軽に使えるのが気に入ったので、rtavr の最初のリファレンスボードとして使うことにした。

こうなるとは、当初は思ってもみなかった。

合成ツールは Diamond を使用している。Xilinx から入ったのだが、使いやすい印象。メジャーどころの Altera や より 合成ツールの サイズが小さい -- それでも大きいが -- というのは、試用するの場合の利点。

    rtavr を動かす本命は依然として 自作の Artemis ボードのつもり。だが、Artemis ボードを使う前にツールの開発が必要なのだ。ツールの開発を 『MachXO 2280 Breakout ボード』をつかってやることにした。そして、ツールが動けば勢いで rtavr も 先にテストしてしまうだろう。

  • 自作ボードでしか rtavr を動かせないというのでは、都合が悪い。完成しても誰も試そうとはしないかも知れない。またバグが報告されても、共通のボードでないと確認できないかも知れない。そういう意味でリファレンスボードはあった方が良いのだ。

  • ツールでは、FT2232H を Bitbang モードで使う。こうすることで Artimis ボード の AE-UM232R とコードを共通化することができる。(ちなみに ツールは開発中だが、JTAG が使える所までは出来ている。)

  • 『MachXO2 Pico dev kit』(LCMXO2-1200ZE-P-EVN) も デジキーで買えるようになった。... が、4787 円と思ったより高い。このボードに興味がないわけではないが、今は組み込まれているデバイスを動かすような ことの優先度は低いし、リファレンスボードとしては使わないことにした。


入手先や資料について


コネクタの アサイン図:

MachXO 2280 Breakout Board Evaluation Kit(LCMXO2280C-B-EVN)

          TOP View

J10 J6 J5
(1) (2) (1) (2) (1) (2)
PB9B(P8 ) PB2A(P2) Lattice VCCIO GND PT2C(B2) PT9A(D8)
PB9A(P7 ) PB2B(P3) VCCIO GND PT2D(B3) PT9B(E8)
PB10E(N8 ) PB2C(N5) VCCIO GND PT3A(A2) PT9C(E9)
PB10C(P9 ) PB2D(N6) VCCIO GND PT3B(A3) PT10A(A10)
PB10D(P10) PB3A(T2) VCCIO GND PT3C(D3) PT10C(C9)
PB10A(M10) PB3B(T3) VCCIO GND PT3D(D4) PT10D(C10)
PB11C(R9 ) PB3C(R4) VCCIO GND PT4A(C4) PT10E(D9)
PB11D(R10) PB3D(R5) VCCIO GND PT4B(C5) PT10F(D10)
PB12A(T10) PB4A(P5) -- -- PT5A(D6) PT11A(B9)
PB12B(T11) PB4B(P6) -- -- PT5B(D5) PT11B(B10)
PB12C(N10) PB4C(T5) -- PT15A(E10) PT5C(B4) PT12A(A11)
PB12D(N11) PB4D(T4) -- PT15B(E11) PT5D(B5) PT12B(A12)
PB13A(R11) PB5A(R6) -- PT15C(B13) PT6E(E7) PT12C(B11)
PB13B(R12) PB5B(T6) -- PT15D(C13) PT6F(E6) PT12D(B12)
PB13C(P11) PB6A(T8) PT7C(A6) PT16A(B14) PT6C(A5) PT13C(C11)
PB13D(P12) PB6B(T7) PT7D(A7) PT16B(C14) PT6D(A4) PT13D(C12)
PB14A(T13) PB7C(M7) PT8C(B8) PT16C(A15) PT6A(C6) PT14A(A13)
PB14B(T12) PB7D(M8) PT8D(C8) PT16D(B15) PT6B(C7) PT14B(A14)
PB14C(R13) PB8C(R7) FTDI -- GND PT7A(B6) PT14C(D11)
-- PB8D(R8) Chip -- GND PT7B(B7) PT14D(D12)
(39) (40) (39) (40) (39) (40)
  (LED)
[D5] [D1]
PB15D(P14) PB16D(P16)
[D6] [D2]
PB15B(T15) PB16C(P15)
[D7] [D3]
PB15A(T14) PB16B(R16)
[D8] [D4]
PB14D(R14) PB16A(R15)

TP0 - TP10 : VCC10 (3V3)

J1 -- JTAG J9

(1) 3V3 (25) PD14D(R14) [D8]
(2) NC (27) PB15A(T14) [D7]
(3) NC (29) PB15B(T15) [D6]
(4) TCK --- R3 --- FT2232H ADBUS0 (31) PB15D(P14) [D5]
(5) TDI --- R4 --- FT2232H ADBUS1 (33) PB16A(R15) [D4]
(6) TDO --- R7 --- FT2232H ADBUS2 (35) PB16B(R16) [D3]
(7) TMS --- R9 --- FT2232H ADBUS3 (37) PB16C(P15) [D2]
(8) GND (39) PB16D(P16) [D1]

(R3,R4,R7,R9 = 70 ohm)


    20x2 の コネクタが 8 つ付けられるが、普通の使用方法で それを全部使うのはあまり考えられない。そこで、写真右サイドの 4 列(J6,J5)と 左サイド中央側の 2 列(J10)を 普段は使うようにしようと思う。そう考えて ピンアサイン図を作成した。

  • Lattice Diamond でのピンのアサインには、() 内の ピン番号を使用する。

  • 2x20 ピンソケット(低メス) を J10, J6,J5 に付けようと思う。

  • 実験用には、 C基板(旧: FR-4) を使うつもり。必要な信号の分だけ ピンヘッダを下向きに付ける。
    (注意) ピンヘッダを付け過ぎると 抜き差しが非常に難しくなるので注意

  • C基板(新: CEM-3) は穴が少ないので、横向き にしか付けられない。C基板(旧) だと 縦向きも可能。

  • J9 で基板をカットすると JTAG ケーブル として使えるかも知れないので、できるだけ J9 は使わないようにしようと思う。-- ちなみにカットしてしまうと、FPGA は再config できなくなる。FPGA を壊してしまったり、二度と使うつもりがない場合にしか カットするつもりはない。

  • ちなみに 上下のコネクタは、GND が多く 3V3電源 がない。信号線を引き出すような目的に合うと思う。実際に使う予定は今のところないが、拡張ボードを 作って 直付しようかと目論んではいる。

  • LED の信号は J9 (25) - (39) にも出ている。(位置は、左サイド 最外側の 下 8 pin)
    基板をカット する場合は、J9 の右側が良さそう。
    ここに ロジアナを接続すれば、波形を見ることが出来る。目測できないような信号でも LED に出力する意味はありそう。

      ロジアナで使うようにするには、JTAG の 8pin と LED の 8pin に 1列の ピンヘッダを付けるのが良さそう。


    いろいろ書いたのだが、とりあえずやりたいのは、水晶発振の実験ぐらい。
    デバッグのためになんらかの デバイスを付けるつもりはない。ツールでの通信が可能になれば不要になるはずなのだ。

    ちなみに、ツールでの通信は、まだうまく行っていない。そのデバッグのために ロジアナは必要になるかも知れない。

制約ファイル(.lpf)


      BLOCK RESETPATHS ;
      BLOCK ASYNCPATHS ;
      LOCATE COMP "LED_7" SITE "R14" ;
      LOCATE COMP "LED_6" SITE "T14" ;
      LOCATE COMP "LED_5" SITE "T15" ;
      LOCATE COMP "LED_4" SITE "P14" ;
      LOCATE COMP "LED_3" SITE "R15" ;
      LOCATE COMP "LED_2" SITE "R16" ;
      LOCATE COMP "LED_1" SITE "P15" ;
      LOCATE COMP "LED_0" SITE "P16" ;
      USERCODE ASCII "RT01" ;
      IOBUF PORT "LED_7" IO_TYPE=LVCMOS25 SLEWRATE=SLOW PULLMODE=NONE DRIVE=12 ;
      IOBUF PORT "LED_6" IO_TYPE=LVCMOS25 SLEWRATE=SLOW PULLMODE=NONE DRIVE=12 ;
      IOBUF PORT "LED_5" IO_TYPE=LVCMOS25 SLEWRATE=SLOW PULLMODE=NONE DRIVE=12 ;
      IOBUF PORT "LED_4" IO_TYPE=LVCMOS25 SLEWRATE=SLOW PULLMODE=NONE DRIVE=12 ;
      IOBUF PORT "LED_3" IO_TYPE=LVCMOS25 SLEWRATE=SLOW PULLMODE=NONE DRIVE=12 ;
      IOBUF PORT "LED_2" IO_TYPE=LVCMOS25 SLEWRATE=SLOW PULLMODE=NONE DRIVE=12 ;
      IOBUF PORT "LED_1" IO_TYPE=LVCMOS25 SLEWRATE=SLOW PULLMODE=NONE DRIVE=12 ;
      IOBUF PORT "LED_0" IO_TYPE=LVCMOS25 SLEWRATE=SLOW PULLMODE=NONE DRIVE=12 ;

    制約ファイル(.lpf)は、ピンの番号を書くらしい。PB16D とかではない。

    LED をドライブするだけなので、他の設定は適当。

      SLEWRATE は FAST と SLOW があり FAST がデフォルト。意味なく FAST にすることはないと思ったので、SLOW に変更。
      PULLMODE には、UP/DOWN/KEEPER がある。LED は L で点灯するだけなので、NONE にしておいた。
      LVCMOS25 と LVCMOS33 との違いが実際にあるのかどうかは、良く知らない。DRIVE 電流の値は、いくつかあるが、自由に選べるわけではないらしい。LVCMOS25 では 12mA が選択できたので、そのままにしてある。


rtavr_tools-0.1.tar.gz

    開発中のツール。test_hdl ディレクトリに テスト用の HDL コードを置いてある。これを書き込んで、src の basic_test をビルドして動かすと、テスト用の HDL コードと SPI で通信する。

      通信もちゃんと動いているわけではない。9 bit 送ると 8bit 受け取れるという変な状況。

      ... どうも FPGA 側で JTDI が ラッチされているような感じ。そういうものならば、8bit とか 16bit とか最低単位を書いたらいったん Shift-DR を抜けて入りなおすような、処理に統一した方が良さそうだ。いったん抜ければ CS がトグルされ bit 位置が リセットされる。

      rtavr の slave-SPI を使うような場合、2 バイト分を送りこむと AVR 側が間に合わないのでどうしようかと思っていたが、1 バイト書いたら CS トグルなら 余裕ができて好都合。

    作成中のコードは沢山あって、これから組み上げていく予定。

      ほとんどのコードはテストできていないが、

    • .bit(Xilinx) .mcs(Xilinx) , .jed(Lattice) , .mem(Verilog) のファイルの読み込み(パーザは いいかげん)
    • Lattice XO の Config, Xilinx の Config (作っただけ)
    • FT245R/232R BitBang Cable ドライバ(結構動いている)、serjtag Cable ドライバ(作っただけ)

      などが含まれている。

    一応かつて 雑誌の付録になったものはサポート可能にしたい。-- 結構持っているし。ただ Altera は 自分の NotePC に 合成ツールが入れられないし、チップ単体で買えない or 買いづらいのでパス。

    XP2 も チップが買えるし、サポートしたい。(DDT付録 はもっていないけど)

    ただ、無制限にチップをサポートするつもりはない。基本は、自分が使う予定があるもののみ。

MachXO 2280 について

    実は細かいことは知らないのだ。
  • Config 用 FLASH 内蔵
  • 4LUT x 2280 の規模
  • ブロックRAM は 8kbit x 3
  • 内蔵発信器と 2 つの PLL 。

    これぐらい。ブロックRAMの容量が少ないので、チップ自体には興味がない。ボードが入門用に最適だったので選んだだけ。

    Config のしかたは、SVF ファイルを読んでだいぶ理解した。XP2 とおなじようなやり方(違いはある) 。一方 MachXO2 の Config のしかたは、だいぶ違う。あと、FLASH と RAM でデータ形式が違う。.. ちょっと ツールで対応するのは面倒。

    MachXO2 には興味があるが、-1200 は 、規模が小さくブロックRAMの容量も少ない。いま Lattice の チップを買うとすれば(実際は買わないが) LFXP2-5E/8E が良さそうな感じ。

MachXO 2280 Breakout ボードの利用案

    JTAG を通して PC と通信できれば、結構応用範囲が広がる。BitBang では、最大でも 3.7Mbps 程度の帯域にしかならないが、MPSSE を使って通信すれば、24Mbps (3MB/sec の 同時入出力) が可能だ。4pin しか接続されていないから、FT2232H の他の機能は使えないのが残念ではあるが、この程度までなら、お手軽に使える。

    USB なので、うまくバッファリングしてやらないと 途切れなく データを送受信するのは難しいかも知れないが、ブロックRAM もバッファに使うなどしてやれば、サウンドデータを送受信することも可能かも知れない。

    あと、いろんなデバイスとの通信テストとか。ピンが沢山あるから、付ける一方にして、外さないという使い方が可能。PC で制御プログラムを作って確認後、ターゲットのマイコンに移植するやりかたもできる。

    月並みだが、ロジアナ系。低速で良いなら メモリとかなしで作れるだろう。その場合 PC のディスクに全部ログするような使い方もできる。FT2232H を生で使っても似たようなことはできそうだが、FPGA で作るメリットは柔軟性。高速だが 2bit のみとか、低速だが100bit みたいなことができる。

    メモリを付けてまで作るようなことは考えない。手間を考えれば メモリ付きのFPGA ボードにしたほうがお手軽そうだ。

    あと、いろんなライタに仕立てるのは可能。 通信ができる以上、工夫次第で JTAG すら可能だろう。

rtavr_tools-0.2.tar.gz


    spi_test -- spi_echo test1
    30 ff (7f)
    31 30 (18)
    32 31 (18)
    33 32 (19)
    34 33 (19)
    5535 3455 (1a2a)
    aa5536 35aa55 (1ad52a)
    37 36 (1b)
    38 37 (1b)
    39 38 (1c)
    ff 39 (1c)
    ff ff (7f)
    spi_test done

    ようやく通信できた。左から PC の出力データ (MSB first) 、PC への入力データ。() は参考用で 1bit 右シフトした値。8 bit のシフトレジスタがあるだけなので、1 バイト分後で出力されている。

    ググって見付けた 『よくわかるバウンダリスキャン試験解説講座』を読んで TCK の立ち上がりで シフトすることを理解した。SPI とは極性が逆だ。

    test_hdl も直してようやく動いた。

    これで JTAG の API も FIX 。

    void jtag_go(CABLE cbl,int state);
    void jtag_init(CABLE cbl);
    void jtag_reset(CABLE cbl);
    void jtag_IDLE(CABLE cbl, int ms, int count);
    void jtag_SIR(CABLE cbl, uint8_t *buf, int bit_len, int flags, uint8_t *rcv_buf)
    ;
    void jtag_SDR(CABLE cbl, uint8_t *buf, int bit_len, int flags, uint8_t *rcv_buf)
    ;

    void jtag_SIR32(CABLE cbl, uint32_t code, int bit_len, int flags, uint32_t *rcv_
    data);
    void jtag_SDR32(CABLE cbl, uint32_t code, int bit_len, int flags, uint32_t *rcv_
    data);
    void jtag_SDR32R(CABLE cbl, uint32_t code, int bit_len, int flags, uint32_t *rcv
    _data);

    32bit までなら コードが書きやすく分かりやすいように tag_SDR32 などを作っている。jtag_SDR32R は、SPI 通信用で MSB first 。

    flags は、1 : 受信も行う。2: 状態を移行しない。(最後の TMS==0)。

    いまのところ、API 間で非同期にI/O はしていない。受信をしない jtag_SDR を連続で call するような場合しか有効でないが、jtag_SDR を 1 つにまとめたほうが最適化になる。要するに非同期してわずかに高速化してもあまり意味はない。

    そういえば、

    int (* get_tdo_bits)(CABLE cbl, int bit_len, int tdi, uint8_t *rcv_buf);

    なんて (CABLE の) API を作ったのだが、使っていない。これは不要だった。(削除予定)
posted by すz at 21:52| Comment(0) | TrackBack(0) | MachXO2

2011年06月19日

UM232H

FTDI のドキュメントを調べる機会があって、見ていたら FT232H という Hi-Speed(480Mbps) のチップが出ていることを知った。このチップを使ったボード UM232H も FTDI から出ている。(データシート)



    デジキーの価格は、UM232H が 1801円。

    FT232R の AE-UM232R と比べれば高いし、シリアルが 12Mbps で動いたところで、普通の使用方法ではメリットはないだろう。

    メリットがあるのは、MPSSE を使った JTAG や BitBang 使うようなものや、SYNC 245 FIFO/FT1248 を使った 高速パラレル通信。MPSSE を使った JTAG は、最大 30Mbps , SYNC 245 FIFO は 40 MB/sec と書いてある。

    FT232R 用 BitBang ライタ も そのままで動いて、速くなるんじゃないかと思う。

      ちょっと見込みが甘かった。値は設定できるが、平均 550kbps ぐらいしか出ていない。(8bit x 2(ON/OFF) x 往復 だからデータの 転送レートは 2.2 MB/sec = 17.6M bps) 。 Full-Speed の性能は超えているから 確かに Hi-Speed だが、ちょっとしょぼい結果だ。

      AN232B-03:D2XXDataThroughput を見ていたら 1回の Write サイズを 3968 の倍数にせよと書いてあった。すなおに 3968 バイトにしてみたら 平均 2.3 Mbps になった。これならまぁいいか。

      (追記) FT_SetUSBParameter で 16KB を指定し、1回の Write サイズを 3968 x 4 にしたところ 3.87 Mbps まで出た。MPSSE の 1/5 ぐらいの性能だが、FT232R/245R 用の コードで動くのが、作る立場でのメリット。おまけでここまで出るのなら不満はない。

    従来から FT2232H があるが チャネルは 1つになった代わりに、安くなった。-- チップ単体だと FT232HL (LQFP48) が 383円。FT232R と比較できる価格だ。

    • FT1248 というのは、新規の機能のようだ。FT2232H にはない。

    • VCCIO は、3.3V のみ。これは、FT2232H も同じなようだ。5V トレラントにはなっている。

    最近は、FPGA に興味がシフトしているので、気になっている。

    JTAG では特に高速な方が良い。またパラレル通信の帯域はかなり魅力的。これぐらいの性能で PC とやりとり出来て、電子工作で使えるインターフェイスは少ない。しかもパラレルだから FPGA で受けられる周波数になっている。

部品についてのメモ:

チップも安いから、基板を設計したくなる。LQFP48 は小さいから AE-UM232R のサイズに入れられそうだ。互換ボードとか作ったから、いろいろ流用できそうだ。

ただ、ピン互換にするメリットがあるのかどうか? MPSSE がメインなら、シリアルとして config しないことになる。+αの機能を入れるなら SYNC 245 FIFO か FT1248 ではないかと思う。そうなると ピンが足りない... ような?

SYNC 245 FIFO/FT1248 を使わないなら、JTAG 専用で 良いではないかと言う気もする。.. となると Sparkfun FTDI Basic Breakout (3.3V) みたいなデザインが良さそう。(ただしピン互換は無理。RTS が必要だが 6pin に入っていない。)

  • MI0603J600R

    チップフェライトビーズ。60Ω@100MHz 。いろんな USB 関係の回路図で VBUS から 電源を取る場合に チップフェライトビーズを通している。 このチップは、Lattice の USB JTAG (FT2232HL) の回路図でも使っていた。UM232H だと 3 つ使っている。(VBUS からの 入力, VPLL, VPHY) 。

    秋月に BLM18PG600SN1D (1608, 60Ω@100MHz, 25個100円) があるので、ここで買う必要はない。ついでに買うなら ... という感じ。

  • PGB1010603

    USB D+/D- は直結なのだが、これが GND との間に入っている。ESD 保護用だそうだ。FT2232H の回路図にはないから、推奨といったところか?

      Arduino UNO の回路図みてたら、これが入っていた。思ったより一般的なのか?

      ちなみに、GND との間ではなく、SLD との間。SLD と GND の間には、BLM21 という チップフェライトビーズが入っている。値は書いてない。

  • MCR10(12K)

    1% 誤差指定の 12KΩが必要。買い忘れないようにしないと。

  • 93LC56BT

    UM232H の回路図では、SOT-23-6 の 93LC56BT を使っている。(16bit モードのある B でないといけないらしい 要注意)

  • NX3225SA

    表面実装型の水晶で、秋月で扱っている FA238 (3225サイズ) に置き換えられるのは、これ ... なのか?

    12 MHz が欲しいが、95 円もする。秋月の FA238 は、16/20/25 MHz のみだし、仕方がないか。

    .. ただ、ハンダ付けで一番苦労するのは、いつもこの水晶。ちょっと悩む。

  • NX5032GA 2pin SMD で安いというと こういうやつ。 73 円だし特に安いわけではないが、ハンダ付けが楽そう。ラジアルタイプは安いが、安っぽい感じがして嫌。固定する方法も悩む。

UM232R

    UM232H があるなら、UM232R もあるのか? ... と思ったのだが、同然ながらあった。
    で、データシートを見てみたら AE-UM232R とピン配置が 同じだった。

    ちなみに、AE-UM245R も UM245R もある。こちらはピン配置が違う。UM245R は、UM232R のチップを載せ替えただけのようなピン配置で、AE-UM245R は、秋月オリジナル。

追記(2011/10/8): ストロベリー・リナックスの FT232H モジュール
posted by すz at 19:48| Comment(0) | TrackBack(0) | 日記

2011年06月04日

コンピューターウィルス作成罪?

MiAU から 「情報処理の高度化等に対処するための刑法等の一部を改正する法律案」について慎重審議を求める声明 が出ている。

ソフトウェアをリリースしている立場としてかなり気になる。

『コンピューターソフトウェアの重大なバグ(瑕疵)の放置が提供罪に該当する事態がある』とのことだが、いくつか疑問がある。

ソースコードしか提供していないものがあるのだが、これは そもそも、『コンピューターソフトウェア』に該当するのだろうか? ビルドしなければ、動作することはないし、ビルド環境の違いで動作しないような場合もある。ー要するに 動作するものと ソースコードは、1:1 に対応しない。ビルドすら不可能な場合だってある。

それに、ビルドするときに改変して 『トロイの木馬』を埋め込むようなことは可能で、それは提供されたソースコードをみても分からない。

ソースコードの提供には、責任がないとすると ビルドして提供する側に責任があることになる。まぁ 『トロイの木馬』のような話もあるし、たぶん一般的な認識ではないかと思う。

    そうはいっても、法律を制定する側の 一般的な認識とは限らない。いままでの例から考えても、信頼しきることはできない。

次の疑問はライセンス。ほとんどの オープンソースのソフトウェアは、『AS IS で提供するものだから、いかなる保証もないよ』と(ソースには)書いてある。そして、それを了承することが 使用できる条件になっている。ビルドして提供するとしても、『使用できる条件』なのだから、ライセンスとして添付しての提供になるのが普通である。

オープンソースのソフトウェアは、無償であることが多い。『なんらかの保証を求めた時点で使用権を剥奪する』というのは、さすがに法的にも有効だと思うのだが、実際のところどうなのだろう?

ちなみに、有償のソフトウェアも同じような条項が付くのが普通である。保証するためのコストが価格に込められてないならば、やはり法的に有効であろうと思える。

でもそうであれば、重大なバグ(瑕疵)の放置って何だということになる。

だいたい、PL法でも ソフトウェア単体は 法の対象になっていない。命がかかわるような重大な問題であっても 対象にはならないのである。それには、ちゃんとした理由があるはずだ。

    実はちゃんとは知らないのだが、次の理由だろうと思っている。

    ソフトウェア単体では、どのように動作するかそもそも定義できない。OS やら ハードウェアを含んだシステムとして 定義しないと 動作の定義は不可能で、そういうものは普通装置として認識される。

    (装置であれば、PL法の対象になる。)


まぁ、こういうわけでソフトウェアにたいして、責任を追求するのは無理がありそうな気がするわけだが、無理が通される可能性はある。

さて、次の疑問。放置って何?

私の認識では、バイナリが違えば別のソフトウェアである。

    というか、ライセンスが違えば バイナリが同じであっても別のソフトウェアと言えるかも知れない。が、ここでは そこまでは追求しない。

おなじソースコードから作成した A と B のバイナリがあったとする。そして A と B を作った人(団体)が違うとする。

A を作った人は A のみの責任を負う。B に対する責任を負ういわれはない。

    これは、常識として通用している。これを前提として オープンソースのビジネスが成り立っている。

おなじソースコードから作成しても別のソフトウェアであれば、改変したソースコードから作成したら当然別のソフトウェアであろう。

放置しないということは、別のソフトウェアを提供しなおすということで、コストがかかるということだ。装置することが許されていないとなると、別のソフトウェアの購入を強制することが出来るということであろうか?

たぶんそんなことは、ないのだろう。それはともかく、重大な問題があったソフトウェア と 置換されるべき 別のソフトウェア との関係はどのように定義されるのだろう?

    なんだが、グダグダな感じで終わらせてしまったので、補足。

    要するに、バイナリとなってリリースされるソフトウェアは、それで完結している。

    発禁にすることはできても、表現を変えて再提出せよと命令することは出来ないのではないか?

    そういう風にかんがえると、『重大なバグがあったらそのままの形で売り続けてはいけない。』ぐらいにしないといけないのではないか?

    『そのままの形』と書いたが、バグがあることを告知して、修正版があれば、それを入手する情報が添付されていれば良いのではないか? (リンク先が更新されるという前提で)リンク を貼っておくのでも良いかも知れない。

    有償のものは、そういう感じで良いと思うのだが、無償のものはそれでは困る。有償だと金銭の授受がある以上責任がある人(団体)がはっきりしている。無償だと、配布している人が存在しないかも知れない。あるいは、著作権が切れている状態かも知れない。あと、歴史的理由で実用としては配布していないかも知れない。

    無償だと免責だとか、ソースコードが添付されていれば、免責だとか。なにか配慮が欲しい。

    バグがあるという理由で、著作物を消滅させることにはなって欲しくないものだ。

こういうわけで、現時点では、具体的になにを意味するかわからないのだ。そうであれば、反対すろこともできない。私も慎重審議を求めることにしよう。

追記: 2011/06/17 本日 「ウイルス作成罪」(不正指令電磁的記録作成罪) が成立した。

毎日jpの記事 では、コンピューターウイルスを「意図に沿った動作をさせず、不正な指令を与える電磁的記録」などと定義。という説明になっている。誰もが『これはバグの定義では?』と思う内容だ。記者の無理解のためこういう説明になったのか? はたまた 本当なのか? 本当だとすれば、どうしてこうなったのだろう?

そもそも、コンピュータ・ウイルスとは、使用者の意思に関係なく 無限に感染していくようなもののことだ。コンピュータに依存している社会が危機にさらされるから、そういう性質のものを作ること自体が絶対悪である ... という風に私は理解している。

    無限に感染していく性質ならば、必ず自分自身をコピーする性質がある(実行形式の)プログラムのはずだ。それだけを問題にすれば良い。「記録を破壊した」とかは、別の犯罪だ。そういうプログラムをなんらかの方法で実行させれば良いわけで、コンピュータ・ウイルスでなくとも成り立つ。

    「記録を破壊するプログラム」をメールで大量に送ること ... これは犯罪だとは思うが、なんらかの形で騙して 損害を負わせるようなことだから 詐欺の類ではないのか?

    「記録を破壊するプログラム」が、自分自身を 勝手にメールで送る ような機能を合わせ持っていれば、これはコンピュータ・ウイルスだろう。

追記: 解説がいろいろ出てきた

    『無断で他人のコンピューターにおいて実行させる目的』で ウイルスを 「作成」「提供」「取得」「保管」すると 罪に問われる。そして、ここで言うウイルスは、バグがあるプログラムを含む定義。

    ということらしい。

    他人のコンピューターにおいて実行させるのに、普通は「無断」などあり得ない。騙されて実行してしまうのが普通。騙されて実行してしまうことも この法律に引っかかるのだろう。だが、「騙す目的での行為」 と 「作成、保管」とは 論理として つながらない。どのようにでも解釈されうるおそれがある。

      『無断で他人のコンピューターにおいて実行させる目的を持ったプログラム』の 「作成のみ」なら プログラムの動作で判断可能で、まだ理解できるのだが、そうは書いてない。まぁ「保管」が含まれると恐ろしいことになるから、そうは書けないのだろう。

      そういう理由もあって、このような表現をしているのだろうが、やってはいけないことの本質を捉えていないから、どのようにでも解釈される印象だ。

    本当に 「無断で実行させる」例として、OS の脆弱性をついてアタックをかけて 実行させる という手段がある。これを罪とするのは、正当だとは思うが、これだけが該当するような感じではない。そして、これは本当の意味のウイルスの特徴ではない。

    増殖するのがウイルスの特徴であって、「無断で実行させる」だけならば「増殖」しない。 「増殖するもの」に対して 軽い罪のように思われるし、「増殖しないもの」に対して 重い罪のような印象がある。なにより、解釈しだいというのが怖い。

「情報処理の高度化等に対処するための刑法等の一部を改正する法律」 を読んでみた。

    いまさらながら、条文を読んでみた。正直 リンクで紹介されないと読む気がしない。ようやくリンクを見かけたので、読むことにした。

      第百六十八条の二 正当な理由がないのに、人の電子計算機における実行の用に供する目的で、次に掲げる電磁的記録その他の記録を作成し、又は提供した者は、三年以下の懲役又は五十万円以下の罰金に処する。

      一 人が電子計算機を使用するに際してその意図に沿うべき動作をさせず、又はその意図に反する動作をさせるべき不正な指令を与える電磁的記録

      二 前号に掲げるもののほか、同号の不正な指令を記述した電磁的記録その他の記録

    「作成」「提供」に関しては、どうもこれだけらしい。

    すなおに読むと...『正当な理由がない』 のにバグのあるプログラムを作成したり配布したらダメとしか読めない。

      『正当な理由がない』 -- 『興味本位』ってのは、『正当な理由』にはならないのだろう。趣味でプログラムを作るのに、『正当な理由』などあるのだろうか?

      『人の電子計算機における実行の用に供する目的』-- 実行させる目的 って何だ? そもそも プログラムを 配布するのは、実行させる目的のはず。ソースコードは、そのままでは実行できないが、実行させる目的 であるとは言える。ソースコードだけだからと言って 安心できない。

      ところで、AVR は、人の電子計算機に入るのだろうか? 入らないと判断できる記述ではないから入りそうな気がする。

      (一) は、やはりバグの定義にしか読めない。

    「取得」「保管」も同様で、『正当な理由がない』 のにバグのあるプログラムを「取得」「保管」してはならないという風に読める。

    「無断で実行させる」とかは解釈のひとつに過ぎないわけか。『正当な理由』だけが拠り所という感じ。悪意をもってと判断されば、なんでも罪に問える 内容に読める。

    悪評が高い 「不正アクセス禁止法」 でも、条文自体はちゃんと書いてあるように読める。それでも、『ACCS裁判』では、判事が内容を読み違えたと私は思っている。これはもっとひどい。条文を読んでも、どういう理由で、どういう行為が罪になるのかサッパリ分からない。いったい司法は、なにを基準に判断するのだろう?

      「不正アクセス禁止法」では、アクセス制御機能 = 鍵と理解すると 整合がとれた内容になっている。
      目的は、鍵による秩序の維持を図ること。
      (一) は、他人の鍵をつかうな。
      (二) は、鍵 を ピッキングで 開けようとするな。
      そして、(三)は 鍵 を 壊すな。

      バックドアは、 鍵がない入口があることを意味する。本来なら (三) かどうかは議論にすらならないはず。

      (補足) これは、私の個人的主張を平易に説明したもので、正確さにかける。だが、このように捉えないと 矛盾が生じる。そこまで分析はしたのだが、説明は困難なのでそこまでは踏み込まない。
      "鍵" という概念を導入して、それを保護することで秩序を守る という目的ならば、バックドアをも保護する のは "鍵" の存在意味がなくなるということで 論理が成り立たない。... 細かく分析すると、もっと出てくるのだが、これぐらいの説明で止めておく。


では、どういう内容なら良かったのか?

    たぶん 2 つの概念に分かれるのではないか

    ひとつは、『感染させるためのしくみ』を実際に行使する目的をもって作成するようなこと。

      『感染させるためのしくみ』とは、『計算機の使用者を騙してプログラムを実行させる』あるいは、OS の脆弱性を突くようなことをして、『計算機の使用者に無断でプログラムを実行させる』ようなもの。

      ここでは、プログラムがなにかということは問わない。そんなことをするのは、プログラムがなんであれ悪なのだ。

      だいたいプログラムを差し替えることは容易であり、犯行の直前まで安全なプログラムを実行するようにしているかも知れない。

      (追記)こうは書いてみたものの、『計算機の使用者を騙してプログラムを実行させる』ものには、メールの文面や Web サイトのリンクが含まれる。あまりに容易に作成できるから条件を変えるか、条件を増やさないとまずい。といっても、詐欺のようなものだし、実際に実行したら罪を問うことを否定はしない。

      ところで、 Web サイトに フラッシュ や java ,スクリプトが 含まれていたらどういう扱いになるのだろう? ほとんどの場合『計算機の使用者は意図』しておらず『無断で』動いている。java などは、『計算機で動作』はするが、計算機のファイルにアクセスできないようになっていて 『人の計算機で動作』とは定義されないようにしないとダメなのではないか?

    もうひとつは、本来の意味のウィルスの作成。

      本来の意味のウィルスは増殖することを特徴とするから、かならず自分自身をコピーする機能を持っている。そして、『計算機の使用者に無断で』自分自身のコピーを実行する

      『計算機の使用者に無断で自分自身をコピーする機能をもった』もの を 実際に行使する目的をもって作成するようなこと。

      このようなプログラムが 上記の機能と組み合わさると 他の計算機にも感染して爆発的に増殖することになる。だからといって組み合わせたものだけを罪とする必要はない。これだけでも危険なのだ。

      また、これと 上記のものとは、違う技術になる。どちらかの作成を専門とする場合もありそうだ。

    表現は吟味しないといけないのだろうが、どういう特徴をもったものがどういう理由でダメなのかをはっきり書けば良いのではないのだろうか?

    あと、例外として『正当な理由がある』場合はのぞくとなっていれば良いのだろう。どういうのものがダメか判断できれば『正当な理由がある』かどうかも判断できる。そして、『正当な理由』はまれだということになっていれば良い。できたら 『正当な理由の例』も条文にちゃんと書くべきだろう。
posted by すz at 10:10| Comment(1) | TrackBack(0) | 日記

2011年06月02日

FPGAライタの設計(2)

AVR互換コア rtavr の SMP化 も一段落した。そろそろツールに着手しようかと思う。

    ちなみに、rtavr の最新版は、これ。ツールができるまで凍結。

  • rtavr-0.9.3.tar.gz

FPGAライタの設計』で少し検討したが、これからはそれの実装がメイン。

作ろうとしているのは、

  • 自作 ARTEMIS ボードの コンフィグ と SPI-FLASH への書き込みが同じ操作性でできる。
  • ARTEMIS ボードに rtavr を入れた場合 ISP でプログラムだけの書き換えもできる。
  • さらに rtavr と SPI で通信し printf デバッグができる。
  • JTAG インターフェイスは、ARTEMIS ボードと接続できる AE-UM232R(ft232r) と自作の『AE-UM232Rピン互換ボード』(mega32u2)
  • AE-UM232Rは、BitBang だが、AE-UM232Rピン互換ボードは自作の serjtag プロトコルを使う。

こういうもの。SPI-FLASH への書き込みは、一旦 FPGA を コンフィグ して行う。

    コンフィグするものは、JTAG と SPI-FLASH を直結したものになる予定だが、rtavr を動かして接続するものも作ってみたい。

それ以外に

  • エミュレータと結合して、rtavr 用プログラムのデバッグ環境にする。

    verilator を使うと、完全なデバッグ環境を作れるかも知れない。ちなみに、verilator は構文チェックとしてだけ使っても有用だそうだ。

というのもやるつもり。SPI-FLASH への書き込みの方が後回し。
さらに、

  • Lattice MachXO2

も視野にいれる。リファレンスには、『MachXO2 Pico Dev Kit』を予定。

... なんたる大風呂敷!という気がするが、どこまで出来るものなのか.. まぁやってみよう。

こういうツールはオープンソースのものを含めて多数あるわけだが、わざわざ作るのは、FT232R BitBang に対応したものがないし、serjtag に対応したものも当然ないため。avrdude でやったように ft232r/serjtag のドライバだけを作るのも手なのだが、上位レイヤでエミュレータを付けたりしたいので、ほとんど自分で作ることになる。

そもそも、したいのは rtavr を使うための環境作りであって、単にFPGAのコンフィグだけがしたいのではないから、既存のツールとは合わない。

参考にするものは、

このあたりがメイン。あと、『USB-Blasterもどきの製作』の DDT#1付録LaticceXP2-5E書き込みソフト も参考にさせてもらおうかと思っている。

いままでも xulaload は見ていて、わからなくなったら xilprg も合わせて見る -- みたいなことをしている。mcs ファイルと bitstreame ファイルの読み込みコードはそれで作成済み。

CABLE ドライバ

    前置きが長くなった。まずは、下位レイヤから設計を始めよう。

    serjtag/ft232r の avrdude 用ドライバは既に持っているわけだ。open/close まわりはほぼそのまま使う。だが、インターフェイスは大幅に変える。serjtag のプロトコルに近いものにして、ft232r の方を合わせる方針。

    方針はそれで良いとして... 機能の定義。単なる JTAG ならあまり悩まなくても良いのだが、付加機能がある。

    接続されている信号 を列挙すると

    FPGA um232r um162(mega32u2)

    TMS D7/RI PB0(SS)
    TCK D5/DSR PB1(SLCK)
    TDI D6/DCD PB2(MOSI)
    TDO D3/CTS PB3(MISO)

    M1 CB0 PD5
    M2 CB1 PD4
    PROG_B CB2 PC4
    INIT_B CB3 PD1

    DIN - (PD0)
    CCLK - (PC2)


    JTAG から Config するには、M2 = H , M1 = L としてから、PROG_B = H → L → H とする。INIT_B は、H になっているはずだが、エラーになると L になる。

    正確ではないかも知れないが、だいたいこんな感じの操作をする。
    DIN/CCLK は、Serial SLAVE モード(M = 111) での Config で使うもので、おまけ -- 後回し。

    MachXO2 には、PROGRAMN, INITN という端子があって、よく似た機能になっている。(M1/M2 相当は必要ない)

    こういったピンの割り当ては、設定ファイルで 定義できないと困りそうだ。ただ... あまり凝ったことはしたくない。それと、AE-UM232Rピン互換ボードの UM162 では、serjtag を使うが、こういうピンの定義がそもそもない。serjtag 自体拡張しないと。

    um232r.type = ft245r
    um232r.tms = 7 # D7/RI
    um232r.tck = 5 # D5/DSR
    um232r.tdi = 6 # D6/DCD
    um232r.tdo = 3 # D3/CTS

    um232r.init = 11 # CB3
    um232r.prog = 10 # CB2
    um232r.m2 = 9 # CB1
    um232r.m1 = 8 # CB0

    とりあえずこんな感じ。ルールは次のようにする。

    • um232r は CABLE 名 で定義可能
    • ft245r は CABLE ドライバの指定で、決まった名前。
    • # から後はコメントで 無視。
    • ピンの指定は、CABLE名.ピン名 = [~][0-9][0-9] で、~ は負論理を示す。あと、存在しないものは定義しない。

    この程度なら、ちょっとしたコードで解析できるだろう。
    ちなみに serjtag の定義はまた違うもの。tms/tck/tdi/tdo の割り当ては決まっている。init/prog/m2/m1 は GPIO 的につかうから似たような設定か。

    さて、CABLE ドライバの操作メソッドは、

    int setup_port(int tdi, int tms, int tck)

      TDI/TMS/TCK の値設定。

    注意) tck を 1 に設定すると、クロックの極性が逆になる。
    setup_port を呼ばないと 初期値は不定。

    int put_tdi_bits(uint8_t *buf, int bit_len, int flags , uint8_t *recv_buf)

     TDI にビット列を送り込む。

     flags には、受信データを記録する CABLE_RECIEVE と
     最後の TMS の状態を H にセットする CABLE_TMS_HIGH がある。

    ビットストリームは、1 バイトの中では、LSB first

    int put_tms_tdi_bits(uint8_t *buf, int bit_len, int flags , uint8_t *recv_buf)

     TDI/TMS の組の データ列を送り込む。

     flags には、受信データを記録する CABLE_RECIEVE がある。

    ビットストリームは、1 バイトの中では、LSB first 。送信データは、TDI TMS の順。

    int get_tdo_bits( int bit_len, int tdi, int tms, unsigned char *rcv_buf)

     TDI/TMS の状態を設定して (bit_len 分) TDO を読み取る。

    ビットストリームは、1 バイトの中では、LSB first 。

    int setup_gpio(int pin, int value)

      PROG/M1/M2 の設定。

    int get_gpio(int pin)

    INIT の読み取り

    これだけにする。これを使って JTAG のプリミティブを組んでいく。まずは、ここまでをやってみる。

verilator

    ツールは作成中だが、なにかと面倒。FT232R 版の枠組みは出来てきたが、それだけで 1000行近い。

    ツール作成に飽きると verilator が気になってくる。verilator は、Verilog のソースを C++ や SystemC に変換してくれるツール(コンパイラ)。Icarus Verilog のようなシミュレータと比べて 2 桁速いそうだ。

      Icarus Verilog の入出力をツールにつなげて、なんとか rtavr 自体のデバッグができないか考えていたのだが、これが使えるなら悩む必要もない。

    まずは、ちょいとビルド。古い MinGW 環境でも flex/bbison を入れるだけでビルドはできた。

    で、50A 用の rtavr を通してみる。

    ひとつにまとめた rtavr_50a.v を作り rom_data.mem と同じディレクトリに置いて、

    verilator --cc rtavr_50a.v

    とやってみると、やたら Waring が出る。

    %Warning-IMPLICIT: rtavr_50a.v:1833: Signal definition not found,

    ほとんどは、こんな感じのもので、sub module に対する bit 幅 1 のパラメータが定義されていないというものだった。文法上問題ないようだし、他のツールも Warning にならないからわざわざ対応するつもりはない。

      %Error: rtavr_50a.v:2739: Unsupported: Can't unroll generate for; condition not <= or <
      %Error: rtavr_50a.v:2739: For loop doesn't have genvar index, or is malformed
      %Error: rtavr_50a.v:2739: Unsupported: Can't unroll generate for; condition not <= or <
      %Error: rtavr_50a.v:2739: For loop doesn't have genvar index, or is malformed

    で、エラーはこれ。USART の UBRR のビット数制限で generate しているところ が引っかかるので UBRR_BITS を外す。あと port も generate 使っているから RTAVR_PORT_ESCALATION を定義することで generate しないようにする。


    %Error-BLKLOOPINIT: rtavr_50a.v:3853: Unsupported: Delayed assignment to array inside for loops (non-delayed is ok - see docs)

    次は、ram の 0 初期化 (initialize での for 文) GPR_INITCLR, SRAM_INITCLR を外すことで対応。

    そうしたら... なんか出来た。

    -rw-r--r-- 1 suz Administ 200421 Jun 4 12:12 obj_dir/Vrtavr_50a.cpp
    -rw-r--r-- 1 suz Administ 19935 Jun 4 12:12 obj_dir/Vrtavr_50a.h
    -rw-r--r-- 1 suz Administ 1521 Jun 4 12:12 obj_dir/Vrtavr_50a.mk
    -rw-r--r-- 1 suz Administ 617 Jun 4 12:12 obj_dir/Vrtavr_50a__Syms.cpp
    -rw-r--r-- 1 suz Administ 1023 Jun 4 12:12 obj_dir/Vrtavr_50a__Syms.h
    -rw-r--r-- 1 suz Administ 1133 Jun 4 12:12 obj_dir/Vrtavr_50a_classes.mk

    で make してみる。

    cd obj_dir
    make -f Vrtavr_50a.mk

    そうしたら、Vrtavr_50a__ALL.a が生成された。... なんかいけそうな感触。

    エミュレータじゃなくて これをツールに統合すれば、プログラムや I/O 周り (SPI_SLAVE) のデバッグができそう。SMP もいけるだろう。ちょっと面白くなってきた。

    ただ、こっちは、JTAG 関係は必要ない。こっちに走ると JTAG ツールが後回しになってしまう。しばらくいじるのを我慢しよう。

LCMXO2280C-B-EVN (MachXO 2280 Breakout Board Evaluation Kit)





    LCMXO2280C-B-EVN というのが、Digikey で 2700円で売られているのを知った。

    デバイスは、MachXO-2280 でひとつ前の世代だが、一応 2280 LUT で MachXO2 Pico Dev kit より多い。
    そんなことより、Digikey ですぐ買えて、FT2232 が載っているのが気に入った。

    実をいうと FT2232D は持っていない。ツールでは、FT232R と同じ コード(BitBang) で 対応しようと思っているのだが、MachXO2 Pico Dev kit は、すぐには入手できそうにないし困っていた。

    ツールを作るには、(ツールのテストのために)確実に動くものが欲しいし、安価だし、願ったりかなったりなので、購入することにした。

      ちなみに、秋月の FT2232Dボード 改めて見ると 1450円となんか安くなっている。ただ汎用 JTAG CABLE として使うには、AT93C56 の入手がネック。

    ... というか、これで rtavr のデバッグまでいける。そうなると artemis ボードを作らなくとも済むようになってしまう。artemis ボードを組むのがますます後回しになるが、まぁ経験を積んだ後でも良いかも知れない。いまさら急いでもという気持ちになっている。

      ちなみに、Lattice 純正なのだから書き込みツールは不要。だが、JTAG と内部でつなげて ISP したり、SPI 通信したりするのにツールを使いたい。書き込み機能は不要でもツールの設計の確認のために、おまけで作っておくつもり。

    Lattice の合成ツールを入れるためには、空き容量をなんとかしないといけないのだが、実は SSD も新調した。
    現在の SSD の erase count は 3000 ぐらいで、まだ 1年〜2年ぐらいは持つのだが、使えなくなったときに入手できないと嫌なので、64GB を買うことにしたのだ。

    ところで、『FPGAボードを使う計画』-- ステップ(8) I/O ボードを Spartan-6 で作る。というのがあるのだが、TQG144 では、ピンが足りないことが予想された。かといって BGA など電子工作レベルでは無理。だが、LCMXO2280C-B-EVN は、やたら入出力が多い。

      ピンヘッダで 320pin 分あるが、デバイスは、LCMXO2280C-3FTN256C だそうだ。
    • 製品ページ (英語)

      ユーザーズガイドを見ると LED が 8個載っている。(下の写真の 右:D1〜D8) 。オシレータを内蔵しているし、とりあえずは、これで十分。なにも接続せずにデバッグできそう。

      サイズはよくわからないが、だいたい 7.5cm 四方。(穴の数を数えたら 縦横共 30個だった。-- 7.62 cm 四方)

      ユーザーズガイドを見ると FT2232HL って書いてある。D じゃなく USB Hi-Speed 対応の高速版!これはお得かも。(ちなみに MachXO2 Pico Dev kit は FT2232D も "H" -- ユーザーズガイドに書いてあった。)

      FT2232HL との接続は JTAG の 4 つの信号のみ(JTAG 用ピンヘッダとパラレルに接続)。他は NC でコネクタすらない。JTAGは、シリアルとの互換性をまったく考慮していないが、保護用抵抗が入っている。

      machxo_bo.tck = 0 # ADBUS0/TXD
      machxo_bo.tdi = 1 # ADBUS1/RXD
      machxo_bo.tdo = 2 # ADBUS2/~RTS
      machxo_bo.tms = 3 # ADBUS3/~CTS

      こんな接続。

    I/O ボードは、これで良いのではないかという気がしてきた。FusionPCB の 10cm x 10cm も安くなったし、これをマウントするマザーボードを作っても良いかもしれない。先の話だが覚えておこう。

    ... と思ったのだが、320穴もの ピンを ピンヘッダ-ピンソケットで 接続すると 二度と外せなさそう。だいたい 2x40 を 両側に 1つづつ付けるぐらいが精一杯 のような ...

    そういうことだとすると、いったいどうやって使うのが良いのだろう?

    まずは、コネクタの割り当てを見てみる。

  • J5-J6...J10-J9

      USB コネクタを下にすると、上下サイドに付くコネクタは、上から J5-J6...J10-J9 になる。

      J5 と J10 は信号線がみっちり詰まっていて、GND すらない。一方 J6/J9 は 電源系が多く 信号線はすくない。特に J9は、LED を除くと 信号線は 5 本しかない。(J6 は 12本)

      ただその 5本は重要そうな感じで CLK0-3 と SLEEPN 。

  • J3-J4..J8-J7

      J3,J8 は、作動ペア 2 本づつが GND とともに配置されている。(14ペア)。
      J4,J7 は、2,4..22,24 が GND で、25,27 が N.C. 。

      ケーブルで引き出すのに向いているかんじ。

    ... となると、マザーボードに付けるなら 上下サイドにピンソケットを下向きに付けるのが良いのだろうか? J5,J10 をメインにして、J6/J9 は電源供給(他)を目的に 一部だけ使う .. みたいな。

    逆に、小基板を載せる.. なら 5cm 四方ぐらいのサイズで 済むから具合が良さそう。ただし、アクセス性が悪いから 何を載せるかは悩ましい。

      構想どおりなら、SDRAM と MicroSD スロット x N 。と水晶ぐらい?

      ... おもいだした。5cm x 5cm なら 40pin 分は無理。19x19 のサイズ(穴は 18x18)まで。-- 片側の 4 列をつなげると 反対側に届かない。それなら、片側だけ使うものとして設計すれば良いか。

      中央に J10,J9 を使った SDRAM + クロック ボードを置いて、左右に インターフェイス変換基板 (MicroSD x 4 と ARTEMIS 通信用 2x5コネクタ x 4 + USB みたいなかんじ) を考えてみよう。

      ... 今そういうものを作りたいわけではなかった。今は、そういう構想のもとに、ピンヘッダ/ソケットをどう付けるかだけ決める。

      2x40 低メス (40円) を J5,J6 と J10 に 付けることにして、左右はさわらない ことにしよう。

      C 基板を付けるなら、スルーホールにして、中央に縦にマウント。ピンヘッダは、必要な分だけにしておかないと 外すのがやっかいになる。

      で、とりあえずやりたいのは、セラミック発振子 とか 水晶発振子 で発振できるかのテストぐらい。

    (おまけ)邪な考えだとは思うが、J9 の 上の列 (下から 2 番目の スルーホールの列) で切ってしまうとどうなるのだろう? ひょっとして USB Jtag ケーブルとして使えるのだろうか?

      MachXO は、MachXO2 とは違い JTAGENB というピンはなく ユーザI/O として使えないようだ。ユーザ I/O として使えれば、他の I/O ピンに接続するとか ができるのだが...
      あと、Config は JTAG のみのようだから、切り離した FPGA の利用は難しそうだ。

    当面は FPGA も必要なので、そのようなことは実行しないつもりだが、不要になってしまったら、そういう形で再利用できるかも知れない。

ツールの状況とか

    遅々としてなかなか進まないのだが、ft232r 用の コードはコンパイルが通った。あと、てきとうな conf ファイルの読み込み部分はできた。serjtag に移っているが、serjtag デバイス側に問題があったりして、ちょっと困っている。

    さて、Lattice Diamond をちゃんとインストールしてみた。MachXO2 用の Config で rtavr を試してみると ... エラー。ブロック RAM が 9kb x 3 しかないのが原因だった。RAM 1KB , ROM 2KB に変更してみたら OK 。規模は、548/1140 スライスだった。

    JEDEC ファイルというのが、生成され これを tool->> programmer で ispVM に渡して書きこむ手順。ispVM は、ライタソフトで、FT2232 経由で書きこむことができる。

    書きこむだけなら、ここまでの理解でできることはわかった。

    JEDEC ファイルをどうやって読み込んで、どういう JTAG 操作で 書きこむのかまでは、よくわかっていないのが現状。『USB-Blasterもどきの製作』の DDT#1付録LaticceXP2-5E書き込みソフト を見させてもらって理解しようと思う。

    LCMXO2280C-B-EVN (MachXO 2280 Breakout Board Evaluation Kit) は、すみやかに NARITA まで来たのだが、まだ受け取れていない。箱を開けて即書き込みできる状態にはなっているが、どうやってテストするかが、まだまだ。

    まずは、JEDEC ファイル

  • ELM: PLDフューズファイルについて (1997.7)

    が参考になった。実際のファイルを見ると

      ^B
      *
      NOTE xxx が続く


      QF486576 # 486576 bit の情報
      G0*
      F0*
      L000000
      1/0 が続く
      *
      CC8F6*     # データのチェックサム(16進数)
      N User Electronic Signature Data*
      U00000000000000000000000000000000*
      ^C6523     # ^C の後 文字コードのサム(16進数)

    デリミタは、* だが行末にしか来ないようだし、簡易パーザなら簡単に作れそう。

    さて、どうやって Config するものなのか ... XP2Write を眺める。

    int JtagCableOpen(int num=0);
    void JtagQueSIR(PUCHAR tx,unsigned bitadr,unsigned bitlen,int read=0);
    void JtagQueSDR(PUCHAR tx,unsigned bitadr,unsigned bitlen,int read=0);
    void JtagQueIDLE(unsigned clocks);
    int JtagFlushQue(PUCHAR rx=0,unsigned rxbits=0,int check=1);
    void JtagCableClose();

    jtag.h で定義されている Jtag のプリミティブはこう。-- 実は JTAG の操作をよく知らない。SIR/SDR を基本とすれば良いわけか。なるほど。

    で、XP2WriteDlg.cpp にこれを使っているコードがある。コードは長いがなにをやっているかはわかりやすい。

    tx[0]=0x16; //IDCODE
    tx[0]=0x1C; //Preload
    tx[0]=0x15; //Enter programming mode
    tx[0]=0xB2; //Read status
    tx[0]=0x03; //Erace
    tx[0]=0x1E; //Leave programming mode
    tx[0]=0x21; //InitAddress
    tx[0]=0x67; //ProgramIncrRti
    tx[0]=0x52; //Program/Status
    tx[0]=0x1A; //program user code
    tx[0]=0x21; //Reset addr
    tx[0]=0x17; //Read Usercode
    tx[0]=0x45; //program sed crc
    tx[0]=0x44; //read sed crc
    tx[0]=0x2F; //program done bit
    tx[0]=0xFF; //Bypass ...to enter usermode?

    8bit の IR を登場順に拾っていくとこんなかんじ。-- 随分あるものだ。

  • TN1086: MachXO JTAG Programming and Configuration User's Guide (pdf)

    DS1002: MachXO ファミリ データシート (日本語 pdf)』には、これを読めと書いてあるのだが、こんな情報は載っていない。

      分かるのは、JTAG 1532 を通して Flash に書き込む方法と 直接 Config する方法があり、Flash からの Load指令(Refresh) もできるということぐらい。

    ... JTAG 1532 では、BSDL ファイル にコンフィグ方法が定義されている ... らしい。

      ここからダウンロードして眺めてみることにしよう。

      見たのだが... なにかそれらしいことが書いてあることは分かる。IR の定義も分かる。だが、アルゴリズムは直感的にはよくわからない。XP2WriteDlg.cpp と XP2 とを見比べて みるしかないか。それで理解が進んだら、今度は XP2 と MachXO,MachXO2 を見比べる -- って そんな手順以外ないのだろうか?

        よくよく見たが、アルゴリズムなんて載っていない。載っているのは、IR に対応した DR の名前と bit 幅。


        DR IR XP2_5E XO_2280 XO2_1200
        ISC_ADDRESS  ISC_ADDRESS_SHIFT   1938 1116 333
        ISC_DATA   ISC_DATA_SHIFT   638 436 1080
        ISC_PDATA ISC_PROGRAM,ISC_READ 638 1080
        ISC_PDATA VINCR_RTI,ISC_READ 436
        ISC_SECTOR ISC_ERASE 8
        ISC_CONFIG ISC_ENABLE,LSC_ENABLE_X 8
        ISC_CONFIG ISC_SETUP,READ_SETUP 4

        ちょっと比べてみたのだが、定義上は微妙に違う。手順も似ているが微妙に違うのだろうか?

        あと、『Lattice XP2のC-SRAM書き込みモードに対応しました』という記事を発見。ただ、そういうことが可能であるということしか分からない。

        どうも Lattice の場合 config は、Flash に対してやるものであって 直接 config は、optional みたいな感じがする。MachXO2 の場合、SPI や I2C でも config できるが 直接 config は、JTAG だけだし。

        一番の問題は、ドキュメントを見付けられていないこと。

        TN1204 MachXO2 Programming and Configuration Usage Guide の Appendix B. MachXO2 Slave SPI Programming Guide に 例が載っている。

        この例が、XP2Write のコードに似ている。比較していけば、MachXO2 の Flash への config はできるようになるかも知れない。だが、もっと 直接説明した ドキュメントはないのだろうか?

      ちょっと大変そうなかんじだ。もともとは、(後で困らないような) Jtag のメソッドを決めるために 調べてみようと思っただけ。その観点でまとめて次にいこう。

    • Lattice の場合、IR コードに多数のコマンドが定義されている。これはちょっと想定と違った。DR に流し込むデータにコマンドも含まれているのが普通だと思っていたのだ。

      設計にあまり影響はないが、SIR と SDR を頻繁に切り替えて使う場合もあることを想定しておく。

      JTAG の扱い方はよく知らないわけだが、デバイスに対して、IR の設定と DR の読み書きができれば良さそうな印象。

      JTAG chain は、とりあえず考えない。当面使う予定のものは chain がない。デバイスの選択という概念は、とりあえずなしにして、カレントのデバイスのみを操作するような API だけ作っていこう。

    • Lattice のコンフィグは、とりあえず必要ない。とりあえず必要なのは、JTAG 使った ISP と通信。これを先にしよう。

      ... といってもデバイスによって手順が違う。デバイスのドライバは必要だが、部分的にサポートするような構造になる。

    • FPGA を直接 config するのと (SPI_FLASH とか)FLASH を書き込むのは全然別のものと考えていた。

      SPI_FLASH の書き込みは、FPGA 内に作りこんだ回路との通信を想定していた。無駄が多いが、Lattice でも MachXO2 ならそのようなものは作れる。とりあえず、その構想のまま行く。

      作りたいのは、ライタソフトではないのだ。あくまで、JTAG を通して通信するのをサポートするツールで その仕組みの応用として FLASH の書き込みができるなら対応を考える。直接 config するのは、これを作るためにも必要だし、基本機能として考える。... ということにしよう。

      MachXO は JTAG 以外からの FLASH の書き込みは できないような感じだが、Breakout ボードしかつかう気がないし そうであれば なにも考えずに 純正ツールで書き込めるわけだから、気にしないことにする。

    BSDL ファイル のチェック

    そういえば、『LatticeXP2のFPGA回路内部へJTAGで通信する』 の記事には、

      JTAGEモジュールを有効にするには、JTAGプライベート命令のIPA(0x32)とIPB(0x38)を使います。インストラクションレジスタにIPA命令を入れるとJTAGEモジュールの信号系統1が有効になり、IPB命令を入れると信号系統2が有効になります。

    と書いてある。これは BSDL ファイルに記載されているのだろうか?

    " IPB (00111000)," &
    " IPA (00110010)," &

    MachXO の場合はこう書いてある。大丈夫そうだ。

    "PRIVATE (00000010, 00111010, 00110010, 10111010, " &
    "11011101, 11001010, 00111000, 01100000, " &

    だが、MachXO2 の場合、PRIVATE の中で記述してあるだけ。
    JTAGF という機能はあるから出来ないわけではないが、enable にする手順が違うかも知れない。ただ、XP2 の場合も 同様だからたぶん大丈夫だろう。(内容訂正)

    ここでつまずくと全然面白くない。MachXO2 Pico Dev kit が欲しかったが、とりあえずは、MachXO Breakout で良かったのかも知れない。

FPGA との通信の方法(めも)

    一番作りたいものは、これなわけだ。いったいどうするのか整理しておこう。ただし、どれも未確認なので要注意。

    MachXO の場合は、『LatticeXP2のFPGA回路内部へJTAGで通信する』 の記事がとても参考になる。

    Diamond 1.1 で使った限り違うのは、lscc/diamond/1.1/cae_library/synthesis/verilog/machxo*.v に定義があり、インスタンシエートする必要はないということと、MachXO では、JRSTN ではなく JRST になっているということぐらい。

    さて、IPA と IPB を 使って 2 つのチャネルが作れる。 『JCE1は、Capture-DRもしくはShift-DRのときにHになります。』ということだから、JCE1/JCE2 が H のときにそれぞれのチャネルが動作するようにしておけば良いのだろう。

    使い方は、チャネル1(IPA) は、SPI として 通信に使う。チャネル2(IPB) は、rtavr の ISP に使うことにした。SPI_FLASH の書き換えは、rtavr の SPI を通して接続する予定(希望)だが、そんなまどろっこしいことをせずに、SPI_FLASH の線と直結するかも知れない(未定)。いずれにしても チャネル1に接続。

      これらの通信を、JTAG のフルスピードで行うとまずい場合がある。rtavr の ISP は、rtavr の 周波数 (CLK2X / 2) の X 倍を超えてはいけないとか なにか条件がある。チャネル1(IPA) を rtavr の SPI につなぐ場合は、もっと厳しく 1/2.5 以下とか。しかも連続で送れないとか ファームウェアの都合に起因する条件もある。忘れてはいけないのでメモ。


    ___ ___ ___ ___
    JCK _____| |___| |___| |___| ....
    _______________________
    JCE1 & JSHIFT _____| |____

    IN SFT IN SFT IN SFT

    どうもこんなタイミングで動かしてやれば良いらしい。

    注意点は、両方とも 論理が逆なので、SPI と接続するときは反転して入力。MSB first か LSB first かは通信規約によるが、普通の SPI なら MSB first 。

    あと Shift-DR でしか使えない。いったん Shift-DR に入ったら その状態でずっと使うのが基本。bit 同期を取り直すなら、Shift-DR を抜けて再度 Shift-DR に入り直す。

    ISP はいまのところ RESET 状態でしか使えない。( JCE2 & JSHIFT ) を rtavr の RESET に入力することにしよう。

      rtavr で、CPU を一時止める機能は、作れないことはないのだが、そうなると ISP に RESET のための レジスタ定義と レジスタへのアクセスメソッドの追加が必要になる。面倒というより論理が増えるし、メリットも感じないので とりあえずパス。

    MachXO2 では、IPA/IPB がない。どうするのかは、要調査。 でも たぶん同様。

    さて、同じ機能を Spartan-3A で使うには BSCAN_SPARTAN3A を使う。これもチャネルが2つある。チャネルの選択は同様で、IPA/IPB の代わりに USER1(0x02)/USER2(0x03) を使う。

    同様の定義にするなら、JCE1/JCE2 , JSHIFT の代わりに SEL1/SEL2 , SHIFT を使う。TCK も同様だと思うのだが、タイミングが違うかも知れず扱いかたが変わるかも知れない。TCK の代わりに DRCK1/DRCK2 を使ったほうが良いかもしれない。こちらは、Shift-DR と連動するので確実かも。(その場合は、SHIFT との AND は不要 -- というかするとまずいかも)

    Spartan-6 では、また違うのかも。4 つのチャネルが定義できて module の仕様も変わった。要調査。

Xilinxの config の方法(めも)

    FPGA の config をどうしても作らないといけないのは、自作 ARTEMIS ボードの Spartan-3A 。-- CABLE が独自だから代用ができない。

    ただ、基本はすごく簡単なような ...

    JPROGRAM にして CFG_IN で bitstreame の内容を叩き込んで JSTART 。これだけのような ..

    ただ、チェックとかはしないといけない。ステータスを見るには、READ_STATUS のシーケンスを CFG_IN で流して CFG_OUT で読むようだ。

    SYNC_TIMEOUT
    SEU_ERR
    DONE
    INIT
    MODE
    VSEL
    GHIGH_B
    GWE
    GTS_CFG_B
    DCM_LOCK
    ID_ERROR
    CRC_ERROR

    xulaload』のコードを見るとこれだけある。ちゃんと終了したか 。エラーなら理由は何かぐらい見ないと。

      INIT_B を接続したが、不要なのか。ちなみに M1/M2/PROG_B は、SPI_FLASH からのロードを強制的に行ったり、スレーブシリアルモードにしたりする場合に使い、普通は不要。

      ついでに書いておくと 相手が入力専用の TXD 以外 は抵抗を入れるべきだった。(スペース的に入れられたかどうか分からないが)。

    同じようにしていろんな情報が取れるようだが、そこまでしなくて良いだろう。

    Lattice のデバイスも このレベルなら簡単なのだろうが ... 今はよくわからない。まぁぼちぼちやろう。

通信機能のプロトコル

    SPI をシリアルのように使いたい。どのような通信ルールにするか。

    JTAG を使うのだから HOST 側はポーリングしないといけない。これはやむを得ないとして...どういうやり方が良いのだろう?

      (案1)ステータスを読む/送信する/受信する/ といったコマンドを作る。

      (案2)0xff は、データがない という意味にして、送信データがある場合は、データを送り ポーリングする場合は、0xff を送る。受信も同様で、データがなければ 0xff が読める。

    (案1)は、ありがちで悪くなさそうなのだが、コマンドを決めないといけないし、変更すると混乱するから決めたものをずっと使うことになる。コマンドを決めるのに悩みそうだし、拡張が可能だから安易に拡張したくなるという罠もある。

    (案2)は、シリアルの代替にしか使えなさそうだが、その分明快だ。こっちにしようかと思う。

    ツールでは、terminal-mode というモードにして、このモードに入るとキー入力を送り 、受信データを そのまま表示する。MSYS の rxvt の上で動かすと 端末ソフトで通信しているのとあまり変わらない感じになるはず。モードから抜けるのは、~. とか。

SVF ファイルと ispVM

    SVF ファイルとは、どういうものか知らなかったので ググってみたら TEXTファイルだと書いてあった。
    MachXO2280 への Implement はできていたので SVF に変換して読んでみたところ ..

    なんだか可読性が良いではないか。これなら、なにをやっているか(かなり)理解できる。随分参考になりそうだ。この情報と XP2Write を合わせて見れば、ライタも作れそうだ。

    で、MachXO2 のほうも同じようにしようとしたら .. Export Files に JEDEC file の項目が出ていない。
    理由がわからないので、新しい ispVM だけ インストールしてみることにした。

    で、インストールされるものを眺めていたら なにかソースコードもある。
    CPUEmbedded/PCM, CPUEmbedded/SCM, ispSlimVMEmbedded, ispVMEmbedded, SSPIEmbedded ... なんだろう?

    JEDEC file の項目が出ない件についてはわからない。Diamond 1.2 の日本語ドキュメントが出ていたから 早々と 1.2 にするのが良いのかも知れない。

      update チェックをしたら B1.1.01.50.42.10_xo2_1200JEDEC というそのままズバリな名前のパッチがでていた。 10MB ほどなので、Diamond 1.2(既に出ていた)にせずに パッチで済ませることにした。

      XO2 も いずれ 2000/4000/7000 が出てくる。バージョンアップは、そのときでいいや。

      (追記) 確かに JEDEC は作れた。しかし ... SVF への変換でエラーになった。Diamond 1.1 付属の ispVM は、17.9 。単独で インストールする ispVM は、18.0 なので試してみたが、これもダメ。待つしかないようだ。

    あと ググっていたら、『XAPP058 には、エンべデッド SVF ファイル プレーヤのソース コードが掲載されています。』という情報も見付けた。ちょっと見てみようかと思う。

    たぶん JTAG レイヤーの プリミティブは、こういうのと同じレベルにするのが良いのだろう。参考にしたい。

      ちょっと 『XAPP058 (日本語 pdf)』 を読んでみた。XSVF というバイナリに変換したものを入力して JTAG を操作するエンジンがあるらしい。

      で、フロチャートを見ると XSIR, XSDR に加えて XRUNTEST の 3 つの処理しかない。XRUNTEST は、delay の役目がある。sleep とは違い クロックを出している。MMC/SD カードで クロックを出していることが重要な場合があったが、JTAG はどうなんだろうか? -- 少なくとも ユーザ回路での SPI 通信で クロックだけが欲しいような設計はあり得る。

      そういうプリミティブも必要そうだ。あと API を決める上では、SPI通信が悩ましい。rtavr の場合、バイトデータを連続して送ると ファームウェアの処理が間に合わないのが明白。クロックを 100kHz ぐらいまで落とせば良いわけではあるが... せめて SPI をダブルバッファ化すべきかも知れない。あるいは... FIFO の CPI を使うことにして、SPI ブリッジを入れる... とか。

      少なくとも クロックだけを動的に変更する API は必要そうだ。

    SSPIEmbedded をちょっと見たのだが、『Slave SPI (SSPI) Embedded』が名称。 algorithm file and data file. を入力して SPI 経由の コンフィグをするものらしい。algorithm file は、コンフィグの手順を抽象的に定義したものというより 単なるステートマシンのパラメータみたいな気がする。

    API を決める上での 調査は、これぐらいで良いだろう。

JTAG レイヤの API

    void jtag_go(CABLE cbl,int state);

    void jtag_init(CABLE cbl);
    void jtag_IDLE(CABLE cbl, int ms, int count);
    void jtag_SIR(CABLE cbl, unsigned char *buf, int bit_len, int flags, unsigned char *rcv_buf);
    void jtag_SDR(CABLE cbl, unsigned char *buf, int bit_len, int flags, unsigned char *rcv_buf);

    void jtag_SIR32(CABLE cbl, unsigned int code, int bit_len, int flags, unsigned int *rcv_data);
    void jtag_SDR32(CABLE cbl, unsigned int code, int bit_len, int flags, unsigned int *rcv_data);

    こんな風に決めた。

    jtag_init は、RunTestIdle 状態まで持っていく。
    jtag_IDLE は、RunTestIdle 状態 にして、count 分 (tms,tdi) = (0,0) を送出。count が 0 なら ms (ミリ秒) を元に count を計算。

    jtag_SIR/SDR は、ShiftIR/DR 状態にして、buf を送出。flags が 1 なら rcv_buf に TDO を採る。
    状態は ShiftIR/DR のまま。

    jtag_SIR32/SDR32 は、32bit までのデータを扱う場合にコードを簡潔に書くための API 。

    jtag_go は内部関数。RunTestIdle, ShiftIR, ShiftDR にしか行けない。

    XP2Write なんかは、FLush という概念がある。キューに溜め込んでおいて、複数の 処理をまとめてやることでUSBの遅延の影響を少なくするわけだ。

    決めた API では、受信データを要求された時に、自動で SYNC するという構想。serjtag のプロトコルでは、送出のみとか all 0 の送出では、送出データを送らないとか、TDO の値は、要求されたときだけ採取して返すようになっているので 送受信データ量も減らせる。ft245r (BitBang) では、データ量は減らないが、自動で SYNCというのは有効。

    関数は 全部 void 。どうせ受信データをチェックするから、いちいちチェックしなくて良いだろうという考え。

TARGET レイヤの API

    typedef struct target *TARGET;

    struct target {
    int (* sel_chan)(TARGET tgt, CABLE cbl, int chan);
    int (* program)(TARGET tgt, CABLE cbl, unsigned char *buf, int len);
    int (* verify)(TARGET tgt, CABLE cbl, unsigned char *buf, int len);
    };

    int tgtxil_init (TARGET tgt, CABLE cbl, unsigned int device_id);

    とりあえず、こんな風にした。SPI_FLASH の program は、もっと上位のレイヤ。
    program/verify は、FPGA の直接 config で、RAM だけの 書き込みを想定。program/verify は作れなかったら常に ERROR するようにする。

    sel_chan は、簡単だが最も重要。これでお膳立てをして、あとは、jtag_SDR/jtag_SDR32 で通信する。
    ちなみに bitclock を変えるのは、CABLE の API 。

    こんなわけで、ようやくツールづくりが回り始めた。ちょっとがんばってみよう。

いろいろ問題が出た。

    まず、jtag 。

    ShiftIR/DR 状態のまま終わるのは、無理。最後の bit は、TMS=1 で送出しないといけない。

    これで最後という場合は、flags に 0x2 を付けることにした。... で、ターゲットの コンフィグのコードを書いて見たら、全部 0x2 が付くことになった。むしろ続く場合に 0x2 をつけた方がよさそうだ。

    あと、状態が増えた。ちなみに、通信する場合も 1 つのブロックの処理をしたら いったん終わらせた方が良いかもしれない。CS の操作と同じなので bit 同期がとれる。

    次にターゲットの API 。verify できるものなのかどうか良くわからない。xilinx の場合すごく大変そうだし、lattice の場合でも いったんプログラムモードから抜けたら読めるものなのかどうか?

    program のときに verify なり CRC チェックなりをすることにして、verify プリミティブは削除しても良いかもしれない。lattice で verify だけ出来るのなら削除しないが、無理だったら削除することにしよう。

    あと lattice では特にいくつかのパラメータが必要。最初に PRELOAD する bit 幅がまず必要。次に アドレスサイズとデータ幅。

    XP2 と MachXO は、手順がかなり似ているが、違う部分もある。MachXO2 も 多少違うはず。
    これらの違いへの対応は、IDCODE で判断するつもり。

    ... だいぶ具体的なことが書けるようになってきた。もうすぐベースは出来るだろう。

まだまだ

    なんと、Lattice の IDCODE は、ファミリで 1種類だった。... ということは IDCODE をパラメータとして渡しても コンフィグ できない。で、xx_init のパラメータは、LCMXO2280 とか名前で渡すことにした。

    あと、Lattice XP2 と MachXO では、似ているものの やはり違いは大きい。SVF ファイルを見ると違いが良く分かる。

    /* XP2 only */
    #define ISC_PROGRAM_STATUS 0x52
    #define ISC_ERASE_DONE 0x24
    #define PROGRAM_SED_CRC 0x45
    #define READ_SED_CRC 0x44

    /* XO only */
    #define ISC_SRAM_ENABLE 0x55
    #define DATA_SHIFT 0x02

    SIR で これだけ違う 命令を使う。ステータスの読み方なんかも違う。program() 自体別立てにした方がすっきりしそうだ。

    一方 Xilinx の方は、IDCODE でデバイスまで分かる。だが、デバイスが違っても コンフィグするコードは FPGA なら 同じ。

    さて、jed ファイルの読み込みも いんちきパーザを作ったので読み込めるようになった。デバイス固有のパラメータは、プログラムの中にテーブルを作って対応することにした。MachXO に関する 下位レイヤは揃ったことになる。後は上位レイヤだが、なかなか悩ましい。

MachXO2 の SVF が作成できた。

    ispVM には、SVF の作成方法が 2 つある。試してだめだったのは、UFW での 作成で、組み込みの SVF 作成機能は OK だった。それだけでなく、Verify だけする設定とか、SRAM だけ書き換える設定があった。-- ispVM を起動しただけでは UFW しか動かせないので 実際にデバイスが接続されていないとダメなのかと早とちりしてたのだ。

    SRAM だけ書き換える設定は、MachXO や XP2 にもあるから SVF を作れば、想定どおりのライタが作れる。
    問題は、組み合わせが沢山あるから、どういう API にして 関数をどう作るか。

    一応、SRAM への書き込みを default にして、Flash の書き込みは option にしようかと思う。verify も同様。あと ERASE のみというのも、必要なのかも知れない。これは FLASH のみ。

    で、MachXO (LCMXO2280) と MachXO2 と XP2 (LFXP2_5E) に対応するつもり。今 LCMXO2280 は持っているからテストできる。MachXO2 は、1200 以上をこれから使っていこうと思っている。LFXP2_5E は、雑誌付録でまだ入手可能。それ以外は対応するつもりはない。

    ちなみに、Xilinx は、XC3S50A/XC3S200A と XC6SLX9 のみを予定。-- 要するに自分が使う予定があるもののみ。

Lattice の SVF を整理。

    Flash の Erase , Program, Read と SRAM の Program , Read を XP2/XO/XO2 について出力して比べて見た。

    見ているとどうもいくつかのプリミティブに分けられそう。

      その前に、読み書きする対象について。

      XO は最も基本的で コンフィグデータ と USERCODE の 2 つ。XP2 はそれに SED_CRC が付く。で、コンフィグデータの書きかたは、SRAM と FLASH であまり違いはない。-- SRAM に書いて WRITE-BACK しているような印象。

      XO2 は、SED_CRC はないが、FEATURE というのがあるようだ。それに加えて、FLASH での WRITE では、ADDRESS を WRITE している。どういう概念なのか良くわかっていない。また XO2 は、SIR の命令も随分違う。XP2/XO とは、大分違う印象だ。

    まず、Enter_Programming_Mode と Exit_Programming_Mode , この手続きは デバイスが同じなら同じ。

    あと、Program_Done 。更新系では、Exit_Programming_Mode の前に行う。エラーが起きた場合、Program_Done してはいけない(たぶん)。

    この間で、読み書きする。たぶん Erase → Program → Verify(Read) に分けることができて 独立したプリミティブに出来そう。 あと、SRAM と FLASH は、それぞれのプリミティブのパラメータに出来そう。( Program_Done も SRAM と FLASH の区別がいるかも )

    読み書きする対象はいくつかあるのだが、単一のメモリブロックということにしている。サイズは、決まっているので、コンフィグデータ , (SED_CRC/FEATURE) , USERCODE の順に配置するつもり。

    ただ、XO2 がどうなっているか、ちゃんと調べた後でないと確定できない。


    LCMXO2_1200 (SRAM):
    0 - 359639 (333 * 1080) Config data
    359640 - 359671 (32) USERCODE
    LCMXO2_1200 (FLASH):
    0 - 278399 (128 * 2175) Config data
    278400 - 343935 (128 * 512) UFM
    343936 - 344015 (80) FEATURE
    344016 - 344047 (32) USERCODE

    XP2/XO は、SRAM と FLASH に書くデータのサイズが同じで address_size x data_width で計算できた。(データの内容も同じ: 確認済)
    XO2 も SRAM に書くデータのサイズは、address_size x data_width で同じ。

    だが FLASH に書くデータは別のものであるらしい。そして、jed ファイルに入っているのは、FLASH に書くデータ。-- これは困った。jed ファイル は容易に作れるが SRAM に直接書けるものではない。

    SRAM に書くデータ は、ispVM を 起動すれば SVF で 作れるが手順が面倒。

  • TN1204: MachXO2 コンフィグレーションガイド (日本語 pdf)

    に書いてあることが少し理解できるようになった。

    • 設定は、「SpreadSheet View」の「Global Preferences」で行うが、まず GENERATE_BITSTREAM を ON にして .bit ファイルを生成しないと SRAM 用 SVF は作れない。COMPRESS_CONFIG は、.bit ファイルにだけ影響すると書いてあるが、ON にしないと .jed ファイルが生成されない。

    • FLASH のエリアは、CFM と UFM そして、Feature Row と USERCODE 。CFM は、"Configuration Flash" という記述で書かれる場合もある。Flash は、桁 x 行(Row) でアドレスされていて、Feature Row は ひとつの 行(Row) を USERCODE と共に使用する。

      CONFIGURATION のデフォルトは、CFG_EBRUFM となっているが、EBR(ブロックRAM) の初期値を UFM に置くとう意味で、ユーザロジックで書き換えが可能になっている。

    どうも MachXO2 では、SRAM 用のデータを作るのが面倒なようだ。だが、SRAM 用の SVF ファイルから取り出せば 作れないことはない。

    作ってどうするのか?

      Flash を読み書きする ロジックを SRAM だけで動かすように作るつもりだったのだが ..

      まぁ、すくなくとも、こういう特殊なものは、ツールで使うとか用途も特殊。そうであれば、一回作ったものを使い回すはずで、作成の手間は多少あってもかまわないのかも知れない。

      ちなみに 無圧縮 bit ファイルのサイズは、45376 バイトだった。情報量は、359640/8 = 44955 バイトで 差分は、421 バイト。

        Lattice Semiconductor Corporation Bitstream
        Version: Diamond_1.1_Pro duction (517)
        Bitstream Status: Advanced Version 1.62
        Design name: rtavr_test_rtavr_test.ncd
        Architecture: xo2c00
        Part: LCMXO2-1200HC-4TQFP100ES
        Date: Wed Jun 15 05:50:25 2011
        Rows: 333
        Cols: 1080
        Bits: 359640
        Readback: Off
        Security: Off
        Bitstream CRC: 0xF760

      421 バイトのなかには、こういう情報もヘッダとして入っているし、FEATURE ROW , USERCODE が別にあるはず。必要な情報を取り出すこと自体は容易そうだが、無圧縮の bit ファイルを作るということは、設定を変更して Implement しなおすということで、ispVM を起動して設定するより時間がかかる。

    Digilent JTAG SMT1



    あ、Digilent が、FTDI 採用している! ... と思ったら iMPACT から直接使えるのか。

    そうか。JTAG 界 は FTDI があれば、良いわけか。... そうなると 作っているツールは、LCMXO2280C-B-EVN (MachXO 2280 Breakout Board Evaluation Kit) に対応しておけば、万全といえる。

    ただ、EEPROM 設定済みの FT2232 は、Synchronous BitBang Mode が使えないかも。
    -- と思ったが ドキュメントを見る限り、大丈夫なようだ。

      ちなみに、MPSSE の使い方。ちゃんと対応すれば、30MHz もの bitclock で動作できる。

    • AN_135_MPSSE_Basics

      これ読むと MPSSE を使う場合でも Open , Close は同じで良いらしい。FT_SetBitMode からが違う。データの詰め方が違うところは、影響が大きいが、1つのソースで対応できるはず。

    • AN_108 -- これに MPSSE の詳細が書いてあるらしい。

      あと、実効性能は、MPSSE の場合、片道 20〜24Mbps 程度だそうだ。さて、Synchronous BitBang Mode はどれぐらいになるのだろう?

      FT232R と同様に設定可能な bitclock より 実効性能がボトルネックになるはず。FT2232HL のデータシートだと Synchronous FIFO Mode は 25MB/sec 以上と書いてある。Synchronous BitBang Mode は、送信データ量と受信データ量が同じだから 片道 12MB/sec ぐらい? 
      ... CLK の ON/OFF に 2 バイト送信するので、そこまで出るなら 6Mbps ぐらいということになる。

      MPSSE の 1/4 程度なわけだが、Config する程度ならデータ量は、50A , MachXO 2280 , MachXO2 1200 クラスだと 多くて 0.5 Mbit ぐらい。 バウンダリスキャンをして パラレルの Flash に書きこむような使い方だと いくらでも性能は欲しいが、Config する程度ならば十分すぎるぐらい。FT232R 使っても あまりストレスはないだろうと思える。

    ついでにいろいろ見ていたら、Hi-Speed シングルチャネルの FT232H なんてものがある。



    FTDI 純正の モジュール UM232H (1801円) なんてのも出ている。(データシート)

    MPSSE も使えるし、JTAG 用に便利かも。... あとよく見たら CLK 付きの Fast Serial がある。... これは PDI に使えるかも。

ツールの進捗状況。



      jtag_IDLE 20ms = 6.064 ms
      jtag_IDLE 20ms = 19.870 ms
      jtag_IDLE 200ms = 202.916 ms
      ft245r: bitclk 460800 -> ft baud 230400
      jtag_go JTAG_STATE_IDLE - JTAG_STATE_SIR : 4 00000a
      put_tdi_tms_bits 4:0 1100
      rcv_data 0 :
      put_tdi_bits 8:0 01101000
      rcv_data 8 :11011100
      jtag idcode I = 0000003b
      jtag_go JTAG_STATE_EXIT1_IR - JTAG_STATE_SDR : 7 000228
      put_tdi_tms_bits 7:0 01101000
      rcv_data 0 :
      put_tdi_bits 32:0 11111111111111111111111111111111
      rcv_data 32 :11000010000010110001010010000000
      jtag_go JTAG_STATE_EXIT1_DR - JTAG_STATE_IDLE : 4 000028
      put_tdi_tms_bits 4:0 0110
      rcv_data 0 :
      jtag_go JTAG_STATE_IDLE - JTAG_STATE_SIR : 4 00000a
      put_tdi_tms_bits 4:0 1100
      rcv_data 0 :
      put_tdi_bits 8:0 01101000
      rcv_data 8 :11011100
      jtag idcode D = 0128d043
      jtag idcode I = 0000003b
      jtag_go JTAG_STATE_EXIT1_IR - JTAG_STATE_SDR : 7 000228
      put_tdi_tms_bits 7:0 01101000
      rcv_data 0 :
      put_tdi_bits 32:0 11111111111111111111111111111111
      rcv_data 32 :11000010000010110001010010000000
      jtag idcode D = 0128d043
      jtag usercode I = 0000003b
      jtag usercode D = 00000000

    基本的なものが動くようになった。ターゲットは、Lattice LCMXO2280C-B-EVN (MachXO 2280 Breakout Board Evaluation Kit) 。FT2232H + MachXO が載ったボードで、MPSSE ではなく Synchronous BitBangMode を使っている。

    今は、ft245r CABLE ドライバと jtag 操作が一応動いたという段階。LCMXO2280C-B-EVN を使って、config 関係のコードのテストが可能になったし、SPI terminal モードとか ISP でのプログラムのコードを作ってテストもできる。それらが終わったらいよいよ rtavr のテストを開始できる。

    XC3S50A/200A の Artemis ボードの出番がないが、ある程度ツールが動くようになれば、AE-UM232R を使ってテストが出来るようになる。やっぱり最初は、Xilinx の config で、それが出来たら、AE-UM232R 互換ボードで serjtag を使っておなじことができる所まで持っていく。

    まぁこんな手順で進めようかと思っている。

ツールの進捗状況2。

    ツールをテストするため、LCMXO2280C-B-EVN の HDL を作った。

    まずは、内部クロックの確認と LED の ピン割り当てが正しいかのテスト。-- OK。

    次に、JTAG の先に、単にエコーバックする spi_echo と メモリを内部に持った ISP をつけた。

    IPA/IPB が選択されたら それぞれ LED を点灯させる。-- OK。

    エコーバックのテスト :

      spi_test
      30 fe
      31 0c
      32 0c
      33 cc
      34 0c
      35 cd
      36 0d
      37 0f
      38 c7
      39 ce
      ff 0e
      ff ff
      spi_test done

    値は変だが、なにか返って来た。

(続く)
posted by すz at 00:24| Comment(0) | TrackBack(0) | artemis