以前、TrenzElectronic社のTEC0117を使ってGOWINのJTAGを調査しようとしたときには、オンボードのUSB-JTAGを無効にすることができなくて半ばあきらめていたのですが、自宅療養で暇だしMITOUJTAGもMPSSEに対応したこともあって再チャレンジしてみました。
TEC0117にはGOWINのLittleBee 1NR9 FPGAが乗っています。GW1NR9とGW1N9の違いは内蔵メモリだそうで、内蔵SDRAMが入っているのがNR9です。
下の写真は私の持っているTEC0117のボードです。以前実験した時の名残のピンヘッダがいくつか立っていますが、今回はUSB-JTAGを使うのでこのピンヘッダは使いません。

MITOUJTAGをひらいてケーブルを自動接続すると、MPSSEが認識されます。

デバイスの自動認識ボタンを押すとデバイスが見つかり、候補の一覧が表示されます。
TEC0117に乗っているFPGAの型番はGW1NR-9なのですが、NR_9系統を選ぶと正しくバウンダリスキャンされません。

ここでは、1N_9のほうを選びます。

どうやらGOWINが提供しているBSDLファイルでは1NR_9のほうがバウンダリスキャンセル長が長くなっているのですが、GW1N_9を選ぶとずれてしまうようです。中身はGW1NR_9もGW1N_9もどちらも同じなのではないかと思われます。(そういうのは、高解像度のX線CT検査機があるとわかりますね)

そういえばボードのLEDが光っていません。
内蔵フラッシュを消してしまったのかもと思い、Trenz社のTE0117のページから「工場出荷時に書き込まれていると言われているファイル」をダウンロードしてみると、中身はこれだけ。

このPicoSoC.fsというのが書き込まれているデータなのでしょう。開いてみると・・
0000010100101011
1111111111111111
1010010111000011
0000011000000000000000000000000000010001000000000101100000011011
0001000000000000000000000000000000000000000000000000000000000000
0101000100000000111111111111111111111111111111111111111111111111
00001011000000000000000000000000
1101001000000000111111111111111100000000111111111111000000000000
00010010000000000000000000000000
0111011100000000000010011001000
11110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
まさかの'1'と'0'のテキストファイル!
これを解読するのは大変そう・・
FTDI何とか.pngを開くと、FT_Progを使ってPort AをD2XXにしろと書かれています。

この設定をするとGOWIN EDAのProgrammerから書き込みができるそうです。
しかし、そのとおりに設定しても認識されません。このオンボードのUSB-JTAGはDigilent互換のものであるようですが、思い切って消してみるとGOWIN Programmerから認識されて書き込みもできるようになりました。

このツールでTEC0117のFactory Imageを内蔵ROMに書き込むと書き込めて起動するのですが、内蔵SRAMに書き込んでも起動しません。もしかするとRAMベースのFSファイルとROMベースのFSファイルで何か違うのかもしれませんし、ソフトCPUが入っているデザインはROMからしか起動できないのかもしれません。
適当なLチカのファイルを書いて、

ピン定義も適当に作り、GOWIN EDAから書き込んでみると、一発でうまくいきました。

ツールの作りはE社よりもGOWINのほうが優れています。
さて、自分のJTAGツールからFPGAに書き込めるようにしたいのですが、このFSファイルの扱い方がわからないとどうにもなりません。また、データシートどおりにJTAGを操作しているのですがSRAM Eraseさえ動いている感じがしないのです。
そこで、SVFファイルを作るためGW1N4というデバイスに変えて実験してみます。GOWINのEDAはGW1N4だけはSVFファイルを作ることができるからです。
FSファイルは以下のような感じでした。
こうしてGW1N4のSVFを作り、FSファイルを見比べてみます。
まず、FSファイル。先頭にコメントがありますね。Trenz社のFactory Imageのはこのコメントが削除されてしまっているようです。

FSファイルは先頭に凸凹した部分があって、その後ろに巨大な10ブロックが続きます。
このFSファイルをもとにSVFを作り、見比べたものがこちらです。ファイル先頭の凸凹している部分はSVFには含まれておらず、巨大ブロックの部分から書き込めばよいことがわかります。

FSファイルの巨大ブロックの1行1行の右端の部分は2296bit目から密度が変わっていて、アドレスか、チェックサムと思われるビット列が付け加えられていました。

この長方形の10ブロックの大きさは、データシートに載っているサイズと一致していました。

GW1NR9の場合のBitStreamの場合は先頭に4bitの1111が付きますが、おそらく1列の長さを8bitの倍数にするためではないかと思われます。

またSVFファイルを見ると、JTAGでコマンドを与えるたびに
RUNTEST 5 TCK;
というのを実行しています。

このRUNTEST 5 TCKを行ったらSRAM Eraseが動くようになったので、Update IRの後でSelect DR Scanに戻すのではなく、必ずRun-TEST Idleを通らなければならないのだと思われます。
このような感じで、GOWINの書き込み方はわかってきたのですが、FSファイルのBitStream部分だけを抜き出してJTAGで送ってみてもコンフィグは成功しませんでした。
今度会社に行ったらオシロスコープで波形を見ながら考えてみようと思います。
最近のコメント