2012年05月24日

JTAGツールとSYNCBB

前記事で MPSSE についてちょっと調べてみたわけだが ... 自分のツールで対応してみたいというのが理由だった。だが、結局は 機能が増えるわけではなく、性能が改善されるだけだ。それはそれで興味深くはあるのだが ... 後回しでも良いだろう。

MPSSE はちょっと置いておいて ... 他のことを考えてみよう。

一般に JTAG Cable は、けっこう高価だ。自作なんかも 行われているわけで、JTAGkey clone が人気がある。ただ、これにしても 部品も揃えないといけないし、それなりにはコストがかかる。なにより作るのが面倒で、お試しでちょっと使うには敷居が高い。

であれば...

  • AE-UM232R を使って、配線だけで 広範囲な電圧(1.8V-5V)に対応。ただし遅い
     -- VCCIO を ターゲットから貰えば良い。配線だけで済むが、接続の手順というものがあるかも。
  • UM232H を使って、3.3V 固定なものの 配線だけで高速に 使える。
     -- UM232H は、3.3V 専用。またシリアルの設定のままだと基本 MPSSE は使えない

こういう風になれば、少しは敷居が下がるのではないだろうか?

    SYNCBB でも FT2232H で 3.87 Mbps までは出た。MPSSE の 1/5 ぐらいの性能だが、常に最高性能を出せるとは限らないわけで、使い物にはなるはず。FT232R だと 随分(ひとけた)落ちると思うが、お試し用と割り切れば悪くないはず。

でも、なかなかこうならないのは、ツールの対応が進まないからだと思う。それについて考察してみる。

OpenOCD

    まずはこれ。FT232R のドライバは標準ではない。誰かパッチを作っていないか調べてみると ...

    なんとあった。
    FT232R based JTAG with OpenOCD patch

    これである。ただし、

    I do not have FT232R. I just feel this might be interesting.

    なんてことが書いてあって、ちょっと心もとない。コード自体はしっかりしているようなので、まぁこれベースで 改造していけば、使えそうな感じはする。ちなみに、OpenOCD-0.5.0 に対してパッチを当ててみたら 2 ヶ所だけ reject された。手で直すのは簡単ではあった。

    ちょっと見た範囲では、ピンアサインがいまいち

    * Bit 7 (0x80): unused.
    * Bit 6 (0x40): /SYSRST output.
    * Bit 5 (0x20): unused.
    * Bit 4 (0x10): /TRST output.
    * Bit 3 (0x08): TMS output. (CTS)
    * Bit 2 (0x04): TDO input. (RTS)
    * Bit 1 (0x02): TDI output. (RXD)
    * Bit 0 (0x01): TCK output. (TXD)

    Bit2 が RTS だから もともと出力。これに TDO を割り当ててしまうと 出力がぶつかり、配線だけで 使うわけにいかなくなる。ピンアサインについては、後で検討してみよう。

UrJTAG

    OpenOCD ほどではないが、次ぐらい? に有名なツール。これのパッチ があるのかどうか 調べてみたが見つからなかった。

    対応するのにどれぐらい大変なのか? ちょっと見てみた。

    まず、UrJTAG は、FT245 ベースの USB-Blaster と FT2232(MPSSE) ベースの各種 Cable に対応している。ドライバは二段構成で ftd2xx , libftdi に対応した 下位ドライバ2 種類と、上位ドライバの構造をしている。

    で、FT2232 ドライバは 2000行ほどあるのだが、各種 Cable に対応している部分が 半分を占める。Cable を1つだけにすると 1000 行弱で、それをベースに すれば、それほどは難しくないかも知れない。USB-Blaster のコードもあり 500行ぐらいとさらに小さい。でも FT2232 ドライバベースの方が良さそうな気がする。

    ただ、ちょっと問題がある。下位ドライバで FT_SetBitMode して SYNCBB(Synchronous BitBang) モードにしたいわけだが、そのときに Direction の パラメータが必要なのだ。MPSSE だと read/write で Direction を変更できるから良いのだが ... SYNCBB だと なにか API を追加しないといけなさそう。

cblsrv-0.1_ft2232

  • Amontec JTAGkey-Tiny (FT2232) を Xilinx iMPACTから使う

    URL はここ。どれだけ知られているのか分からないのだが、JTAGkey clone を iMPACT から直接使えるようにするもの。ただ、Linux では使えないし、MinGW の環境でビルドできなくなっている。そのままでは、(私が)いじるのには向いていない。

    ところで cblsrv は、ネットワーク経由で iMPACT から司令を受けて JTAG の処理をする サーバ。で、司令がどういうものか ... ちょっと見てみたところ、どうも JTAG の STATE 設定 と TDI へ bit ストリームを送り込む (+ TDO から受け取ったストリームを 返す) 構造のようだ。

    ちょうど JTAG のツールを作っているところだから、上位レイヤーと自作のコードを くっつけた方が (私には)扱いやすそうな感じ。いっそのこと 上位レイヤーのロジックをコピーして re-write しても良いかも知れない。

というわけだ。このなかでは パッチが既にある OpenOCD の改造が 一番敷居が低い。ピンアサインを決めるだけなのかも知れない。( 作った人は FT232R は持っていないものの、ピンアサインは MPSSE に準じているところから見て FT2232X でデバッグ済みのような気がする。)

なら、まずはピンアサイン。avrdude-serjtag で基本のアサインは 2 つある。やはり TXD/RXD は空けておきたいから
 
TMS = D7/RI
TCK = D5/DSR
TDI = D6/DCD
TDO = D3/CTS

これが基本か。 あとは 2 pin だが、

/SYSRST = D4/DTR
/TRST = D2/RTS

これで良いのじゃないか?

あと、JTAGkey clone では、SYSRST は双方向 が基本みたいだが、このピンアサインだと 出力専用 にせざるをえない。(これで良いのだろうか?)

cblsrv の調査

    どんなコマンドがあるか調べてみた。

    MSG_COMMANDS:
    CMD_DONE
    CMD_SET_CABLE_OPTION
    CMD_GET_CABLE_OPTION
    CMD_IS_CONNECTED
    CMD_READ
    CMD_WRITE
    CMD_SET_PIN
    CMD_PULSE_PIN
    CMD_START_OPERATION (open みたいなもの)
    CMD_NAVIGATE_TAP (from to の STATE遷移)
    CMD_WAIT_TIME (sleep)
    CMD_WAIT_TCK (N 個のクロック送出)
    MSG_GET_INFO:
    MSG_SET_CABLE_MODE:

    MSG_CLOSE_CABLE:
    MSG_CHECK_SERVER:
    MSG_0x06:

    これで全部。MSG_XXX で、ひとつのコネクション。違う MSG を送るたびに一旦コネクションを切る。MSG_COMMANDS だけは、他のと違って CMD_XX がひとつのコネクションのなかで連続して発行される。

    まず重要なのが、 CMD_NAVIGATE_TAP -- 簡単なものだとしても JTAG のレイヤーを 持っていないといけない。

    CMD_WRITE は、TDI ストリームを送り込む司令で、CMD_READ は、最後の CMD_WRITE に対する TDO ストリーム を返す。常に read しておかないといけないので、ちょっと嫌らしい。

    MSG_GET_INFO/MSG_SET_CABLE_MODE は対になっていて、ケーブル名 や ケーブルタイプ , port , speed を GET/SET する。

    CMD_SET_CABLE_OPTION/CMD_GET_CABLE_OPTION は、オプション名 に値(文字列) を読み書きするもの。これも 汎用的すぎてちょっと嫌なかんじ。

    cblsrv 自体は、C++ だが、クラスを使ってなくて、C に変更するのは容易。これを書き換えていくというのは、ひとつの手なんだが、書き方が自分の趣味に合わない。MSG_XX や CMD_XX に対して関数が割り当てられていて、case 文 と処理するコードが離れている。関数作る分だけ冗長だし、流れを読みにくい。

    やっぱり、re-write したいような ...

自作のツール

  • rtavr_tools-0.10.tar.gz

    一応 作っているものの最新版。ただし 前記事の MPSSE 対応とか この記事に関係するところをいじっている最中。あと、ちゃんと書いておくと もともと汎用的なものは目指していない。自分が使う範囲で便利なものを目標としている。
posted by すz at 20:06| Comment(0) | TrackBack(0) | artemis

2012年05月23日

MPSSEめも

いままで作ってきた コードは、Synchronous BitBang(以下 SYNCBB) Mode を使っている。FT2232H でも FT232H でも SYNCBB は持っているので、コードはそのまま使えるのだ。

遅いという問題はあるが、実用上さほど問題になることはないと思っている 。FT2232H とか使ったら それなりに高速になる。ただ、UM232H とか安価な モジュールも出てきたし MPSSE を使ってみたいような気もしている。MPSSE は、JTAG ケーブルで良く使われているが、実際どういう機能なのか知りたくも思っていた。まずは、どのように使うものなのか調べていこう。

初期化:

    SYNCBB も MPSSE も FT_SetBitMode() を使ってモード設定する。だから、FT_SetBitMode() するまでの手順は、どちらも共通なのだ。

    FT_SetBitMode() で MPSSE モードにした後は、送受信するデータの意味が SYNCBB とは違う。

  • AN108: Command Processor for MPSSE and MCU Host Bus Emulation Modes

    このドキュメントがその詳細。初期化に必要そうなコマンドをちょっと抜粋しておこう。

  • GPIO の設定と読み出し (初期値の設定)
    MPSSI で使う TCK/TDI/TDO/TMS を含めて ADBUS/ACBUS (BDBUS/BCBUS) の設定と読みだしが出来る。


    Set Data bits LowByte 0x80 Value Direction
    Set Data bits HighByte 0x82 Value Direction
    Read Data bits LowByte 0x81
    Read Data bits HighByte 0x83

    LowByte は、ADBUS の Bit番号に対応し、HighByte は ACBUS の Bit番号に対応する。
    また、ADBUS の bit0 - bit3 は、 デバイスにかかわらず TCK/TDI/TDO/TMS が割り当てられる。Direction は 各bit の値が、1 で出力 0 で入力。

      ここで注意点がある。RS232C のモードだと TXD/RXD/RTS/CTS に割り当てられている。bit2 TDO はデバイスからの出力 だが、RS232C でも RTS でホストからの出力でぶつかるのだ。

      なので、一般的には シリアルに割り当てないように EEPROM の設定が必要になる。

  • クロックレートの設定
    FT_SetBaudRate とは別に クロックレートの設定をしなければならない。

    Clock 30MHz 0x8A
    Clock 6MHz 0x8B (default)
    Set TCK/SK divisor 0x86 ValueL ValueH

    0x8A/0x8B は、FT2232D にはない モードで ベースクロック値を変更する。0x86 の Value はこのクロックに対して分周する値(-1)。bit clock を 1 MHz に設定したければ、5 を設定する。30 MHz にした場合は、29。

    この説明は、正確ではないがだいたいこんなもの。

    GPIOの設定 の周期が、この設定で変わるのかどうかは不明。

  • ループバックの設定
    デバッグの初期にしか必要ないと思えるのだが、TDI と TDO を内部でつなげるモード。

    Loopback Enable 0x84
    Loopback Disable 0x85

    ひょっとしたら 初期化で Disable にしないといけないかも。

  • 2232D にない機能
    2232D にない機能は、無視してよいかと思ったのだが、気になるものがあるので、追記


    Enable 3 Phase Data Clocking 0x8C
    Disable 3 Phase Data Clocking 0x8D

    他にもあるが、とりあえず。

データの入出力

    データの出力方法に様々なパターンがあるのだが、JTAG で使いそうなものだけピックアップ。

    Clock Data Bytes Out on +ve clock edge LSB First (no read)
    0x18 LengthL LengthH byte1 .... ByteN
    Clock Data Bytes In on -ve clock edge LBS FIrst (no write)
    0x2C LengthL LengthH
    Clock Data Bytes In and Out (Out +ve / In -ve)
    0x3C LengthL LengthH byte1 .... ByteN

    Clock Data Bits Out on +ve clock edge LSB First (no read)
    0x1A Length byte1
    Clock Data Bits In on -ve clock edge LBS FIrst (no write)
    0x2E Length
    Clock Data Bits In and Out (Out +ve / In -ve)
    0x3E Length byte1

    -ve clock edge とは TCKの 立下り(↓)だと思えるが、説明はないようだ。8bit 単位でない操作は、bit mode を使う。それぞれの mode は、Out/In を行うかどうかで 3 通りがある。 byte mode に設定できる Lehgth は 1 〜 65535。bit mode は、1 〜 7 。

    基本はこの 6 種類で済むはずだが ... ルールがあるのでそれについて

    bit0 : -ve CLK on write
    bit1 : 0 byte mode / 1 bit mode
    bit2 : -ve CLK on read
    bit3 : 0 MSB First / 1 LSB first
    bit4 : DO write TDI
    bit5 : DO read TDO
    bit6 : DO write TMS
    bit7 : 0

    ピックアップした 6 つは、

    0 x x x 1 1 x 0

    のパターンが基本。ただし no read の場合は、bit2 は 0/1 どちらでも良いのかも知れない。 あと 出力は TMS 入力は TDO というパターンがある。TDI/TMS とも write に設定するとどうなるのか? ... 説明は見つけられていない。

rtavr_tools とのマッピング

    rtavr_tools での CABLE ドライバのインターフェイスは、次のように決めている。

    open
    close
    delay bitclock ベースの遅延
    put_tdi_bits TDI ストリームの出力 , Read あり/なし
    put_tms_tdi_bits TDI+TMS ストリームの出力 , Read あり/なし
    setup_port TCK/TDI/TMS の値を設定。
    setup_gpio INIT/PROG/M1/M2 と名付けた GPIO の状態設定
    get_gpio      INIT/PROG/M1/M2 と名付けた GPIO の状態取得
    set_bitclock bitclock の設定

  • put_tdi_bits

    上に書いてないが、最後のビットだけ TMS を H にするオプションがあり、JTAG では良く使われる。

    コマンドの組立てを考えると...

    MPSSE_PUT_BYTES (MPSSE_PUT_GET_BYTES read あり)
    :
    MPSSE_PUT_BITS (MPSSE_PUT_GET_BITS read あり)
    (TMS_HIGH オプションの場合 の追加)
    MPSSE_SET_LOW
    MPSSE_PUT_BITS (MPSSE_PUT_GET_BITS read あり)
    MPSSE_SET_LOW

    こんな感じになる。ただし、bit 数によっては、MPSSE_PUT_BYTES / MPSSE_PUT_BITS のどちらかがない場合がある。read なしの場合は、単に一気に 送れば良いのであまり問題でないのだが ...

    read ありでは、read データを解析しないといけない。MPSSE_GET_PUT_BYTES / MPSSE_GET_PUT_BITS がどういう組み合わせになっていようが、綺麗なビットマップになる。TMS_HIGH オプションがあると 1 bit 分のデータがそれにくっつく。... これぐらいだったら、BitBang 用として作ったものをベースに改造すればいけそうだ。

  • put_tms_tdi_bits

    これは、JTAG の ステートを変更する 時に使っている。操作するビット数はあまり多くない(最大 10bit)が、jtag の API がステート + TDI ストリーム という構造なので、put_tdi_bits と同じような頻度で使われることになる。

    もともとの仕様は、read あり になっているのだが ... どう実装するのが良いのだろう?

    (bit 数分のくり返し)
    MPSSE_SET_LOW (TMS が 変化する場合のみ)
    MPSSE_PUT_GET_BITS (1bit 分)
    MPSSE_SET_LOW (TMS を最後の状態に戻す)


    read の結果には MPSSE_SET_LOW は関係せず、1 バイト 1bit と決まるから、解析は難しくない。

    これで一応仕様を満たすことにするが ... 実は read ありは使っていない。read が入らなければ、write が連続で出ることになり、レイテンシは無視できる。BitBang だと write した分は、かならず read が入る。たぶんこの理由で、MPSSE の方が速くなりそう。

      ところで、JTAG の ステート変更では、TMS のみを TCK で出力するパターンを使う。そうであれば、TMS を変化させる コマンドを使った方が効率が良い。

      ただ、API まで変えるつもりはないので、TDI が全部 0 のとき TMS を変化させるコードにする .. とか最適化のひとつと考えておく。

  • delay
    クロックを発行しつつ delay する というコード。MPSSE_GET_BITS を必要クロック分発行すれば良さそう。ただし、実装する必要はなくオプション。

    実装されていなければ、put_tdi_bits で代替する。

  • setup_port / setup_gpio / get_gpio

    BitBang 用のコードをベースにすることで、簡単につくれる。

    ちなみに、INIT/PROG/M1/M2 は、Xilinx の信号線をベースに決めている。どのように操作するかは、

    (cbl->setup_gpio)(cbl, CABLE_GPIO_PROG, -1);
    (cbl->setup_gpio)(cbl, CABLE_GPIO_M2, 1);
    (cbl->setup_gpio)(cbl, CABLE_GPIO_M1, 0);
    (cbl->setup_gpio)(cbl, CABLE_GPIO_PROG, 0);
    (cbl->setup_gpio)(cbl, CABLE_GPIO_PROG, -1);
    (cbl->setup_port)(cbl, 1, 0, 0); // TMS = 1, TDI = 0, TCK = 0;

    こんな風に固定にしている。-1 は HI-Z (入力) 、あと config ファイルでの割り当てがなければなにもしない。それに加えて論理を逆にする config の設定がある。

(おまけ)I2C の考察

    I2C のコードはますます作る気はないが、メモ。

    MPSSE_SET_LOW/MPSSE_SET_HIGH は、アトミックに 方向を切り替えられる。だから L または HI-Z (入力) という操作は簡単にできる。読み込みの MPSSE_GET_LOW/MPSSE_GET_HIGH も期待通り同期してくれるだろうから、似非 I2C マスターのコードは簡単そうだ。

    似非 と書いたのは、ちゃんと作ると SCL を H にしたい場合は H になったことを確認しないといけないから。読み込みの結果によってループするようなコードにすると、USB は極端に遅くなる。だから、応答性能 の保証がないデバイス相手だと、ちょっと面倒なことになりそう。

    対策としては、遅くなるのを覚悟で、H になったことを確認する (1)。このパターンだと すごく遅くなるだけでなく、AVR USI を使うときに AVR も止まるという弊害がある。

    もうひとつは、delay をちゃんと計算する(2) 。AVR USI 相手 だと、割り込みが起きる フレームの最初のところだけ遅くして、あとは 普通にするとか。たぶん このやりかたが適切だろう。
posted by すz at 21:45| Comment(0) | TrackBack(0) | artemis

2011年07月02日

FPGAライタの設計(3)

もはや FPGAライタというのは適切ではないのだが、前タイトルを継承して続ける。

いままでの経緯

    ARTEMIS ボードを設計し、その上で動かすなにか.. を考えて AVR互換コアを設計してきた。AVR互換コアは出来上がったのだが、ARTEMIS ボードの JTAG インターフェイスは特殊で それを扱うツールもまた作らなくてはならない。

    それは想定内だったのだが、『MachXO 2280 Breakout ボード』 を最初のターゲットに変更したので、サポートする内容が随分増えた。

      MachXO 2280 Breakout ボード』は、安価なだけでなく、安易に使える。rtavr のリファレンス・ボードとして使えると思ったのが変更した理由。

      ボードもツールも信用できない状況でデバッグするのは、苦痛なので 確実に動作するボードが欲しかったのだ。

      ここで、Xilinx を選ばないというのには理由がある。MachXO2 に興味が出てきたので、将来サポートしたいと思っていた。幅広いデバイスに対応できるようにツールを設計する必要が出てきたので、最初から タイプの違う 2 種類のデバイスをサポートして 後々困らないようにするのが、狙い。

    さて、最低限必要な機能は以下のもの

    • (AE-UM232R の) BitBang で Spartan-3/6 に Config できる。
    • BitBang を使った JTAG通信で(Spartan-3/6 に接続された )SPI_FLASH に書き込める。
    • BitBang を使った JTAG通信で rtavr のデバッグができる。(ISP と シリアルのような通信)

    Config できることは、ARTEMIS ボードのみ必須。JTAG通信で 設計した回路と通信できることが重要で、それはターゲットが変わっても変わらない。

    あと、いろいろなファイルをいろいろな方法で 送り込む必要がある。(Config と SPI_FLASH と ISP) この操作方法は統一感があるようにしたい。

現状

  • rtavr_tools-0.2.tar.gz

    これが今できているものの一式

  • 設定ファイルの読み込み
  • ft245r/ft232r の BitBang Cable ドライバ (FT2232H 対応)
  • SVF ファイルで使うような JTAG 操作のプリミティブ
  • MachXO 2280 の IDCODE の確認と JTAG通信への移行
  • テスト用 HDL (同梱) との JTAG通信

    これが今確認できたことのすべて。

    動作確認できていないが、ツールを作るたみに必要なパーツのかなりの部分は作成済み。

今後の作業

    ここからが本題。

    これから、作ったパーツをくみ上げていく予定なのだが、どのようにくみ上げるかが悩ましい。この記事で整理しておこうと思う。

    ずっと悩んでいたが、avrdude と良く似た インターフェイスにするのが良さそうという結論。avrdude をコマンドラインで使うことが多いので、似て非なるオプションにすると混乱しそうだ。

    必須のコマンドライン・パラメータ。


    -c CABLE名
    -P CABLE の PORT 名
    -B bit clock
    -b baud
    -i テイテンシ パラメータ

    -p TARGET FPGA名


    自分の Bitbang ライタのコードをベースにしているし、CABLE のパラメータはこんな感じで良いだろう。あと FPGA名 も指定しないと。

    このあたりは、最初にパラメータとして指定しないと、認識ができない。

    CABLE名 や FPGA名 は、設定ファイルに記述する。どのように記述するかはきっちりとは決まっていない。また、なんでもかんでも設定できるわけではない。コードを作る都合で、外にだすだけ。例えば、FPGA の IDCODE は、設定ファイルに記述するが、サポートできる Family はハードコーディング。Lattice の場合、知っている IDCODE しかサポートできないし、Xilinx でも 知っているもの以外は受け入れないようにする。

    さて、必須以外のパラメータは動作を指定するもの。... なのだが当面決めないでおこうと思う。

    どうするか..というと コマンドモードを作り そのモードに入って操作する。

    最終的には、動作を指定するパラメータは コマンドモードでのコマンドに変換しようと考えている。

    最初に作るのは、spi terminal モード。

      コマンドラインモードから さらに terminal モードに入る。テスト用のHDL を使うと 入力した文字がエコーバックされる。

      ここから抜けるのは、~. か +++ をすばやく入力。... というのが今のコード。操作できないかも知れないので、動かして詰めていく。



付録: JTAG の API


    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 つにまとめたほうが最適化になる。要するに非同期してわずかに高速化してもあまり意味はない。

rtavr_tools-0.3.tar.gz

    少し前進。コマンドモードを作り、コマンドのテストに入っている。

    cmd mode usage:
    (fl|file_load) [filetype] file
    filetype: bit jed mcs mem
    (tl|target_load) memtype [size]
    memtype: fpga_ram fpga_flash spi_flash rtavr_isp
    ram flash spi isp
    (d|dump) [addr size flags] [! outfile]
    flags: 1 reverse bit (in byte)
    (w|program) memtype
    (v|verify) memtype
    (t|terminal) [bitclock]
    (q|quit)

    こんなコマンド体系になった。

    fl file名 で 内部メモリバッファに読み込み、
    v flash で XO の flash と同じかチェックする。

    jed ファイルを使って flash の内容と一致することを確認できた。

    v ram は、RAM の内容をチェックするのだが、一致しないどころか、毎回違う。
    これは ... 今動いている回路の状態を読み取っているのだろうか?

    dump コマンドも動く。! を付けるとファイルに log することもできる。

    RAM を見たいときは、tl ram として、内部メモリバッファに読み込んでから dump 。

    terminal は全然だめだし、rtavr_isp もダメ。.. まぁボチボチ 完成させていこう。

    書き忘れたのだが、jtag_SDR の start bit 位置が 8bit アラインという制限になっている。これだととても具合が悪いことが分かったので、

    void jtag_SDR_EX(CABLE cbl, uint8_t *buf, int off, int bit_len, int flags, uint8
    _t *rcv_buf, int roff);

    というのを新設した。off/roff は 開始位置で bit 単位。これを実装するために CABLE のインターフェイスも変更。

    あと、xp2 用のコードも マージしつつ変更しているんだが、0.3 では最後にバグをいれてしまい、書いた通りには動かなくなっている。

rtavr_tools-0.4.tar.gz

    また少し前進。erase コマンドを作成して動作を確認。

    そして MachXO に対して flash に書き込めるようになった。ただし、ちょっとバグがあって USERCODE の 最下位バイトが書けない。

    cmd> e flash
    erase success
    cmd> w flash
    Programming :################################################## 29.278 sec
    Verifying :################################################## 12.660 sec
    program success
    user_id = 0x52543031
    user_id unmached 0x52543031 0x52543000
    cmd> v flash
    Reading :################################################## 12.644 sec
    verify error at 60822 0x31 != 0x00
    address_size 1116 data_width = 436
    cmd> v flash
    Reading :################################################## 12.761 sec
    verify error at 60822 0x31 != 0x00
    address_size 1116 data_width = 436
    cmd> e flash
    erase success
    cmd> w ram
    Programming :################################################## 23.747 sec
    Verifying : 0.034 sec
    program error
    user_id = 0x52543031
    cmd>

    実行したときのログ -- ram への書き込みは verify でエラー。

    flash への書き込みはされていない。エラーになったとき ISC_PROGRAM_DONE をしないようにしているが、その場合 書き込んだ内容が有効にならないことも確認できている。

    あと、ちょっと遅い。たぶん jtag_IDLE に時間がかかっているのだろう。そういえば、時間も合っていない。gettimeofday() 使うようにしないと。

    ちなみに、xp2 は持っていない。コードは書いておくが、テストは先の話。MachXO2 Pico Dev kit は入手済みでテストは出来るが、肝心のコードが出来ていない。(ちょっと難しいのだ)

    追記: DDT #1 FPGA超入門は、まだ入手可能なようだ。Amazon, マルツで買える。一応 押さえておくことにした。

関連記事
posted by すz at 15:25| Comment(0) | TrackBack(0) | artemis

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

2011年05月13日

ARTEMISボード(まとめ)



ARTEMISボードの情報は分散しがちになりそうなので、ここにまとめていこうと思う。

  • 紹介

      Xilinx の FPGA Spartan-3A (XC3S50A/XC3S200A VQG100) ボード。標準的なJTAGのコネクタはなく、秋月のUM232R か 自作 MEGA32U2 ボード(UM162) をマウントして 一体にして使う設計。

      サイズは、37.5mm x 47mm 。



        RFADテクノロジー MK6040 にマウントできるよう短辺のサイズを決めている。(参考記事)。長辺は、Fusion PCB の 50mm - 自分で切る場合の余白。秋月 C 基板の短辺でもある。

      SDRAM / コンフィグ用 SPI_FLASH / 水晶発振モジュール(5mm x 7mm タイプ) を搭載可能。

      UM232R/UM162 との通信用にピンをさいていて、外部装置との I/O ピンは少ない。

        ピンの割り当て数
        外部接続用(1) 8
        外部接続用(2) 8 (8bit 幅 SDRAM のとき使用可能)

        SDRAM 39
        SPI_FLASH 4
        UM232R/UM162 13/15
         4 (JTAG)
         4 (USART/SPI)
         1 (CLOCK 用)
         6 (FPGA 制御用 PROG_B/INIT_B/M1/M2
         + CCLK/DIN(UM162のみ) )

        LED 2 (VS0/VS2)
        タクトSW (FPGA リセット専用 PROG_B)


      その他

        電源は、1.2V にスイッチング電源ICを使用可。3.3V は レギュレータだが、電源強化用基板でスイッチング電源化も可能。

        外部接続用(1) に接続できるオプションボード(USB/MICRO SD/PLL)も作成。

      (使用目的)

      最初は、設計した基板を作ること自体が目的だったが、AVR互換コアを作りだして 回路設計が楽しくなり、AVR互換コアを実際に動かすことが主目的になっている。

      50A では、かなり厳しい。実用的なものを作るというよりパーツの開発用。


  • eagle ファイル

    • artemis-01-fusion.zip (Fusion PCB 提出用)
    • artemis-01.zip 全部入り

      以前作ったボードの焼き直しだが、ファイル名を変更したりしている。Fusion PCB が $9.90 になったので、ARTEMISボード を単独で 注文してみた。-- もともとは 動作確認できたあと 1.6mm でつくり直そうと思っていたのだが、これだけ安ければいいか。

      記録:
      2011/05/12 動作未確認のまま、見切り発注。
        - Registered Air Parcel : +$3.52, Total: $13.42(1117円)
      5/19 発送のステータスになった。(メールが来る)
      5/24 日本郵便の検索に表示されるようになった。(5/20 引き受け)
        5月25日国際交換支店から発送 (HONG KONG)
        5月26日国際交換支店に到着 (NARITA)
        5月27日通関手続中

  • テンプレート

  • AVR互換コア

      AVR8L という 縮小版の AVR コアの上位互換 (縮小LDD/STD 命令を追加)。avr-gcc は専用のものが必要。

    • rtavr-wk11b.tar.gz (頻繁に更新中)

    • (リンク) AVR互換コア(テスト3) 専用 AVR_Toolchain のリンクなどの情報。

      (ステータス)
      コア自体は完成度が上がってきた。いまは、実機テストの準備中。

      構成を変えられるようにしていて、機能を縮小することにより 50A にも Implement 可能。

        50A には、ISP と機能縮小版 USART / TIMER0 / SPI / PORTC が入る。

        INT0/PORTC のみの構成なら、500 スライスを切るので、他の回路も一応入れられる。


  • ライタなどのツール
    (ステータス)

    • bit/mcs ファイルを読み込むコードを作成
    • ISP のプロトコル決定

    自前でツールを作り、bit/mcs ファイル の 直接コンフィグ/ SPI_FLASH への書き込み。及び ISP での ROM ファイル書き込み を できるようにしようとしている。

    まだまだ、構想中。

posted by すz at 00:43| Comment(0) | TrackBack(0) | artemis

2011年05月05日

FPGAライタの設計

AVR互換コアも一段落。つぎは、これを JTAG で書きこむものをでっち上げる。JTAG インターフェイス は独自使用の serjtag 。FT-232R も考慮する。

まずは、大昔の記事『USB910のJTAG拡張案』をひっぱりだして、どのように serjtag を設計したのか思い出す。

    serjtag は Digilent の USB JTAG Cable のプロトコルを シリアルで使えるように変更したもの。概念としては互換になっている。

    そのプロトコルは、どういうものだったかというと...

    • コマンド NULL

      受信パケット要求のコマンド。このコマンドを発行したときだけ、受信パケットが送られてくる。

    • コマンド ENABLE

      初期化と終了コマンド

    • コマンド SET

      TDI/TMS//TCK の値設定。

    • コマンド PUT_TDI_BITS

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

      オプションには、受信データを記録する RECIEVE と TMS の状態をセットする TMS_HIGH がある。

      受信データを受け取るには、RECIEVE を使い記録して、コマンド NULL で要求する。

    • コマンド PUT_TMS_TDI_BITS

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

      オプションには、受信データを記録する RECIEVE がある。

    • コマンド GET_TDO_BITS

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

      コマンド NULL で要求してはじめて、受信できる。

    6 種類しかないが、JTAG の操作には十分。

    この 6 種類をメソッド化して、CABLE ドライバを定義する。上位レイヤでは、ビットストリームのデータを元に、この 6 種類を使って操作するように設計すれば良い。

さて、ビットストリームをどのように扱えば良いのだろう? 観点は 2 つある。ひとつは、JTAG の操作。もうひとつは、ファイルの形式。

    まずは、
  • xulaload
    をみてみよう。

    xula.py をみてみると、JTAG を操作しているように見える。

    TMS_TDI_CMD = 0x42 # Send a single TMS and TDI bit.
    TMS_TDI_TDO_CMD = 0x43 # Send a single TMS and TDI bit and receive TDO b
    it.
    TDI_TDO_CMD = 0x44 # Send multiple TDI bits and receive multiple TDO
    bits.
    TDO_CMD = 0x45 # Receive multiple TDO bits.
    TDI_CMD = 0x46 # Send multiple TDI bits.

    Xula のコントローラには、こんなコマンドがあるらしい。上記 6 種のコマンドで 組み立てることは可能なように思える。Python をそのまま使うのであれば、移植は難しくなさそう。

    だが、基本ツールでは、Python だけでなく perl も使いたくない。そして使うだけでなく、ちゃんと理解したい。

      基本ツールで使うスクリプトは、sh , awk, sed ぐらいにすることにしている。ライブラリを使うなら基本 C 。対応するのが serjtag のみなら スクリプトで書けそうだが、FT-232R が想定に入っているから C にすることになる。

  • XAPP139 : [PDF] バウンダリスキャン (JTAG) 使用による Virtex FPGA のコンフィギュレーション (日本語版)
  • XAPP452 : [PDF] XAPP452 Spartan-3 FPGA Family Advanced Configuration

    xula.py に XAPP139 と XAPP452 の文字が見える。これを読めば理解できるだけの情報が得られるのだろう。

XAPP139 を見てみる。

    このドキュメントに コンフィグの基本が書いてあるようだ。

    まずは、シーケンス。

       :
      CFG_IN をロード
      ビットストリームをロード
      JSTART をロード

    どうも、このあたりが肝心な部分らしい。

    self.LoadBSIRthenBSDR(self.CFG_IN, bs)
    self.tlr()
    self.LoadBSIRthenBSDR(self.JSTART, None)
    return

    xulaload xula.py は 1:1 に対応するようなコードになっている。tlr() というのは、"Go to TEST-LOGIC-RESET" だそうだ。ビットロードのデータは、bs で

    BitFile(bitfilename)

    で生成している。
    一方、実際に bs を送るのは、sendbs() で

    Send bitstream over TDI, raising TMS for last bit

    コメントにはこう書いてある。last bit には気を付けないといけないが、基本は、ビットストリームを送るだけらしい。あと、指定するファイルは xxx.bit で PROM ファイルではないようだ。

XAPP452 を見てみる。

    XAPP139 には、ビットストリーム・ファイルの説明は載っていない。それが載っているのは XAPP452 。だが、xulaload bitstream.py は、中身はほとんど見ていない。

    シンプルなのだが、何をやっているか分からないので、xilprg を見てみた。

      xilprg では、1 バイト read してみて、'a','b','c','d' なら読み飛ばす。'e' ならデータフィールドなので、読み込む。という処理をしていた。

      フィールドの読み込みは、最初に length が BIGENDIAN で入っている。
      サイズは、'a','b','c','d' なら 2 バイト。'e' なら 4 バイト。
        xilprg では、次のコメントが付いている。参考まで。

        case 'a': // NCD File Name
        case 'b': // Part Name
        case 'c': // Creation Date
        case 'd': // Creation Time

      また ファイルの先頭から 13 バイト 無条件に読み飛ばしていた。

    これぐらい知っていれば .bit ファイルは扱える。だが、xilprg は PROM ファイルの .mcs ファイルも扱えるようだ。.mcs ファイルは、ihex フォーマットらしい。.mcs ファイルを扱うようにすれば、同じファイルを SPI FLASH に書いたり、直接 CONFIG したり出来て便利なような気がする。

bit ファイルを読み込むテスト

    簡単なプログラムで確認してみた。

    今は自力で作れないので、『MZ-700をつくる』の mz700fpga_X200_051120.lzh から mcs ファイルと bit ファイルを借用した。

    で見てみると

    # 'a' len = 10
    # 'b' len = 11
    # 'c' len = 11
    # 'd' len = 9
    # 'e' len = 130952

    という風に格納されていた。


    0000: 87 ff ff ff aa 99 55 66 30 00 80 01 00 00 00 07
    0010: 30 01 60 01 00 00 00 34 30 01 20 01 40 00 3f e5
    0020: 30 01 c0 01 01 41 40 93 30 00 c0 01 00 00 00 00
    0030: 30 00 80 01 00 00 00 09 30 00 20 01 00 00 00 00
    0040: 30 00 80 01 00 00 00 01 30 00 40 00 50 00 7f 88
    0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    *
    00b0: 00 00 00 00 00 01 98 00 00 00 00 00 00 1c c0 00
    00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    *

    先頭をダンプするとこうなっていた。

    参考までにプログラム: bit_test.c

mcs ファイルを読み込むテスト

    次は、mcs ファイル。

    ihex のフォーマットは、『HEXファイルフォーマット』を参照。忘れたらいつもここを見ている。

    Xilinx にも説明がある。『PROMGen - PROM/EEPROM ファイル フォーマットの説明』を見ると、02/04 でアドレスを拡張しているようだ。

    base_addr 00000000
    base_addr 00010000
    ln 8188 size 130952

    みてみると、04 を使っていてサイズは同じ 130952 バイト。あと、アドレス 0 から連続してデータが入っている。(隙間はない)

    0000: ff ff ff ff 55 99 aa 66 0c 00 01 80 00 00 00 e0
    0010: 0c 80 06 80 00 00 00 2c 0c 80 04 80 02 00 fc a7
    0020: 0c 80 03 80 80 82 02 c9 0c 00 03 80 00 00 00 00
    0030: 0c 00 01 80 00 00 00 90 0c 00 04 80 00 00 00 00
    0040: 0c 00 01 80 00 00 00 80 0c 00 02 00 0a 00 fe 11
    0050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    *
    00b0: 00 00 00 00 00 80 19 00 00 00 00 00 00 38 03 00
    00c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    *

    だがダンプしてみると .. 似ているようで何かちがう。

    参考までにプログラム: mcs_test.c

これで、ファイルフォーマットは分かったし、読めるようになった。JTAG の操作は、XAPP139 と xulaload,xilprg を読めばいけそうだ。準備はできた。

... と思ったのだが、bit と mcs の違いについて 検索していると 『なひたふJTAG日記』 になにやら情報が。

  • SPIのフラッシュROM書き込みツール

    ひとつはこれ。JTAG で通信して SPI FLASH に書くことができるそうだ。ユーザロジックで JTAG と通信できることを知らなかった。

    ... というか普通にバウンダリスキャン? IOB のレジスタと通信すれば良いだけ?

    ug332 (日本語版 p263) に書いてあった。BSCAN プリミティブ(BSCAN_SPARTAN3A 等)を使えば プライベートスキャンチェーンをインプリメントできるそうだ。

    Spartan-3A 用の『ライブラリガイド(pdf)』を見ると TCK/TDI/TDO1/TDO2/TMS のインターフェイスがある。これに SPI をスレーブとしてつなげれば良いわけか。

    メモ: 2つチャネルを作れるから ISP の機能も組み込むと良いかも知れない。プログラムのデバッグで FPGA の Implement はしたくないし。

    ISP は、TPI が手本の独自仕様にしようと思う。だいたい JTAG でアクセスする手順が煩雑で互換性など取れない。AVR互換コア(rtavr)の中には作らないかも知れない。RESET 時にはバスを開放するような仕様にして、外に付ける。

    BSCAN プリミティブは、rtavr に入れたくないし、SPI も PORT 経由で(外部から)接続しないといけないのが理由。

      知っていたら、artemis ボードのデザインも随分変わったかも知れないし、rtavr も USART 付けなかったかも。現時点では、今のデザインで良いと思っているから、知らなくて良かったと言うべきか。

    この方式の利点は、(1) デバイスに対して 1つビットストリームを用意すれば良いのと、(2) JTAG ケーブルだけで良いこと。

    (1) は、定義しなければならないピンが存在しないから。使う方も作る方も面倒がなくて良い。

    (2) は、SPI - SPI コンバータで作れそうだから、これが主目的だとプロセッサが不要になってしまう。だが、通信手段のひとつと考えれば、便利そうに思える。

    ただ、クロックはどうするのだろう? 外部に影響を与えないで、クロックが作れたりするのだろうか?

    ... 違うようだ。JTAG から作り出していると書いてある。rtavr は 2X クロックが必要なうえ、SPI スレーブは 1/2 CLK でしか動かない。4倍のクロックが必要だから無理。

    遅延の設定を使ってクロックが生成できるのなら嬉しい。だいたい コンフィグでそれをやっているのだから、出来ないはずはないと思うのだが...


      ちょっと検討してみた。

      『FPGAの部屋:Spartan3Eの入力用プログラマブル遅延素子』を見ると 3E で既に プログラマブルな遅延機能が入っているそうだ。

      記述は、UCF ファイルに

      NET "ROT_A" IFD_DELAY_VALUE = 0;

      こんな記述を追加するらしい。

      では、~CLK を出力して インバータを作るだけで 20 ns 前後 の クロックが生成できそうだ。

      これで CLK2X を作れば... 外部クロックなしで動かせる。ただ、ピンを使うので、ボード依存がないものを作るという目的には合わない。ピンを使うなら 普通に外部クロックを使えば良いし。

      そう言えば、秋月で 48 MHz とかの セラミック発振子を買ったのだった。これを FPGA に直接接続するには、どうしたら良いのだろう?

      追記:
    • MAX7256による水晶発振の実験
    • MAX7256によるCR発振の実験
      という記事を見つけた。... FPGA 側は、インバータひとつで良いらしい。外付けは、並列の R1 (100K) と 直列の R2 (1K)。 (R1 でよく見るのは、1M Ωだったりするがどうなんだろう?)

      秋月で格安だった、SG-645PCP (33MHz) は売り切れてしまった。自分自身はいくつか確保しているが、ひとには薦められない。

      ちょっと 33 MHz は DCM で 使いにくいし、32MHz / 48MHz あたりを基本としようかと思う。

  • SPI ROMプログラマの最初のリリース

      このツールを使ってbitファイルをSPIメモリに直接書き込めば、FPGAが起動します。
      MCSに変換しなくてもよいので、i●PACTを使って書き込むよりも、はるかに手軽です。

    欲しかった情報は、bitファイル を SPI メモリ用に変換できるという事実。

    そもそも bit ファイルというのは、どういう構造をしているのだろう?

      UG332 : 『Spartan-3 ジェネレーション コンフィグレーション ガイド』を読むと、無印の XC3S200 は、

      1 フレーム 1696 bit (212B) x 615 フレーム (計 130380 バイト)

      ついでにメモすると

      XC3S50A : 1 フレーム 1184 bit (148B) x 367 フレーム (計 54316 バイト)
      XC3S200A : 1 フレーム 2208 bit (276B) x 540 フレーム (計 149040 バイト)

      これがメインのデータフレームで、それに 同期ワード、アレイID、 CRC が付く。

      同期ワードは、先頭で、

      3無印/3E 0xAA995566 (32 bits)
      3A 0xAA99 (16 bits)

      アレイID はそれに続き

      XC3S200 : 0xX1414093 (32 bits)
      XC3S50A : 0xX2210093 (32 bits)
      XC3S200A : 0xX2218093 (32 bits)
      (X は Rev. )

      その後データフレームが来て、最後に CRC 。

    それは分かったが、130952 - 130380 = 572 バイトもある。ほかにも情報があるのだろうか?

    それはともかく bit ファイルでは、AA995566 がそのまま見えている。0024: から 01414093 も入っている。だが、mcs ファイルでは、5599AA66 。アレイID は わからない。

    ちょっと B5 からの 0198 と 8019 , 1CC0 と 3803 に着目してみよう。

    00000001 10011000 00011100 11000000
    10000000 00011001 00111000 00000011

    bit の数は同じだが、なにかずれている。よく見れば... バイトの中で bit 順が逆転しているだけのようだ。-- そうなると AA995566 は、

    10101010 10011001 01010101 01100110
    01010101 10011001 10101010 01100110

    -- 5599AA66 になる。

    なんだ、簡単な話ではないか。... SPI FLASH の bit 送出順( MSB First / LSB First ) が逆なだけ?

    確認してみた。

    < 0000: 87 ff ff ff aa 99 55 66 30 00 80 01 00 00 00 07
    ---
    > 0000: ff ff ff ff aa 99 55 66 30 00 80 01 00 00 00 07


    • mcs_test.c
    • bit_test.c

      プログラムは、正常時、全部をダンプするように変更。dump ルーチンに リバースしての表示オプションを追加。

    で、全部の diff を取ると 違うのは先頭だけ。同期ワード前のデータは無視されるはずで違っても関係ない.. と思う。

いろいろ課題はあるが、JTAG の操作に主題を移そう。

    まず、xulaload の xula.py を見てみる。


    # see ug332, Table 9-5 p 207:
    # Spartan-3 Boundary Scan Instructions

    # see ug332, page 340
    def status(self):
    # packet format see ug332, page 323
    read_status = [
    "aa99",
    "2000",
    self.ccl('r', 8, 1),
    "2000",
    "2000",
    ]

    なんてコメントが見える。ug332 は重要なようだ。

    ... ちょっと面倒なので続きは後で。

実装の方針

    まずは、やりたいことを整理しよう。

    • JTAG インターフェイスは、serjtag or FT-232RL 。

    • 対応デバイスは、XC3S50A/200A で後で(= いつか) XC6SLX9 に対応。対応ボードは自前の artemis のみだが、ボード依存性は減らす。あまり汎用化に凝りたくない。

    • .bit/.mcs ファイルを FPGA に直接 コンフィグ
    • .bit/.mcs ファイルを SPI に書く(1)。 インターフェイスは BSCAN を SPI FLASH に接続。
    • .bit/.mcs ファイルを SPI に書く(2)。 インターフェイスは BSCAN(ch1) を rtavr に接続。
    • プログラム(HEX ファイル)を置き換える(1)。インターフェイスは BSCAN(ch2) を ISP に接続。
    • printf デバッグ ができるようにする(1)。インターフェイスは BSCAN(ch1) を rtavr に接続。
    • printf デバッグ ができるようにする(2)。インターフェイスは USART を rtavr に接続。
    • プログラム(HEX ファイル)を置き換える(2)。インターフェイスは BSCAN(ch1) を rtavr に接続しての自己書き換え。
    • プログラム(HEX ファイル)を置き換える(3)。インターフェイスは USARTを rtavr に接続しての自己書き換え。

    デバッグの目的もあるから、冗長なのだがこれぐらいか。

追記: Lattice MachXO2

    Lattice MachXO2 はまだまだ使うつもりはないのだが、いずれ使うかも知れないので、予備調査。

    まず、知りたいのは、Spartan-3A のように JTAG に内部で接続できるかどうか?

    ググるとこの記事が見つかった。XP2 では、JTAGE を使うが XO では JTAGD だそうだ。XO2 は当然ながら書いてない。JTAGF か XO 互換の JTAGD あたり?

      確認できた。JTAGF で、JCAPTURE がない。(lscc/diamond/1.1/cae_library/synthesis/verilog/machxo2.v 参照)


    それはともかく、Spartan-3A のように 2 系統あるようだ。同じように扱えば良さそうで、安心した。

    ちなみに、Lattice の場合、JTAGプライベート命令の IPA(0x32)とIPB(0x38)で切り替えるそうだ。一方 Xilinx は、USER1 と USER2 らしい。

    内蔵FLASH の書き換えは、TN1204 に説明がある。いくつかの方法があるが、JTAG 経由だと、バウンダリスキャンを使って pin を駆動して書き換えることになるのかも。

    書き換え用ファームウェアを config することによる 内蔵FLASH書き換え方法も可能なようだ。これなら Xilinx とほぼ同じ方法が使える。MachXO2 の場合、内蔵オシレータがあるので、クロックについては、Xilinx より自由度が高い。

    ライタについては、Pico では、FT2232D が基板に付いている。FT232R 同様の Bitbang による 操作も可能なはずなので、コードを大幅変更をしなくとも サポートできるはず。

    とりあえず Pico をリファレンスと考えて MachXO2 がサポートできるよう 設計していこう。

プログラム構造の設計

    まず、下位レイヤ 。上記の JTAG インターフェイス をベースした API にする。ただ、送れるビット数に制限があると 面倒なので、上位レイヤが指定したビット数を送るように下位でなんとかする。
    ーそうなると、受信要求の NULL コマンドは上位では扱えない。受信要求を パラメータとして、必要なら 下位で発行するということになるだろう。

    たぶん概念としては、こんな感じ。

    • open()/close()

       初期化と終了

    • set(int tdi, int tms, int tck)

       TDI/TMS//TCK の値設定。

    • put_tdi_bits(uint8_t *buf, int bit_len, int mode , uint8_t *recv_buf)

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

       mode には、受信データを記録する RECIEVE と
       最後の TMS の状態をセットする TMS_HIGH がある。

    • put_tms_tdi_bits(uint8_t *buf, int bit_len, int mode , uint8_t *recv_buf)

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

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

    • get_tdo_bit(int tdi, int tms)

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


    これらをメソッド風に定義して、CABLE ドライバとして、serjtag と ft232r ドライバを作る。あと、JTAG の 面倒を見てくれる サブルーチン群を用意する。

    その上に、Xilinx とかの TARGET の config 方法を知っている TARGET ドライバを構築。

    • config
    • チャネル1 を利用可能にする
    • チャネル2 を利用可能にする

    あたりを TARGET ドライバが メソッドとして提供する。

    config するには、ファイルのロード必要だが、それは別途用意。チャネル1/2 でどういう通信をするかは、いろいろある。ISP を使った書き込みとか、SPI スレーブを使った SPI_FLASH 書き込みとか、SPI_FLASH を直接接続したときの SPI_FLASH 書き込みとかは、メソッド化できるかも知れない。が、だいぶ上位なのでそこまでせずに、関数にしてしまった方が楽そう。

    あと、実をいうと rtavr の エミュレータを接続したい。ISP 機能と SPI スレーブ機能を実装したやつ。SPI を使った printf デバッグみたいなのができるようになると後々楽そう。

    CABLE ドライバに、GPIO の制御 を入れたいのだった。ft232r の場合はピンの割り当ても。
    設計の方針として、『FPGA ボードに触れずに使える』というのをいれていた。

      VS0/VS2 を設定した後、PROG_B に出力して、FPGA を初期化する機能を付ける。INIT_B にも接続しているから、config 失敗も分かる。これらはちゃんとサポートしたい。

      ft232r は Bitbang だから、仕様さえ決まれば対応できる。だが、ピンアサインは、自由にできるようにしておかないと。MachXO2 だとどういう制御をするのかについてもチェックして仕様を決める必要がある。

      一方 serjtag はプロトコルがないから、そこからやらないといけない。自由にピンアサインを決めれるわけでもないので、ピンの config はいらないと思うが、GPIO での制御をする/しないぐらいは、決められないと 汎用のJTAG として使えない。

posted by すz at 12:26| Comment(0) | TrackBack(0) | artemis

2011年04月20日

XuLA-200(Spartan-3Aボード)




XuLA-200 という FPGA ボードがあるのを知った。

TQ100 の Spartan-3A の XC3S200A に SDRAM と SPI-FLASH を付けたボードで、USB コントローラも 付いている。ツール類もオープンソースで公開している。

    価格は、$69 。XuLA-50 というのもあって こちらは $39 。XC3S50A と XC3S200A の価格差は そんなにないから、戦略的な価格づけ? いままで AVR互換コアを作ってきた経験から言うと 50A ではできることは多くない。お試し版という感じか。

    今買うなら、『Avnet Spartan-6 LX9 MicroBoard』$89 ( 国内版 だと 11000円 ) が良いのかも知れないが。 このコンパクトさはすばらしい。

    2011/09/01 追記: Avnet Spartan-6 LX9 MicroBoard 秋月でも扱いだした。7980円也。

USB コントローラは、PIC で違うが、その他は設計してきた FPGA ボードと構成が近い。



まだ組み立てていないし、結線がどれぐらい違うのかチェックしてみようと思う。ひょっとしたら自分のボードの問題点が見つかるかもしれない。UCF ファイルとかも、どういう風に定義しているのか?気になる。

あと、ツール類。どんなものを提供しているのか? ひょっとしたら楽できるかも知れない。

とにかく要チェックだ。

ちょっとツールをチェック。

  • XSTOOLs

    SouceForge のプロジェクト git で管理されているが、ここ から snapshot をダウンロードできる。

    最新は、2011/1/27 Ver. 5.13 。これは一体どういうものなのか?

  • xulaload

    XuLA 専用。JTAG bitstream (.bit ファイル?) を書きこむもので python スクリプト。

    ... ふうむ。細いことを言わずに config だけするのもアリか。

    今の計画では、SPI-FLASH への 書き込みをするために AVR互換コアで作った ファームウェアを FPGA に config する必要がある。FPGA のテストでは、SPI-FLASH に書くのは 単に 二度手間になるだけで無意味。
    でも手軽で高速ならそれでも良いかも知れない。

    この最初の config はどうしよう。PC 側で serjtag の streame にして jtag として操作するのが最初だとは思うが 遅いようなら config ファイルを 送り込んで Mega32u の方で 変換することも考えた方が良いかも知れない。

    以前 USB で マスストレージクラスを作ったが、500KB/sec ぐらいだった。受信データをそのまま SPI で送り込むのが大半なので これぐらいの速度が出た。シリアルだと 200KB/sec 程度だったような。serjtag も たぶん同じぐらいのはず。

    一方 XC3S50A は 400Kbit(50KB) XC3S200A は 1.2Mbit(150KB) 。... 速度はあまり気にする必要はなさそう。

    serjtag は 通常のオペレーションなら 62B(or 60B ? 忘れた) 単位のブロックをUSBシリアルで連続で送る。そういう操作をするプログラムは簡単なものになるはず。xulaload を参考に C か perl で作ってみよう。

    で、次に SPI-FLASH に書くツール。操作のほとんどは、FPGA 側でやるつもり。インターフェイスはシリアルだから AVR のライタのような仕様にしても良いし。... (ブロックモード付き)AVR910 もどきとか。

    あとは、xilprg/cblsrv か。-- ずっと放置していたが、この機会に検討しよう。

    XSTOOLs は中身を見て、良さそうなら対応を考える。あとは OpenOCD か。Jtag デバッグするなら対応しないといけないが ... なにしろデカイし後回し。

ちょっとツールをチェック2

  • XSTOOLs

    ダウンロードして README を見てみた。

    XESS 社 (www.xess.com) のボードの専用ツールで、 ボードの diagnostic test, RAM or flash との upload/download をするものだそうだ。そこに自分のボードを割りこませても意味はない。

  • xulaload

    内容は次のようになっている。

    73 bitstream.py
    180 jtag.py
    22 loader.py
    366 xula.py
    641 total

    思ったよりは大きいが、コンポーネントに分かれていて汎用性は高そう。だが、私は python 使いではない。やはり参考にするだけにする。

    bitstreme のフォーマットをどう扱って jtag をどう操作するか分れば後は自分で作れる。

    C で書いても 大差なさそうだが、perl でプロトタイプを作るかも。

  • xc3sprog

    SouceForge のプロジェクトで xc3sprog というのを見つけた。ダウンロードファイルは 4MB もある。一体何が含まれているのだろう?

    ただこういうツールは微妙。たぶん jtag 使ってのデバッグはできないだろうし、SPI-Flash への書き込みは別に作らないといけない。やはり自前で作って SPI-FLASH と config を統一的に扱えた方が良い。

    ただ、どういうものかはチェックしておこう。

      4MB はバイナリだった Linux (32bit/64bit) と Windows 用が同梱されている。

      ソースコードは こちら。snapshot をダウンロードしてみたが、cable は FT2232 とパラレルに対応。-- ちょっと面白くない。Digilent に対応していると serjtag への移植が簡単だったりするのだが。

      対応デバイスは、device.list に載っている。気になるものをピックアップすると。

        04002093 6 0x9 XC6SLX16
        04008093 6 0x9 XC6SLX45
        02210093 6 0x9 XC3S50A
        02218093 6 0x9 XC3S200A

        06e1c093 8 0x1 XC2C32A_VQ44
        06c5e093 8 0x1 XC2C64-VQ44

        0970203f 4 0x1 ATmega128

      SPI ベースならドライバを定義すれば、なんでもいけるのか -- 悪くはない。

      AVR互換コアでの SPI-FLASH ライタの設計も再考の余地がある。シリアルよりも SPI スレーブの方が 汎用のツールに対する親和性があるようだ。 例えば -- なにか Xilinx のデバイスのふりをさせると 汎用ツールの cable を違う設定にするだけでいける。


    ところで、自分のボードに名前を付けたい。現状 xc3s50a-sdram ボードという名前になっていて、カッコ悪い。ググるとヒットするからこれでも良いかという気もするが ..

    追記: 名前は、artemis-50A にしようかと思う。『Teensy(1.0)互換ボード』 に angel162 と名づけてしまったし。

    それ用の ファームウェアを angel_loader (最新版: angel_loader-1.4c.zip) としていて、これが自作ツールのベースになる。

    angeel - artemis のつながりは、とある物語の『あだな』。ART が入っているし、気に入ったかも。
    (三つ目の名前を考えないといけなくなったら swan3 )

追記: PIC18F14K50

    XuLa-200 では、PIC18F14K50 を使っている。秋月でなんと 150円 。ATmega32u2 だと デジキーで 333円 25個でようやく単価 209円(2011/5/21 現在) 。

    AVR しか使うつもりはないが、ちょっと羨ましい。

      AVR しか使わないのは、開発環境の構築を含めた自由度の問題が大きい。それに、いろいろ作ってきて資産がある。いまさら PIC で似て非なることをするつもりは全くない。
posted by すz at 01:30| Comment(0) | TrackBack(0) | artemis

2011年02月05日

FPGAボードを使う計画

FPGAボードを設計してみた』わけだが、それ自体を作りたいのが動機だったりする。だが、どのように使うつもりなのか全く計画がないというわけではない。

ここでは、どう使うつもりなのか - なにがしたいのか - について整理していこうと思う。

まずは、どんなものかについて簡単に説明すると

  • FPGA は、安価な 100 ピンの Spartan-3A (200A or 50A)
  • SPI FLASH での Config 可能。
  • SDRAM が付く。(最大 512Mb(64MB) で 16bit幅 / 8bit 幅 )
  • ATMEGA32U2 と 接続してありホストとの連携を強化(JTAG, Config 以外に 通信に 4bit + α)
  • 一方外付け回路用の I/O は貧弱。8bit が標準。(SDRAM を 8bit 幅にすると + 8bit)

  • ボードの名前は決めていない。eagle でのファイル名は xc3s50a-sdram だが長いので、仮に 200Aボード/50A ボードとする。

次にしたいこと (or やるべきこと)をリストして 後で詳細を書いていく。

  • ステップ(1) 200Aボード/50A ボードを使えるようにする。
  • ステップ(2) AVR互換コアを作る (DONE)
  • ステップ(3) AVR互換コアで SPI_FLASH に書き込めるようにする。
  • ステップ(4) AVR互換コアで SDRAM を使えるようにする。
  • ステップ(5a) SDRAM のアプリケーションとして、簡単な フレームバッファ/ロジアナ を 作ってみる。
  • ステップ(5b) FULL-SPEED(12Mbps) USB IP を使ってみる。
  • ステップ(5c) MicroSD を使ってみる。
  • ステップ(6) SDRAM をメインメモリとした CPUコアを動かしてみる。
  • ステップ(7) 200Aボード/50A ボード同士通信できるようにする。
  • ステップ(8) I/O ボードを Spartan-6 で作り、200Aボード/50A ボードから利用できるようにする。

だいたいこんな感じ。

200Aボード/50A ボードを使えるようにする


このボードには、JTAG 用のコネクタはない。その代わりに USB インターフェイスが載った ATMEGA32U2 を接続しているわけである。

だから、JTAG ケーブルにするファームウェアと それを使うホスト側のプログラムを作らないと なにもできない。

Digilent の USB JTAG ケーブル互換のファームウェアを作るのが、ひとつの方法ではある。そうすれば既存のソフトに手を入れず利用できる。それぐらいは困難だと思えないぐらいのレベルに今やなっている。ただ、USB の ID を詐称することになるので、こんなのを作ったとしても 自分で使うことしかできず 公開できない。

自作の JTAG ケーブル用のプロトコルとファームウェアはベースを用意してある(serjtag)。いくつかの オープンソース の ツールを これ(serjtag)に対応するよう改造していこうと思う。

serjtag は、Digilent の プロトコルを参考にしていて、プロトコルそのものは違うが機能的にだいたい互換にしている。移植にはそんなに苦労しないと見ているが、やってみると問題は出てきそうだ。

ステップ(2) AVR互換コアを作る


オープンハードウェアで、AVR互換コアはいくつかあったと思う。これらを利用すれば作る必要はなさそうだが、そもそも作ってみたいのだ。

実を言うと経験がないので、どれぐらい難しいのかよく分かっていない。あまりに困難だったり、飽きたり、面倒になってしまったら、既存のAVR互換コアを改造する方法に切り替えようと思う。
作りたいのは、Tiny10系の コア。レジスタが少なかったりして、リソースを減らせる利点がありながら GCC が利用できる。

    いったい gcc が使える 8bit CPU のコアはどれぐらいあるのだろう? AVR は昔からあるが それ以外だと R8C ? 16bit になると h8300 coldfire PIC24 M16C ? こんな感じ?

      追記: MSP430 が該当するらしい。 FPGA で利用できるコアとして OpenCoresopenMSP430がある。

      また、LatticeMico8 も gcc が利用できるらしい。Mico8 は 自社プリミティブを使いまくっているように思えるが、シミュレータ用の定義も添付されているようで 一応完結している。

      もう AVRコアを作ってしまったので、他の8bitコアに興味はないが 外部インターフェイスやデバイスをどうしているとか 参考にはさせてもらおうと思っている。

    そもそも AVR を使う理由は gcc があるからだし、この中から 慣れ親しんでいる AVR を選ぶのは必然ではある。そして、作ってみるとすれば、普通の AVR を縮小した Tiny10 系を選ぶのも必然だろう。 

    技術的興味から言えば 4 段パイプラインというのは大きい。いったいどういう風にして動かすものなのか 設計できるレベルで理解したいと思う。


(もう上記と違うことを書いて恐縮なのだが..) 作りたいとはいえ、経験がないわけだから、全くの自己流だと無駄が多い。だいたい書き方の流儀すらろくに知らない。ソースがあるもので 練習してみたい。

いくつか OpenCores から リストアップしてみた。

AVR core は昔からあるもの。Navre AVR clone は、SoftUSB と組み合わせて使うことを想定しているらしく興味深い。が、完全に互換ではないようだ。AVR8 は Reduced AVR Core for CPLD となっていて Tiny10 よりさらに単純化したもののようだ。AVR_HP は、Hyper Pipelined AVR Core。-- よく分からないが、4つまでの core が付く -- 興味深いが 今の目的に対して複雑すぎ。

いろいろあるわけだが、Verilogが 多い。VHDL を勉強しようと思っているので他にないかググっていたら、

が (やはり Verilog だが) 見つかった。(このサイト前にも見た記憶がある。そのときは感心して終わりだった)

規模は、KX_AVR が、452スライス+1MULT 。AVR Core が 955スライスだそうだ。50A が 704スライス、200A が 1792 スライスなので入ることは入る。Tiny10 互換だと機能を削るわけだから、もっと小さくはなるだろう。ちなみに Spartan-3 用 PicoBlaze は 96スライスだそうだ。

これらの数字から考えて 出来れば 300 スライス以下になると 嬉しいのかも。一応の目標にしよう。

速度は、KX_AVR が 26.854 ns と書いてある。周波数にすると 37.23 MHz 。4段パイプラインと書いてあるから MIPS 値も 37.23 MIPS だろう。ちなみに PicoBlaze は 88MHz / 44 MIPS だそうだ。

Tiny10 向けに機能を削ると 速くはなっても遅くはならないだろう。だが、入手した 50A/200A (-4 グレード)で、33MHz というのはかなり厳しいのかも知れない。

なにやら KX_AVR は出来が良さそうな感じなので、これで勉強させてもらおうかと思う。

    VHDL ではないが、しょうがないから 混在も OK で検討しよう。

まずは、単純に 論理合成してみた。デバイスは xc3s200a-4ft256 。CPU core だけでメモリが入っていないので、ピンの数が多い。

    Number of occupied Slices 477 1,792 26%
    Number used for Dual Port RAMs 64
    Number of bonded IOBs 104
    Number of BUFGMUXs 1
    Number of MULT18X18SIOs 1

で、MEGA と ELPM の define を外してみた。ひとつエラーが出たが適当に修正。

    Number of occupied Slices 450 1,792 26%
    Number used for Dual Port RAMs 64
    Number of bonded IOBs 104
    Number of BUFGMUXs 1

これぐらいでは、大して変わらないということか。ちなみに、レイテンシはどこ見れば良いか分かっていないので載せられない。

行数は、1868 行。-- 中括弧だけの行みたいなのが、ほとんどないから C だと 3000 行ぐらいの感じか。一から作るなら別だが、削っていくだけなら長大という感じはしない。ちょっといじってみたくなる量。

だが、いまはこれぐらいにしておこう。

メモ: PicoBlaze をぐぐっていたら KX_AVR のひとの KP4 というページもヒットした。プリミティブ一覧が、\Xilinx\doc\japanese\books\docs\lib\lib.pdf にあるそうだ。重要な気がするので、メモ

追記: 2011/04/19

ほぼ完了。実際には残っている作業はあるが、完成と言って良いレベルになった。詳しくは、『AVR互換コア(テスト2)』の記事を参照。

ステップ(1) のボードの製作を 飛ばして (2) をやったわけだが、設計が楽しくなってしまったからしょうがない。まだしばらく (2) の仕上げをやるつもりだが、次はいよいよボード製作か。ただ、(3)も gcc をいじるところからやらないといけなくて大仕事。(3) の目処を先につけるかも。

ところで、XuLA-200 というボードを知った。これは、XC3S200A-VQ100 に SDRAM が付いたボード。価格は $69 。USB も付いていて、ここで検討したボードにかなり近い。USB のコントローラが PIC であることが違う。(こちらは、FT232RL or AVR(mega32u) )。

いろんなツールも提供していて これからどういう風にすべきかの指標になりそうだ。

ステップ(3) AVR互換コアで SPI_FLASH に書き込めるようにする。


AVR互換コアが実際に使えるものなのかどうか判断するには、有用なものを作ってみるのが良いだろう。

(ATMEGA32U2 の )シリアルで接続して、SPI_FLASH に書きこむものを目標としてみよう。こういうものを作るなら、PORT 以外に デバイスも作り込みたいところ。

Tiny20/40 には SPI が付いているので、互換になるようにしてみたい。あと、USART が載った Tiny10系デバイスはないので、Tiny2313 あたりの USART 互換を目標にする。

ちょっと Tiny40 の I/O レジスタのアドレスマッピングを見てみたが、USART は ADC のところに入りそうだ。PORT は A,B,C の 24bit 分の割り当てができる。タイマーは、8bit の timer0 と 16bit の timer1で標準的。TWI もいずれ使いたいから入れたい。

PORTは、いままでの AVR と違い プルアップ用のレジスタが増えている。どちらが良いか判断できないので、define で切り分けて 従来タイプと 新タイプを分けた方が良いかもしれない。

以上で I/O レジスタの 32 バイト分はだいたい埋まってしまう。

Tiny10 系では、LPM/SPM 命令がなくなったが、フラッシュは 16bit メモリ空間にマップされている。I/O もそれに倣えば (アクセス効率は悪くなるものの) いくらでも増やせる。

ちなみに Tiny40 には、RAMAR/RAMDR という I/O レジスタがあって これ経由で RAM にアクセスできる。これは何だろう? ひょっとしたら core 内部 でも使っているのかも知れない。

ステップ(4) AVR互換コアで SDRAM を使えるようにする。


ここで作りたいのは、SDRAM の メモリコントローラ。これも IP を利用したいのではなく、作ってみたい。

メインの CPU があって キャッシュへの READ/WRITE をしている状況で、DMA が あって 横から I/O できるようなものを目指す。

AVR互換コアはテスト用として使う。

ステップ(5a) 簡単な フレームバッファ/ロジアナ を 作ってみる。


フレームバッファ/ロジアナ が欲しいわけではない。メモリコントローラが使えるようなものになっているかどうかのテスト用。 うまく作れるようなら発展させるのも良いが ... とりあえずはメインにはしない。

DMA の方につないで動かすが、AVR で SDRAM に書き込んだり、データを抜き出したりする。SDRAM を排他的に使うのも良いが、後々再利用できないので、ちゃんと並列にアクセスできるよう作る。

ステップ(5b) FULL-SPEED(12Mbps) USB IP を使ってみる。


これはやってみたいのだが、入れるならこのあたり? すくなくとも DMA が使えないとテストもできないだろう。

ただ、付けるクロックを 33MHz にしようと思っている。x2 しても 66MHz 。USB の 12M Hz の整数倍にはならない。クロックを付け替えたくないし ... V-USB のように違うクロックでドライブできないか考えてみたい。

    クロックのことを考えると Spartan-6 が圧倒的に有利だ。TQG144のLX9 なら 1286円で実際に買えるし。

ステップ(5c) MicroSD を使ってみる


あまり考えていないが、これもやってみたい。ただ、3.3V の I/O 電圧のみで良いのかどうか? 4bit の SD規格で アクセスできるのか? 出来たとしてやって良いものなのかどうか? いろいろ懸案材料がある。

ステップ(6) SDRAM をメインメモリとした CPUコアを動かしてみる。


MIPS あたりの CPUコアを動かしてみたい。いまのところ、CPUコアを作りたいとまでは思っていない。どんなものなのか、既存のものをメモリコントローラにつないで見る。

この時点で CPUコア を設計するのが楽しくなっていれば、自分で作るかも知れない。

ステップ(7) 200Aボード/50A ボード同士通信できるようにする。


通信はもっと早い段階でやりたいのだが、まともに使うには、AVR互換コアでは力不足だろう。

ステップ(8) I/O ボードを Spartan-6 で作る。


ここでようやく、次のボードを作る。この段階まで到達できるかどうか分からないが、現時点の構想をメモしておこう。

200A/50Aボードの HUB になる I/Oボードで、Spartan-6 TQG144 が候補。4 枚までぐらいの 200A/50Aボードをつなげたい。I/O の種類は 大きくわけて 2 種類。

ひとつは、200A/50Aボードのローカルストレージ用。もうひとつは、外部との 接続用。

200A/50Aボードには、メモリ と CPUが載っている(とする) 。通信も できている。-- 足りないのはストレージ。SPI_FLASH は READ/WRITE できるが、WRITE は性能が低いうえに書き込み回数の上限がある。CPU の ファームウェアを置く領域には利用できるが、データ置き場にはできない。

I/O 用のピンは 通信に使ってしまっている。しょうがないので、通信先に ローカルストレージを付ける。

外部との接続 というのは、ネットワークとか DISK とか グラフィックLCD とかキーボードとか ... PC に付いているような種類のもの。

TQG144 といっても よくよく考えないと、ピンが足りなくなる。I/O の電圧も マルチになりそうで、ほんとうに良く考えないと無理そうだ。だからといって、それ以上のピン数のものは利用できない。ピン 拡張用の デバイスを付けることも視野に入れる。

いったいどれぐらい必要なのか 数だけ見積もってみよう。

  • 200A/50A との通信ポート

    単純に 4 ポートにすると 8x4 ピン必要になる。通信ポートの使い方はだいたい決めたので、それに従うと

    I2C (共通 2 ピン)
    高速 I/O (それぞれ 4ピン 差動 x 2)
    クロック 1 ピン
    未定 1 ピン (入力専用)

    こうなるので、最大は、24 + 2 = 26 ピン。最小は 入力専用ピンを使わないことにして、クロックも (200A/50A ボードから見て)入力専用にすると、16+3 = 19 ピン。クロックは個別にした方が良いかも知れないが、バッファを外付けする手もあるし保留。

    (追記) LPC(Low Pin Count) というインターフェイスがあった。リンク先(Wikipedia) の リンク -- Intel のサイトに 仕様がある。必須なのは 7 ピンで、

    LAD 4 ピン データとアドレス 4bit I/O
    LFRAME# 1 ピン 新しいサイクルが開始されたことを示す (ホスト → 装置)
    LRESET# 1 ピン リセット
    LCLK 1 ピン 33MHz

    で、SUPER-IO と呼ばれる IC が(今も)存在しているのだった。どちらがホストか決まっている必要があるが、これも使えるかも知れない。

  • ローカルストレージ用

    MicroSD で良いと思っている。ただ、MicroSD のもつ 性能を利用したいのなら、6 ピン必要なだけではなく、I/O 電圧 を変えられないといけないらしい。

    悩ましそうな気がするが、とりあえず 6 ピンでカウントして 6x4 = 24 ピン。

    ある SDXC コントローラのデータシートを見てみると

    • DS (Default Speed) 25MHz まで 3.3V I/O 電圧
    • HS (Hi-Speed) 50MHz まで 3.3V I/O 電圧 (ここまで従来規格)
    • SDR12 SDR 25MHz まで 1.8V I/O 電圧
    • SDR25 SDR 50MHz まで 1.8V I/O 電圧
    • SDR50 SDR 100MHz まで 1.8V I/O 電圧
    • DDR50 DDR 50MHz まで 1.8V I/O 電圧

    .. とまぁいっぱい増えている。

    いくら FPGA でも I/O 電圧を個別に しかも動的には切り替えられないから、TXS02612 を使うとか考えた方が良いかも知れない。ただ、それで物理的に接続できても、SD規格は使えないような..

  • グラフィック LCD

    16(or 18) パラレルだったりして、普通に接続すると ピン数を消費する。ただ、帯域は (FPGA の能力から比べると)それほどでもない(はず)。

    仮に最大を 800x480x24bpp としてみよう。これを 70Hz で書き換えるなら 77MB/sec 。-- あ、これは厳しい。8bit シリアルRGB とかでないと無理そうだ。

    もっと 小さいもの 480x320ぐらいならどうだろう?

    とにかく、液晶は どういうものであれ WRITE Only で扱えるのが普通。CPLD とかで シリアルパラレル変換させて ピン数を節約する方向で検討しよう。CPLD は XC2C32A で十分だし。

  • HI-SPEED USB / FULL-SPEED USB

    USB さえ付いていれば、大体のデバイスはなんとかなる。そして 他のPC向け高速 I/O は 帯域が高すぎて無理。480M bps の HI-SPEED USB がせいぜいという気がしてきた。

    HI-SPEED USB をつなぐには、ULPI という標準インターフェイスの PHY を使う。 USB33XX といったデバイスをつなぐことになりそう。

    USB33XX は 8bit I/O で、リファレンスクロックに 13MHz(or 26MHz) が必要で、あと 電源も必要。結構ピンが必要になる。

    2ch 欲しいところだが、付くのだろうか?

    一方 FULL-SPEED USB なら、直接ハンドリングできそうだ。PHY というか ドライバ・レシーバ? を付けても良いかも知れない。良くは知らないが USB1T11, MIC2550 , MIC2551 -- このあたり?

  • SDRAM

    (無印)SDRAM は 39pin 使う。ただ、これには DDR ぐらいは載せたくなるから、専用の I/O バンクを割り当て 2.5V 電源も用意しないといけない。ちなみに TQG144 には Spartan-6 のメモリコントーラは付いていない。

    ちなみに 1.8V I/O 電圧の DDR2 が 具合が良さそうだが、BGA ばかりで電子工作レベルでは無理。PC 用のメモリモジュールは安く手に入るが、相当なオーバースペックで電力もくう。

    まぁ I/O だけでも厳しいのに 無理としか思えないが、一応メモ。

... とまぁ全然見積もれていないが、先の話なのでこれぐらいにしておこう。
posted by すz at 17:04| Comment(0) | TrackBack(0) | artemis

2011年01月22日

FPGAボードを設計してみる

FPGA ボードを作ってみたい。といっても、いま特に FPGA で 作りたいものがあるわけではない。作りたいのは基板で、やりたいのは まずはハンダ付け。

  • プリント基板が Fusion PCB で安く作れるようになってプリント基板作りが楽しくなった。設計したものが形になって出来てくる -- これはとても嬉しいことなのだ。

  • 0.5mm ピッチのハンダ付けはいままで避けてきたのだが、0.8mm ピッチのハンダづけが普通に出来るようになったので、0.5 mm に 挑戦したくなっている。

    FPGA は Startan 3A シリーズの 50A と 200A (VQG100) にしようと思う。

    • 3A は、1.2V core + 3.3V だけで(も)良いので 電源が楽。
    • SPI FLASH で コンフィグするのに (3E と比べて) 便利になっているようだ 。(プルアップ抵抗がいらない?)
    • 50A は 501 円と安いし、200A と配線を共有できるので、これで(製作も含めて)練習して 本当に規模が足りなくなったら 200A に移行する腹づもり。

      (メモ: Spartan 3E/3A VQG100 比較 )

      ロジックセル  スライス 乗算器 最大USER-IO(うち入力)
      (換算) CLB ブロックRAM DCM 価格
      50A 1584 176 704 6K x 9bit 3 2 68 (6) 501 円
      200A 4032 448 1792 32K x 9bit 16 4 68 (6) 1014 円

      100E 2160 240 960 8K x 9bit 4 2 66 (7) 861 円
      250E 5508 612 2448 24K x 9bit 12 4 66 (7) 1181 円

      ブロックRAM の個数 = 乗算器の個数 , 1 個 2K x 9 bit


    FPGA ボードを作るなら SDRAM を付けたい。

    • SDRAM の使い方は以前調べた →『SDRAMの使い方(メモ)』。
    • チップも入手済み。256Mbit (16bit幅) は安く 10 個買った。古い ノートPC用の SO-SIMM 512M byte (512Mbit 8bit 幅 x8) もひとつ入手済み。 そして 128Mbit は、256Mbit と交換したものが余っている。

      だが、もっとも重要なのは、SDRAM を付けることで複雑な配線になるということ。単体の FPGA ボードだとコネクタに線を引き出すのが基本だから単調な配線になる。それでは達成感が得られない。 要するに、基板の設計を楽しみたいということだ。

      もちろん、作った基板には意味を持たせなくてはならない。本当に有用かどうかはともかく、有用だと思えるものでなくてはならない。

    • とりあえずは、CPU を作るようなことを考えようと思う。200A は ブロックRAM が 32KB もあるし、SRAM を外付けしなくとも あまり困らない。SDRAM を使うとすればフレームバッファとか OS で使うメインメモリということになりそうだ。

    • CPU を作るだけなら I/O 線 はあまり必要ではないだろう。ホストとのインターフェイスが充実していれば十分のような気がしている。

    • あと思いつくのは、ロジアナのようにキャプチャするもの。I/O 線 はいらないと書いたが、少しは考慮しておこう。

    ホストとのインターフェイスはどうしよう。

    まずは JTAG 。それとは別に ホストと通信する手段。+できたら リセットなどの操作。

    • 最近設計した AE-UM232Rピン互換ボード(UM162)を使ってみることにする。

    • 一応、AE-UM232R でもちゃんと使えることを目指す。

      こう考えると通信は 基本 シリアル。だが、BitBang による SPI という手もある。あと操作系は CBUS BitBang 。

    • CB0/CB1 は Tx LED/Rx LED がデフォルトなので 避けるとして、CB2/CB3/CB4 が使える。

    • CBx は MProg で設定することで クロック出力もできる。(最大 48MHz !) これを使わない手はない。以前から CB4 をクロック出力と決めているので、これを割り当てる。

    • UM162 も CB4 相当は PWM を割り当てている。ただ PWM なので 16MHz で動かしても最大 8MHz 。データシートを見ると DLL が使える最低周波数は、5 MHz になっている。そうなる 3.3V かつ 16 MHz で無理やり動かしたくなる。ちなみに 3.3V で 動作が保証されている周波数は 8MHz ではない。13 MHz ぐらい -- 要するに 16 MHz はあまり無理なクロックアップではない。


    その他の検討項目。

  • スタンドアローンで動かすこともあるかも知れないので、オシレータは付けられるようにしておきたい。7mm サイズの SG-645PCP を採用しよう。

      他の周波数だと マルツで扱っている KC7050Bが使える。ただし 472円とか結構高価。デジキーで安いのは、ASV シリーズ。これでも 167円とかする。

      追記:Spartan-3A スタータキット:〜DCMでクロック生成〜 を見ると、DCM を使うと 逓倍が可能なようだ。-- 2倍だけなのかと思っていた。秋月のは 33.000 MHz だからきっちり とは行かないが 3 倍して分周すれば .. 50MHz (ぐらい) とかも作れそう。

  • コンフィグには、SPI FLASH を使うことにする。特に 50A なら 少量で良く格安で買った 512Kbit のものでさえ使うことも出来る。ちなみに SPI FLASH は、コンフィグだけでなく、アプリケーションでも利用可能。
    -- CPU を作ったら 使ってみるのも 面白いかも知れない。

  • 電源は、3.3V と 1.2V の二電源。UM162/AE-UM232R は、3.3V の供給能力が 低いので、3.3V のレギュレータを外付けする。1.2V は、MCP1700SC189 の二種類を 選べるようにしようかと思う。50A は消費電流も少ないようなので、10 個で 336円と安い MCP1700で済まそうと思う。(SC189 も 74円で高くはないが、インダクタも考慮する必要がある )

  • 他には ボタンとか LED とか。

    簡単な動作確認手段はあった方が良さそう。UM162/AE-UM232R が付いているから ピンの状態を読むことで代替はできる。必要とまでは思わない。可能なら付けるというスタンス。

  • 拡張用 I/O

    実を言うとあまり使うつもりはない。CPU が動かせたらそれで満足してしまうような気がする。だが、有用であることを目指すなら必要だ。応用できる可能性は残しておく。

さて、Spartan 3A VQG100 はどれぐらいの I/O が使えて、そのうち SDRAM などで どれぐらい消費するのだろう? 見積もってみることにする。

  • まず、100 ピンのうち GND が 13 本。VCCINT など電源ピンも 13本。あと JTAG と DONE/PROG_B は専用ピンで 計 6本。これを計算すると データシートにある 最大 USER-IO の 68 になる。

  • だが、SPI FLASH での コンフィグには、4pin 必要。さらに Config 時に 使用する M2-M0 と VS2-VS0 , INIT_B がある。これらを共用しないとすれば、使えるピンは 57 pin まで減る。

  • さらに 入力専用ピン(IP_XX) が 6 本ある。うち 4本は VREF にも使える。専用ピンぽいので 避けて使うとすれば、残り 51pin 。

  • 一方 SDRAM は、16bit幅 512Mbit (最大サイズ)を使えるように全部 つなげる。DATA 16 本。アドレス + バンク で 15本。コントロールで 8 本の 計 39 本。

  • これ以外に最低限付けようと思うのが、通信用の Tx/Rx と クロック 2系統 (UM162/AE-UM232R とオシレータ) 。

    残りは ... なんと たったの 8 本。贅沢に使うとこうなるわけだが、あまり大幅には増やせない。でも、8本もあれば、いろいろ出来るから悲観しなくとも 良いはずだ。

基板はどういう風にしよう

ここからが本題。上記は状況設定のようなもの。

  • Fusion PCB で作るのを前提にするので 50mm x 50mm 以内。これは絶対守る。

      今回は 100mm x 100mm にパックしてみようと思う。いろいろ作って切り出すつもりで 0.8mm で作る。ただ、この基板に関しては 1.6mm が本来の形だと思う。0.8mm は試作目的。

      あと、0.8mm にしたと言っても はさみで切れる程 余白は作れないかも知れない。

      今回は、緑以外にしたい。まずは、赤にするつもり。

  • 長辺は 可能なら 47mm にする。(1/2 C 基板サイズ)

  • 短辺は可能なら 35mm (1/2 C基板サイズ) 。無理でも 37.5 mm (RFAD ケース サイズ) を目指す。

    こう決めてちょっと配置を考えてみたのだが ... 600 mil 24 pin が かなり邪魔。収まりが悪いのだ。どう配置しよう。

    • 24pin ソケットの 中に SDRAM を置く。

      まずこれを考えた。一応、収まることは収まる。ただし、ブリッジしやすい上に 『ソケットを一旦付けたら直せない。』という問題がある。

    • 24pin ソケットを裏に付ける。

      一応ソケットが裏なので、ピンが邪魔なものの、やりなおしはできる。 ... 。ピンをギリギリまでにカットすれば、すこしはマシになるかも知れない。

    • 24pin ソケットを裏にずらして付ける。

      最終的にこれにした。ソケットを最初に付ける。そのときに、ピンをぎりぎりにまで切り詰め、上に載る SDRAM がちゃんと付くようにしておく。なお、上に SDRAM が載らない側の辺は切らない。

      ソケットを裏に付けるということは、普通は部品面を下にして使うことになる。LED とか操作に必要なものは裏面。FPGA , SDRAM 以外でも必要なものは表面というルールにすることにする。

    上記を基本方針として、設計を進めていった。が、いくつか問題が出た。

    • 24 pin ソケットが邪魔。

      配線の上でもやっぱり邪魔になった。最低でも ピン間 2 本を通せないと VIA だらけになる。まずは ソケットの drill を 1.1mm から 0.9mm に変更。

      それでも うまくいかない。いつも 使っている dru をやめて Fusion の dru ベースにした。ただ、可能なら drill は 0.4mm まで 最低線幅は 8 mil にするつもり。

    • auto ルータの配線が汚い。

      これは仕方がない。FPGA は ピンアサインを自由に決められるので、最適なピンアサインを探りつつ手配線をベースにすることにした。手配線にすると波打った平行線みたいな配線ができる。-- 出来るというより、そうするためにピンアサインを変えていくわけだ。


レイアウト完成
最終的にサイズは 47mm x 37.5mm にした。あと LED は FPGA の分と UM162/AE-UM232R の分が 付けられた。スイッチは、PROG_B 用を付けることにした。

  • PROG_B は、FPGA のコンフィグをロードし直す -- リセットのようなものらしい。必要かも知れないので付けることにした。

  • LED は、VS0 と VS2 に割り当て L で点灯。

    SPI FLASH でコンフィグするのに VS2-VS0 で設定することになっている。想定した設定は 111 (FAST READ コマンドを使う) と 101 (READ コマンドを使う)の 2 種類。"1" なら L で点灯する LED を付けられる。



    十分堪能した。いろいろギリギリで、もうこれ以上手を加えたくない。

      配線は、ほとんど手配線。しかも ちゃんと計画しないと 収まってくれない。とにかく、600 mil 24pin ソケットが邪魔で ピン間 2 本が精いっぱい。あと、配線でみっちりになるので、裏面が空いていても VIA が 自由には空けられない。



      回路図はこんな感じ。回路図書くのも一苦労。この回路図は 書きなおしたもの。1 回目は 、機能別に して ライブラリの シンボルを作ったので 途中で わけがわからなくなった。なにか織物のような 感じまでする 回路図になってしまったので、PIN の順番を基本にして シンボルを作り直している 。

  • 8bit 幅の SDRAM を使った場合の未使用ピン用コネクタは諦め。線は引き出せないし、コネクタの場所もない。無理。

  • USER I/O は結局 8bit 分 だけ。1 本は入力専用。GCLK はひとつ。コネクタ形状は、1.27 mm ピッチで フラットケーブル直付けを想定。一応 VIA のドリル は 0.6mm でピンを立てることも配慮した。

  • 裏面左上 M2-M0 と VS2-VS1 には 抵抗を付ける。設定は決めてしまっているが、一応 変更可能なように配慮した。

  • UM162/AE-UM232R との接続は、JTAG 用に 4 本。通信用に 4 本( TxD/RxD/DTR/RTS で SPI も配慮) 。CB4 は GCLK に接続し、さらに PROG_B と INIT_B を CB2/CB3 に接続。

    CB0/CB1 は LED 。使えるものは全部割り当てた。

  • パスコンは裏面に 8 つ -- 表に付けるのは無理。うち 2 個が SDRAM 。1.2V core 用に 2 つで、3.3V 用が 4 つ。
    これらは 1608 の 1uF を想定。-- 普通は 0.1uF だが 1608 は持っていないので 1uF にするつもり。

  • 電源は、VBUS から取るか VIN から外部電源を入力するかを選択。D1 はダイオードの表記だが、ジャンパしても良いし、リセッタブルヒューズにできるかも知れない。

    本当にダイオードを使うのは、1.2V にレギュレータ MCP1700 を使ったとき。供給電圧を下げて 負担を減らすのが目的。

      UM162/AE-UM232R の VIO は、3.3V に設定する。5V はまずい。ちなみに 電源関係は、VBUS から 電源を取っているだけ。VCC や VIO は接続しない。

手は加えたくないが、もう少し 検討が必要そうだ。

  • 余りピンの VIA 。

    これぐらいはしておいた方が良さそう。付けておかないと 必要になったときどうにもならない。

  • スレーブシリアルモードの コンフィグ

    ホストから使うのなら、こっちの方が断然便利ではないか。-- 無理してでも付けたほうが良いか。

    あと バグはあるかも知れない。特に ライブラリから作っているので、意外な間違いがあるかも知れない。

    追記: 検討してみた。



    M2-M0 の設定について: 設定は いろいろあるが 次のものだけ考えることにした。

    • 001 マスタ SPI モード

    • 101 JTAG モード

      JTAG モードは、勝手にコンフィグをしないモード。こう設定しないと JTAG でコンフィグできないわけではない。

    • 111 スレーブシリアルモード

      AVR など コントローラで コンフィグするモード。CCLK と DIN で 書きこむ。ただし、PROG_B を一旦 L にして初期化しないと いけないし、INIT_B でエラーが起きているかチェックすべき。ピンに余裕があれば DONE も チェックすべきだろう。2 本のみで OK というわけではない。

      JTAG が付いていれば、別にスレーブシリアルモードはいらない。ただ、SPI FLASH を付けないで MicroSD のファイルをロードするような システムを作るときは有用で、可能にしておくべきだろう。


    あと LED は 起電力があるのを忘れていた。これだと明るいところで L レベルになってしまうかも知れない。デフォルトを 1 にするなら H で 点灯という風に変更することにした。暗いところで "0" にならないか 不安があるが最悪は LED を外すことで対処。

    いろいろ検討したが、

    • M0 は 無接続(常に 1)

    • MI/M2 は、LED を接続(H で点灯) した上で、CB0/CB1 に接続 (TX/RX LED) 。

      AE-UM232R だと CBUS Bitbang で モードを選択可能。LED は UM162/AE-UM232R 側が使うが 排他で FPGA からも使える。

    • VS0/VS2 は LED を接続(H で点灯) 。

      こちらは、FPGA 専用。"0" に設定した場合でも 1K を接続するだけなので、LED は使える。

    • AE-UM232R では使えないが、UM162 では あと 2pin 使えるので CCLK, DIN に接続。

    • PROG_B/INIT_B を CB2/CB3 に接続。

    • PUDC_B を GND に接続

      PUDC_B を L にすることで、USER-IO ピンを プルアップする機能で、普通そうするもののようだ。最初はどうでも良いかと思ったが、不安定になったりすると嫌なので ちゃんとすることにした。


    基本的に ボードには手を触れないで操作できるように設計した。.. といっても AE-UM232R では、リセットして SPI FLASH から コンフィグするか JTAG からコンフィグするか選べるだけ。

    UM162 では、スレーブシリアルモード もサポート可能。ただし、スレーブシリアルモードのコードを開発する目的で使う。普通は JTAG を使う。

    ちなみに、SPI FLASH に書きこむには、バウンダリスキャンで、ちまちま書きこむか、書き込み専用の 論理を合成して 通信することで書きこむ。

      これは、ザイリンクスが提供している。詳しくは ここの XAPP974 に書いてあるらしい。

    余りピンの処理については、8bit SDRAM 時 使わないピンを VIA に出した。いちど 1.27mm ピッチで作ってみたが、drill が 0.4mm φにしかできず ピンも立てられないので、2.0mm ピッチにした。ほとんどは 一筆書きで VIA を付けられたが 1 つ は無理だった。これを外して 7bit にしたほうが良いかも。

    .. といっても 裏に IC ソケットがあるので ピンは普通では 立てられない。先に立ててしまうと、SDRAM のハンダ付けが困難になる。干渉しないような 一列の IC ソケットを使えば良いわけだが、0.8mm 厚の場合基板が弱いので、注意が必要。

    結局は役に立たないと思えるが一応。

    (追記) XAPP974 をちょっとだけ見てみた。PUDC_B を GND に接続している。これは、コンフィグ中に I/O を全部 pull-up する機能。一本だけ未使用 I/O (#49)があったので入れ替えて、PUDC(#99) GND に接続することに。

    03e:

    ちょっと MCP1700 が本当に使えるのか気になったので確認。

    1.2V の MCP1700 自体は、200mA が 定格だった。だが、これは放熱が完璧なときの話。いまの回路は 4.4 V (5V - ダイオード) 入力で 1.2V まで 3.2V も電圧差がある。.. となると core 電圧については、FPGA 自体が消費する 電力の 2.6 倍もレギュレータが消費することになる。50A でも、ひどいことになりそうなので、MCP1700 の場合は、3.3V から入力することにした。そうすると 3.3V のレギュレータの負担が増えるが、ダイオードで少しでも負担を減らすことで対処する。

    まぁ、相当厳しいような気がするが、クロックが低ければなんとかなるに違いない。

      こうすると 3.3V の負担が増えるので、結局やめて 別のダイオードを入れることにした。
      ダイオードを使わずに抵抗を入れるのもあり。最大消費電流の 150mA のとき 3V ほど落とせば良いわけで 1/2 W 20 Ωを入れる。


    DC/DC コンバータの SC189 を使えば core 電圧の方は心配しなくて良さそうだ。3.3V の方 は 大食いのSDRAM もある。だが、中華PMP の電源もこんな感じだからたぶん大丈夫だろう。

    最悪は、3.3V 外部電源。これなら問題ないだろう。

      TI に Spartan-3A 電源の必要条件 というページがあった。
      これみると 1.2V の Imax が 50A で 150mA, 200A で 350mA と書いてある。 3.3V は I/O 用が 3A で vccaux が 100mA 。今の回路だと 1.2V に 150mA 流せても そのときは 3.3v が苦しくなる。-- やはり SC189 を使った方が良さそうだ。3.3V も SC189 にしたほうが安心できるかも知れない。

      50A で 1.2V が 150mA といっても 最大クロックで動かした場合。クロックを落とせば電流は減るだろうから、MCP1700 で 3.3V から電源を取るのはやめようと思う。

    あと 03e で穴をあけてみた。穴をあけられる場所は、2 ヶ所しかなかった。しかも 2.2mm φがやっと。
    これで固定するのは無理。位置決めぐらいには使えるかも知れない。

    ところで VIA でコネクタもどきにしたが、これは使えるのだろうか?

    秋月に 1.27mmピッチのピンソケット などは売っている。データシートもあるので見てみたら 0.42 mm 角で drill は 0.7mm にするらしい。

    細かすぎて使えるような気がしないが、ユニバーサル基板もあるし、ピンだけはささるようにしておこう。

    これに合う変換基板もついでに作っておくのが、良いかも知れない。2.54mm ヒンペッダ とか MicroSD とか USB とか。

    とりあえずスナップショット。

一緒につくる基板について




    まず、CPLD 基板。

    Cool Runner II XC2C32A/XC2C64A が 32A で 114円と 結構安いし、手軽に使えると良いように思うのだ。64A にしても 223 円で そんなには高くない。

    こちらのボードも MCP1700 (1.8V) を載せる。MCP1700 も割と安く 10 個で 336円。これで 3.3V 単一電源で使えるモジュールにする。

    サイズは 50mm x 50mm に 2 枚取れるようにする方針で考えた。今回は 10cm x 10cm の 1/4 で 2 枚取れるから だいたい 1 枚 50円ぐらいの計算になる。基板の値段も これに見合う。

    • 足は 9x2列 を 両側に配置する。2 列あるが、1 列のみだけでも使えるように配慮する。そうすると 32 の ピンを使えるということになるが、ピンは 32A の 32 pin 分を出す。(JTAG は別コネクタ。)

    こうやって出来たものは、29.4 x 24.0 mm になった。47 mm に抑えた基板と組み合わせることで 2.5mm 程度の余白が取れる。

次に 『FLASH アダプタとか』の記事で作った基板のリベンジ。-- VIA をスルーホールにする計画だったのだが レジストでマスクされてしまっていた。

これだけ入れてもまだまだ入る。それはともかく面付けはどうしよう。


    検討したが、Fusion PCB でも『ガーバーデータのツール』が使えそうだ。ただし、ドリルデータ(TXT) の オフセットが 標準 CAM と 違う。... というか viewer でちゃんと見れるこっちの方が標準的だろう。大丈夫に違いない。




いまのところ こういう感じ。

まだまだ手直ししていくつもり。Fusion PCB のほうも 2/8 まで受注停止で 出来上がっても発注できない。

とりあえずスナップショットとして出来たものを保存しておく。

  • fpgaset1-02.zip

    上で説明していない基板は、まだまだ考察不足だが 一応説明しておくと ..

  • 右下 UM162 ボード x 2

    赤にするならついでに作りたいと思っただけで (製作中の基板にバグがない限り) 必要ではない。置き換えるかも。

  • 中央下 clk44 ボード

    これも以前作ったボードがベース。水晶の発振周波数を 調整できる仕組みを入れたいので作ってみることに。

  • 中央 TN8102BC キャラクタ液晶変換基板。

    以前記事にしたが、解析中のまま放置中。低消費電力の LCD は欲しいと思っているので、発注までに解析を再開して FIX したい。

  • 中央上 plltest ボード

    これまた 記事にしている。XMEGAボードを作ったとき おまけに付けた回路なのだが、余白があるのなら単独のものを仕込んでおきたい。

    CPLD や FPGA なら PLL 自体は論理回路なので 楽に組める。そしてあれば嬉しい機能でもある。 なので単独の VCO を 作ってみたわけだ。 ただ、これも放置中で 未テスト。


version 04



今はこうなっている。um162 は外そうかとも思ったが、一式載せる方針にした。



新しいのは、これ FPGA ボード用拡張ボード。 MicroSD , USB あと上記の pll 用 VCO 。一応は使えるものを目指した。



UM162 と同様に裏面に付ける。1.27 mm ピッチ 1 列の ピンヘッダ/ソケットで取り付けはできるが、固定する方法がない。今のところ 両面テープとか使って 無理やり固定するつもり。

マウントの方法がいまいちだが、良い方法を思いついていない。ネジ穴を切った ブロックを 下に貼り付けるぐらい?

あと、FPGA 側の拡張用の信号線を 少し変更。-- USB を付けようと 差動 I/O のペアを 調べたら、変な割り当てにしていたので。この変更で、差動 I/O が 2 つ取れるようになった。

これで、載せる基板はだいたい決まった。下半分は FIX 。右上 1/4 FIX 済み。決め切れていないのは、右上 1/4 。特に VCO 基板は重複してしまっている。

    忘れそうなのでメモ。

    全般:

  • FPGA ボードから切りだして作っている。大きさは、LED とか ボタン , UM162 と 干渉しないように決めた。
  • 10 pin の ピンヘッダを付けて、他の使い方もできるように配慮した。

    USB:

  • D+/D- 差動 I/O のペアを割り付け 抵抗を入れられるようにした。
  • スルー 用の端子をつけた。アナライザ用
  • HOST にできるかも知れないので、MINI コネクタの ID を ピンに割り当て。あと、VBUS を 出力 できるように FET スイッチを付けた。
  • プルアップ/プルダウン用の 抵抗と制御線を入れるべきかも。不要にできるのかどうか分かっていないが、まだ付けていない。

    (追記) やはり プルアップ抵抗用の制御線を付けた方が良さそう。LowSpeed なら D- FullSpeed なら D+ をプルアップするから 2 本と抵抗が必要。それに加えて VBUS 検出用の 信号線も 付けよう。これは VBUS を 分圧して入力するから抵抗が さらに +2 。

    MicroSD :

  • 一応全結線。
  • 電源ラインに インダクタを入れられるようにしておいた。カードの中にコンデンサがあるらしいので、インダクタのみ。ホットプラグしないなら、ジャンパで良い。

    VCO :

  • 回路は、以前作ったもの のやきなおし。
  • フランクリン発振回路なので、LC メータとか作れるように配慮。
  • 水晶発振器のVCOにもなるよう ピン配置を決定。



    フランクリン発振回路の C を容量可変ダイオードで変化させるもの。FMトランスミッタで似た様な構成のものがあるから 部品の選定次第で FM 帯域までいけるはず。

    LC を調整して LC メータとかも作れる。タンク回路の部分に 端子を付けておいた。ここに C または L を付けることで周波数が変化するから 差分から 値がわかる。

    C5/C6 はこの回路では付けない。



    C5/C6 を付けて XIN/XOUT (白で囲んだ端子) に水晶を付けると 水晶発振器の回路になる。ただし下の部分を接続しない。

    C1 をジャンパして、容量可変ダイオードを活かすと 水晶発振器の周波数を調整できる。温度をセンスしてフィードバックをかける用途を想定。

    ちなみに、上にある Tiny44A のボードは、この回路を組み込んだもの。... 下半分でこれだけ違う。FPGA ボード関連のものにしたほうが良さそう。

      検討してみた。2mm ピッチの方の 拡張基板というのはどうだろう? 2mm ピッチの方は 3.3V が接続されていない代わりに 5V が接続されている。USB 基板は、3.3V を必要としない上に 5V があると便利になる。MINI-B から 電源を取るだけでも良いし、HOST にした場合供給することもできる。

      詳しくは後述する。

    スナップショット。


  • ピンアサインのメモ: (04a)


    MicroSD USB PLL
    #1 VCC
    #2 DETECT D- PULLUP PLLCTRL
    #3 DAT2 -- --
    #4 DAT3/CS D- INV
    #5 -- D+ XIN
    #6 CMD/DI D+ PULLUP --
    #7 DAT0/DO VBUS DETECT GND
    #8 DAT1 VBUS SWITCH --
    #9 CLK -- XOUT
    (PLLCLOCK)
    #10 GND

    NOTE: #9 (GCLK) , #4/#5 #6/#7 (DIFF PAIR)


    ちょっと考えたのだが、MicroSD は カードを入れなければ、#2 DETECT 以外 OPEN 。これを FPGA ボードに貼りつけて配線してしまえば、2x5 の ピンヘッダを立てられる。ほかのカードは 、ピンヘッダを利用して スタックして使えば良い。

    DETECT は 片側を GND にしたスイッチで カードを入れなければ OPEN ではあるが pullup して使うことを想定しているので、ボードに 抵抗を追加するかも。

    #3 は、配線が面倒なので 他のカードでは使っていない。#2 と #3 を入れ替えるべきだろう。
    ついでに、FPGA 側の信号線との関係。

    コネクタ FPGA 信号名
    #2 #28 L03P_2
    #3 #32 L05P_2
    #4 #33 L06P_2
    #5 #35 L06N_2
    #6 #36 L07P_2
    #7 #37 L07N_2
    #8 #39 IP_2/VREF_2
    #9 #41 L08N_2/GCLK15


    あ、#8 は 入力専用なのを忘れていた。これも直さないと。

  • version 04b




    サイズは同じだが、今度のは、2mm ピッチのほうに付く USB ボード。5V 外部電源用の スルーホールを利用して 2 ヶ所で止められる。そして、1.27mm にも 依然として付けられる。

    ただ、スルー用のコネクタは付けられなかった。あと 1.27mm ピッチの #1 3.3V も無理だった。また差動ペアの割り当ては無理。どうせ 12Mbps までしか無理だろうし 別に困らないとは思うので気にしない。

    このボードには部品を付けないで、単に 2x5 の変換基板としても使える。ただし、#1 3.3V は接続されていない。(裏面に)パッドは用意できたので、どこからか、3.3V を引っ張ってくれば、他のオプションカードの取り付けができる。

  • version 04c



    今はこうなっている。04b で clk44 ボードをやめて、オプションボードを追加したが、04c で さらに追加



    今回 は、3.3V 電源強化 ボード。sc189 ボードを変更して取り付けられるようにした。
    これで、3.3V の消費電流が 増えたときも対応できる。

    最初から組み込めば良いとも思ったが、このサイズには入らない。それに、必要とは限らないし、これでヨシとする。

    その他の変更

    • plltst ボードは 1 つにして、sc120 ボードと sc189 ボード(normal) を追加。... sc189 は、前の小基板セットで失敗しているし、リベンジ。

    • xc2c32a CPLD ボードに 水晶 を取り付けられるよう変更。別に付けなくとも良いが、付けたくなるケースが多いだろうと想定。インバーターは CPLD 側で用意するのが前提。

    そろそろ、これで FIX 。あとは、チェックあるのみ。

    スナップショット:


    そろそろ、... と思ったのだが、1.27mm ピッチの部分、どうにかならないか。

    1.27mm ピッチ単列だと 強度的に不安がある。一応 ケーブル直付けできるようにしていたのだが、 ケーブルを直付けするのは 美しくない。だが、2.54mm ピッチだと 入らない。

    試しに 2mm ピッチ 2x5 を 置いてみたら入りそうなので、検討してみることにした。

      2mm ピッチは aitendo で 結構な種類を扱っている。2x5 だと

    • ピンヘッダ(2.0mm/2列)[PHEADER-2.0PT-D] 40pin 50円
    • 接続ケーブル(2.0mmピッチ10P)[CB-2PT10P-25] 100円

      で十分か。ちなみに、1x10 だと PHR-10 というのがある。

    • ケーブルアセンブリ[CB-PHR10P-240] 片側コネクタ 150円
    • ケーブルアセンブリ[CB-PHR10-10-26AWG-220] フラットケーブル 両側コネクタ 100円

      このあたり。ピンヘッダは、在庫切れだが、秋月にある

      コネクタなどは、入手できることが分かった。で、うまくいくのか?



      こんな感じ。コネクタと IC が近すぎる。これだと FPGA をハンダ付けするときに、ポリミドテープとかでマスクしてハンダ付けしないと、ハンダでスルーホールを埋めてしまいそうだ。

      ただ、1.27mm ピッチにしたとしても、さほど事情は良くならない。また、1.27mm ピッチではケーブルを引き出すコネクタがない。コネクタがあるのは 1.25mm ピッチで微妙に合わない。

      ... というわけで 2x5 に全面的に切り替えることにした。位置合わせはさほど難しくない。全部もとは同じなので、同じ座標に置けば良いのだ。ただ、基板が増えているので 修正は面倒。



      表面に装着したイメージ。今回は青基板の画像を作ってみた。

      • 青基板の方が良いかも知れない。
      • パターンの露出面を 金色っぽくしているが、ENIG だとハンダの乗りが悪いそうなので、HASL にするつもり。
      • 左上の 穴は 2.2 φ→1.5 φにした。あまりにぎりぎりだと、パターンを痛めそうなので小さくした。
      • USB アダプタは、16bit幅 SDRAM とは 両立しないので、たぶん 使わない。




      こちらは、UM162/AE-UM232R を載せる方。裏なのだが、普通はこちらを上にして使う。

      • MicroSD アダプタ を置いてみた。ソケットが 2.54mm ピッチの方にかぶるので、MicroSD アダプタ と 2.54mm ピッチ変換は両立しなかった。
      • ケーブルが引き出せることが分かったので、基板に直接載せる 使い方はしないかも。
      • アダブタにコネクタ付きケーブルを付けるのなら、2.54mm ピッチに一回通して 2mm ピッチ側にハンダ付けするのが良いかも知れない。


    ところで、イメージファイルを作るのが面倒。ガーバデータは解析できているのだから自力でイメージを作るようにした方が便利かも知れない。ちょっと検討してみよう。

    あと、CPLD ボード。こんなにいらない。手軽に使うには潤沢に持っている方が良いと思って x2 にしているのだが ... どうしよう。

verstion 05b



    今はこう。

  • plltst をついに外した。入れたのは、2x5 の変換基板。180 °回転と、裏表入れ替え。作っておくとマウント方法に幅ができる。特に 180°回転なんて変換基板はないと思うし 配線が面倒なので有用かも知れない。ちなみに 単に 2mm ピッチ→ 2.54 ピッチ変換するだけなら、他の拡張基板に付いているから切りだしても良い。あと aitendo で扱っている基板から切り出す手もある。

  • 右上 pmpset1 で 2mm ピッチのところ に ラインを入れた。こうしておくと RC を付けたいとき 使えるかも。

  • CPLD 基板みなおし。変換基板だから単純なのだが、VCC と GND を接続したりしていると悲惨なことになる。たぶんこの基板はもう作る機会がないと思うので ちゃんとチェックした。

    結果は 一応 OK なのだが、水晶を 付けるピンを 1つしかない Global Set/Reset を使わないよう変更した。

    さて、そろそろと書いてから、だいぶん変更を重ねてしまった。FPGA ボードの方の配線のチェックは、一応済ませた。(後ろでまとめている)。あとは位置的な問題と周辺回路のチェック。

    スナップショット:


追記: イメージファイルの生成

    ガーバーデータのツール』をもとに、自力でイメージファイルを生成することに成功した。これで 貼り付ける画像の作成が楽になる。詳しくは、該当記事に追記しているので参照のこと。

    CPLD 基板をどうするか、再度検討。

    CPLD 基板でやりたいことをする基板は前に作ったのだった。作った基板を使わないうちに 新しい基板を作らないことにした。

    で、おなじサイズで差し替え用の基板を作ることにした。ひとつは 照明用LED基板。5mm の LED を 12 個載っけて 12V で使う。

    あと tn8102bc 基板を復活させる。ただし、発注する前に 動作確認ができた場合の話。もし動けば普通の キャラクタ液晶の 1/10 程度の消費電流(0.1mA ぐらい)になる見込みで やはり使いたいのだ。



    こんな感じか。作り直したらパターンをコンパクトにできた。コネクタの配線は、普通のキャラクタLCD に合わせてみた。使えそうなら、このパターンをベースにして、AVR を載せて... みたいなことを考えたい。

    スナップショット:

  • 随時更新している。

    最新では、Makefile を入れた。ファイルの数が増えてきたので管理しきれない。CAM プロセッサーは自動では動かせないが、時刻をチェックして 更新もれを防ぐようにしている。あと、生成したイメージファイルの 削除とかにも便利。-- xpm はかなりでかい。全体画像だと 4MB (png だと 170KB まで圧縮される)

    下の画像も make で作っている。これぐらいの解像度でイメージに変換してブラウザでチェックするのが、一番見やすいような気がする。


    version 05d/05e

    中央上の 2x5 変換基板に抵抗を入れることにした。入れるのは #4-#7 の 差動用端子。入出力を動的に切り替えるかも知れないので衝突対策。変換基板が大きくなったので、sc189 基板を外した。

    大して変えていないのだが、これで良いのか?不安なので、ファイルを変更。

    あらためて画像を見ると、だんだん FPGA ボードのサポートボードの面積が増えてきた。FIX したら 1.6mm であらためて発注しようとは思ってはいるのだが、肝心のFPGA ボードで失敗するとだいなし。いまいちどチェックしよう。

    05e では、FPGA ボードのアートワークを見直し。左右のボード端の部品を少しでも内側に寄せるようにした。(ケース MK6040 に固定するとき部品が端にあると困る)

    さすがにそろそろ FIX か。あと一週間になったし、UM162 ボード や tn8102bc ボードの確認もしておきたい。

    スナップショット:


    いよいよ、発注の時期が迫ってきた。冷静にレイアウトを眺めていると 拡張ボードばかりなのが気になる。これら、全部有用なのか? やりたいことや開発の手順を考えてみたが、USB とか MicroSD とか 割と後回しになる。

    大体、USB を使ってみたくとも 33MHz 以外のクロックを付ける予定がなかったりする。x2 の 66MHz で 無理やり動かすとか考えだすと、なかなかにハードルが高くなる。

    各ボードの 2mm ピッチ 2x5 を 外すとかして小さくして、FPGA ボードに関係したものを 下半分にまとめられないか 検討してみよう。

    追記:

    つれづれ日記』で知ったのだが、『Microtouch - a handheld AVR touch screen demo board』-- すごくいい。基板サイズは、45mm x 50mm で 右上の pmpset1 と置き換えられる。突っ込んでしまいたい。mega32u4 も持っているし、液晶も 37pin タイプのようだ。ただ、水晶とか MicroSD スロットとか 一部の部品が秋月で買える部品と 違うものを使っている。液晶も 1mm / 0.8mm ピッチではないかも知れない。手直しして突っ込むか -- どうしよう。

    別記事 『microtouch』で検討してみたが、今回はパス。慌てる必要はない。じっくり検討しよう。

設計してみた感想 .. というか、今後どうするかについての想定

    Startan 3A 50A と 200A の 100ピンタイプ(VQG100)を選択してみたわけだが、SDRAM だけで ピンがほとんど埋まってしまった。SDRAM を付けた以上なにか高速な I/O をしたくなるが、I/O 用のピンが少ないのがネック。2 枚のボードを接続してある程度高速に通信できるようなら、SDRAM なしの I/O 専用ボードというのも考えてみたい。

    I/O 専用ボードでも 100ピンを使っても良いのかも知れないが、144ピンのデバイスを探してみると、Startan 3AN 50A が 812円で買えることが分かった。 HUB みたいにしてSDRAM付きボードを何枚か接続できて 外部のデバイスを扱えるようにするものを考えてみたい。... といっても SDRAM付きボードが使いこなせてからの話。実現できるかどうか分からないが考慮だけはしておこうと思う。

    これ以上の規模になると、BGA になってしまう。2 層基板では無理だし 電子工作の範疇を超えそうだ。100 pin の 200A と 144pin の 50A だけでなんとかすることにして、チップ間の通信に力を入れるようにしたい。

      あ、144pin の Spartan-6 が買えるのか。じゃぁこれ一択だ。良くは知らないが。まぁ 先の話。

      (メモ: Spartan 3A VQG100/Spartan 6 LX9 TQG144 比較 )

      ロジックセル  スライス 乗算器 最大USER-IO(うち入力)
      (換算) CLB ブロックRAM DCM 価格
      50A 1584 176 704 6K x 9bit 3 2 68 (6) 501 円
      200A 4032 448 1792 32K x 9bit 16 4 68 (6) 1014 円

      LX9 9152 ? 1430 64K x 9bit 16 4 102 (?) 1286 円

      ブロックRAM 1 個 2K x 9 bit

      LX9 は、CMT に 2 個の DCM と 1個の PLL が含まれている
      LX9 は、DSP48A1 スライス に 1 個 の 乗算器 と 加算器 ,
      アキュームレータが含まれる。

      やはり一択っぽい。だが、これを選ぶと今回のデザインにはなり得ない。だからステップアップするときに使えば良く、今回はこれで良いのだ。


    ところで、8bit しかない I/O でどれぐらいの性能が出せるのだろう?

    ちなみに SDRAM は、前に調べたところ、連続した 8 つのデータ を読み書きするなら、16bit 幅なら 2x8 の 16 バイトに CL2 で 13 クロック(CL3 でも 15 クロック)。1 クロックあたり 1 バイト前後。大雑把に言って 66MHz システムクロックなら 66MB/sec 。これと比べて 数分の一ぐらいの帯域は欲しいところ。

    単一のシステムクロックで全部動かすつもりだったのだが、I/O だけ 倍速や 4倍速にするのは可能なようで、その想定はやめた。どうせ高速 I/O なら FIFO を入れるつもりだし、非同期でも問題ないようにもできる。
    こう考えることにすると 3.3V の シングルエンドは 物理的な配線の都合から 33MHz の DDR が限界だと考えた方が良さそうだ。これが可能なら シングルエンド 4bit で 33MB/sec まで行く。あまり心配する必要はなさそう。ひょっとしたらもっとクロックを上げられるかも知れない。PC の DIMM なんかでもシングルエンド(しかもバス)で 133 MHz 実現していたわけだし。

    ちなみに FIFO を ブロック RAM に取るとすると 1KB x 16bit 。ちょっとオーバースペックだが 200A なら 16個あるから 積極的に使っても良いのかも知れない。ただ、50A は 3 個しかない。I/O 専用ボードも なるべくなら 200A にした方が良さそう。

      小容量の FIFO は、分散RAM を使うのが普通らしい。8 データのバースト用バッファなら 16bit x 16 あれば良さそう。ただ CPU の バーストアクセスのために WAIT が入るような作りだと この数倍必要。大容量の FIFO を使うにしても クロックの乗り換えのために 小容量の FIFO を一回通すのは良いような気がする。

    さて I/O ピンは 8bit 分しかない。しかも 1本は入力専用なので クロスしない配線で済ますとすれば 7bit分 しかない。そのうち 4bit は、差動 I/O に使える。シングルエンドにしても この 4bit を使って 高速 I/O することにしよう。その場合 CLK が別に必要になりそうなので、+1 本を クロック専用ピンということにする。

    残りは 2 本だが、これは I2C のような 使い方をしようと思う。並列でつなぐので、どういう風に 高速 I/O 用のピンを 接続するのかネゴしたい。つながった後は あまり関与する必要はなさそうだが、BREAK みたいなことは出来た方が良いかも知れない。ug331 を 確認したら 3STATE_PULLUP という設定があったのでこういう使い方はできそうだ。

    高速 I/O 用のピンのひとつの使い方は、上記のものだが、差動 I/O もあるので、これも考えておきたい。

    とりあえず、調歩同期を考えてみる。2 チャンネルあるが、どちら向きで使うかは、I2C でネゴ。ひとつの 差動 I/O では、システムクロック x 2 でサンプリングすることにして、3 クロックで 1bit にしようと思う。66 MHz なら 44 Mbps 。10bit で 1 バイトだから 4.4 MB/sec 。片方向に 2 チャンネル使うなら 8.8 MB/sec 。

      この数倍も可能なような気がするのだが、クロックがない。66MHz を 2 倍にして 133 MHz がせいぜいか。そういえば、SDRAM 自体も 133MHz までいけるのだから、メモリコントローラも システムクロックの 2 倍速で動かしても良いはずだ。 これもいずれトライしたい。今は忘れないようメモのみ。

    ちなみに 480x272 16bpp のグラフィックデータを 30fps で送るとすれば、7.47 MB/sec 。だいたいこれぐらいの帯域。しょぼいと言えばしょぼいのだが、まずはこのあたりを目標にしたい。

    FPGA の使い方の考察は、この程度にしておこう。ここではなんとかなるということが分かれば十分。

    追記: 2/9 いよいよ 発注の時期が迫ってきた。わけだが ... ここに至って、Pmod というのを知った。Digilent が 設計して 拡張モジュールを発売しているらしい。で、大概の学習モジュールは、これに対応したピンヘッダが出ている。Pmod は 12ピン -- 2列x6 で 1列だけで使うこともできる。

    対応すべきかどうか? .. 本体はもう変えたくない。2mm ピッチだし同じにはできない。10 ピンのケーブルなども 入手済みだし。-- それで良いだろう。だが、拡張ボードの類はどうだろう? 2.54 mm ピッチは 本体とは関係ない。できることなら合わせておいたほうが良いのでは? ... ちょっと悩んでみよう。

    追記: 2/15 予定の期日を過ぎてしまった。結局、最後の 05f をそのまま出した。今は FPGA での設計の方が楽しくなってきていて、基板にはこれ以上時間をかける気がなくなった。失敗するかも知れないが、出してみる。

    ところで色については気が変わった。白にすることにした。価格は $50 。over $50 で送料無料と書いてあったが、$50 で無料になった。ただし、ただの書留。どうせ、設計している間に来てしまうのだ。遅くても全然かまわない。

    発注データ:
  • fpgaset1-05-fusion.zip
  • fpgaset1-05g.zip
  • 最新画像(表, 508dpi, 白)
  • 最新画像(裏, 508dpi, 白)

    追記 2/16 : 作れないというメールが来た。問い合わせてみると、1 ボードにするのは、OK だが、テストできない ということらしい。テストできないのを 許容するなら OK 。

    無条件でテストしないというのは嫌なので、どう変更したら良いか問い合わせ中。

    追記 2/17 : 答えの代わりに『13 個の PCB のうち 5 個までならテストするよ』という返事が来た。



    画像を送って、『OK なら 製造開始してね』 ということにした。

    良く分からないのは、右上が、1 枚と認識されること。実際一枚なのだが --- マージの仕方がだめなのだろうか? といってもツールを変更することは怖くて出来ない。

    3/3 追記: Fusion PCB の方には書いたのだが、こっちにも記載。

    結局、上記のは勘違いで、『5 枚を残して消したデータを送れ』ということだった。それは嫌なので、panelize.ulp でマージしたのをさらに 面付けしたデータを作って送った。



  • fpgaset1-06-fusion.zip (発注データ → 受け付けられた)
  • fpgaset1-06.zip (元データ)
  • 画像(表, 508dpi, 白)
  • 画像(裏, 508dpi, 白)

    その後、2/28 に 送付という連絡が来た。たぶん 受け取りは 3/10 前後になるだろう。

    (注意) 今回は、無理を言って作ってもらった感がある。5 枚もの ボードを面付けして 送っても 受け付けてもらえないかも知れない。面付けしたデータも公開しているが、それをそのまま送って作ってもらうのは、推奨しない。

    もし自分で基板を切ることを前提にして 面付けしたいのならば、個々のボードを panelize.ulp でマージしてほしい。この場合は、1 枚として認識されるので問題ないようだ。

    あといちいち書いておくが、公開したボードデータのライセンスは、GPL ということにする。この EAGLE ファイルを使って ボードを作り、それを他の人に渡すのであれば、(作ったボードそのものの) EAGLE ファイルも渡さなければならない。そして、渡された人が GPL の範囲で利用することを妨げることはできない。それを守る限り 商用利用も OK 。なお自分のためにボードを作り他の人に渡さないなら、私的利用 であり 著作権は及ばないとみなす。


付録: ピンアサイン一覧

    1.27 mm ピッチ拡張コネクタ

    MicroSD USB PLL
    #1 VCC
    #2 DAT2 D- PULLUP PLLCTRL
    #3 DETECT -- --
    #4 DAT3/CS D- INV
    #5 CMD/DI D+ XIN
    #6 DAT0/DO D+ PULLUP --
    #7 DAT1 VBUS DETECT GND
    #8 -- -- --
    #9 CLK VBUS SWITCH XOUT
    (PLLCLOCK)
    #10 GND

    NOTE: #9 (GCLK) , #4/#5 #6/#7 (DIFF PAIR) , #8 INPUT



2mm ピッチ コネクタのアサイン

コネクタ SDRAM FPGA 信号名
#1 5V
#2 DQ14 #19 L06P_3
#3 DQ12 #15 L05P_3
#4 DQ10 #12 L04P_3
#5 DQ1 #9 L03P_3
#6 DQ3 #5 L02P_3
#7 DQ5 #3 L01P_3
#8 DQ7 #98 L06P_0
#9 DQ8 #71 L05N_1
#10 GND


SDRAM の割り当て表 (2mm ピッチに出ているものを除く)

SDRAM FPGA 信号名
DQ0 #10 L03N_3
DQ2 #6 L02N_3
DQ4 #4 L01N_3
DQ6 #49 L10N_2
DQ9 #72 L05P_1
DQ11 #13 L04N_3
DQ13 #16 L05N_3
DQ15 #20 L06N_3

LDQM #94 L05N_0
UDQM #70 L05P_1

WE #93 L05P_0
RAS #89 L04N_0
CAS #90 IO_0
CS #88 L04P_0
CKE #64 L04P_1
CLK #65 L04N_1

BA0 #86 L03N_0
BA1 #85 L03P_0
A10/AP #84 L02N_0

A0 #83 L02P_0
A1 #78 L01N_0
A2 #77 L01P_0
A3 #73 L06N_1
A4 #50 L11P_2
A5 #52 L12P_2
A6 #56 L01P_1
A7 #57 L01N_1
A8 #59 L02P_1
A9 #60 L02N_1
A11 #61 L03P_1
A12 #62 L03N_1


UM162/AE-UM232R との接続表

Serial + SPI
 #1 TXD(PD3) (MOSI) #7 IP_3/VREF_3
#2 DTR(PD7) (SS) #21 IP_3
#3 RTS(PD6) (SCLK) #40 L08P_2/GCLK14
#5 RXD(PD2) (MISO) #34 L05N_2

Clock:
#11 CB4(PC5) #44 L09N_2/GCLK1

Config:
#12 CB2(PC4) #100 PROG_B
#16 (PC2) - J2 - #53 CCLK(L12N_2)
#17 (PD0) - J1 - #51 DIN(L11N_2)
#18 CB3(PD1) #48 INIT_B(L10P_2)
#22 RX_LED/CB1(PD4) #24 M2(L02P_2)
#23 TX_LED/CB0(PD5) #23 M1(L01P_2)

JTAG:
#6 SS #1 TMS
#8 SCLK #76 TCK
#9 MOSI #2 TDI
#10 MISO #75 TDO



CPLD ボードピンアサイン


    A B brd-opt C D
    1 31(GO) 30(GRS) VCC VCC
    2 33(GO) 32(GO) XIN 29 28
    3 36 34(GO) XINV 27 23
    4 38 37 22 21
    5 40 39 20 19
    6 42 41 16 14
    7 44(GC) 43(GC) 13 12
    8 2 1(GC) XOUT 8 6
    9 GND GND 5 3

    GO : Global Output
    GC : Global Clock
    GRS : Global Set/Reset


    水晶使用時:

    XIN -- |>o -- XINV -- |>o -- XOUT

    を組む。
  • JTAG

    JTAG
    1 24 TDO
    2 11 TCK
    3 9 TDI
    4 10 TMS
    5 GND

  • その他:

    VCC 7,26,35
    CORE 15
    GND 4,17,25
    N.C 18 (INPUT)

メモ: UM162 ボードのピン配置。


posted by すz at 22:22| Comment(0) | TrackBack(0) | artemis