当サイトの検索で結構多いのがカメレオンUSBロジアナ用に木村さんという人がこしらえたmyLAというロジアナソフトを求めて来た人。

サイトのドメイン名の権利が失われているのでサイトが消滅した形になっており、諦めた人も多いのでは。

ふとインターネットアーカイブにあるのではと思いあたってみたら、当時のコンテンツがそのままありました。

myLAのインターネットアーカイブ(2003年3月8日版）

表示エンコードは日本語(euc-jp)にすれば文字化けは無くなります。

ここから最終版のmyLAをダウンロードすることができます。

よかったね（´∀｀　）

いまのうちにダウンロードして保存しておくのが吉かも。

当サイトへの検索サイト経由で検索がヒットしてアクセスしに来た記録を見ていたら、MyLAというのがあった。

MyLAというのはオプティマイズのカメレオンUSBベースのロジックアナライザのWindowsソフトを木村さんという人が独自に改良して、複数ビットのHex表示トレースやアナログトレース等が出来るように機能追加した版である。オプティマイズのサイトのカメレオンUSBロジアナのページに今もリンクが掲載されているが、いつからだったかドメインが管理会社の管理になってしまっていうのでサイトが消えてしまった格好になっている。

オプティマイズのオリジナルのロジアナのWindowsソフトはソースコードも含めて現時点でもまだちゃんと公開されていてダウンロードできる。

木村さんのMyLAもオプティマイズのオリジナルにコードを追加したものなので、MyLAに代わるものを作ろうとしたら出来ないことはない。

でも木村さんはMyLAのバイナリだけを公開しオプティマイズのソースを改変したソースコードそのものは公開していなかった。従って、私の手元には消滅する以前にダウンロードしたMyLAのバイナリがまだあるが、これには木村さんが独自に追加したコードが含まれているので、著者権が木村さんにあり私は木村さんに代わって公開することはできない。

本当はオプティマイズがフリーでソースコードを公開しているのだから木村さんも改変したソースコードを公開して欲しかった気もする。もちろんオリジナルにライセンス条件とか配布条件とか明確な規定は無いのでどうしようもないのだが。

オプティマイズのカメレオンUSBロジアナとMyLAがあればほとんど自室で出来る程度のデジタル回路の実験や解析は出来てしまう。専用のロジアナとか持ち出さなくても済むのである。もちろん単純なトリガ条件しかできないので、もっと複雑なトリガ条件を必要とする時には専用ロジアナの出番にはなるが。

こうやって一時期は公開されてもサイトの持ち主がドメイン名とかの管理を怠っていつしか誰もアクセスされなくなるという事件は今後増えていくのかもしれない。

数年前にいろいろブラウザーのブックマークに登録したまま頻繁にチェックしていないサイトとかには、やっぱり消えてしまったものもある。

暇があったらMyLAと同様の機能を持つバージョンを復刻させてみたい気もする。

ふと思い返してもういちどサンプルし直してみることに。

今度はサンプル開始後しばらくしてからトリガーを与えてみることに。

するとちゃんとトリガー以前のサンプルデータが表示されているでは。

つまるところおかしいと思っていたのはいつもトリガーがサンプル開始直後に発生するためRAMへの書き込みが一巡してなかったためでした。bad_dataはramが一巡するまで最後に書き込まれたアドレス以降の残りRAM領域長をカウントしているので意図した通りに機能していました。

細かいところではトリガーポイントの表示が実際のポイントより少し手前にずれているというのはありますが、実用上は問題ないでしょう。

トリガー回数とかを指定できるようにして２回目のトリガーとかをとらえればトリガー発生以前の状態もわかりますが、CPLDがもう余裕が無いのでこれ以上ロジックを追加するのは無理くさい感じ。

ロジアナソフトのサンプルデータ読み出し処理部分を見てみると、どうやらRAMの全内容を読み出した後、先頭部の無効データを０クリアしている箇所を発見。

//ＲＡＭの読み出し
buf[0]=GPFW_BREAD|0x06;
buf[1]=(u8)(SAMPLES*4);
buf[2]=(u8)((SAMPLES*4)/64);
buf[3]=(u8)(((SAMPLES*4)/64)>>8);
usb_bulk_write(&dh,GPFW_CPIPE,buf,4);
usb_bulk_read(&dh,GPFW_RPIPE,ram_buf,SAMPLES*4);
//無効データ長の取得
buf[0]=LGFW_GETBAD;
usb_bulk_write(&dh,GPFW_CPIPE,buf,1);
usb_bulk_read(&dh,GPFW_RPIPE,(u8*)&bad_data,2);
//無効データを０クリア
memset(ram_buf,0,bad_data*8);

これの意図しているのはおそらくトリガーPOSITIONがCENTERやLASTを指定した際に早い時点(RAMの最後まで書き込まれる以前）にサンプルが終了した際に残りのRAMにはサンプルデータが含まれていないので０クリアするということだろうがどうもうまくいっていないようだ。

無効データ数はファームウェアでRAMを読み出す際にカウントしているのだがそこが少し怪しい。本来はRAMを一巡してしまえば無効データは無くなるはずだが常にRAMの長さからトリガー後のサンプルデータ長を差し引いた値になってしまっているようだ。つまりトリガーポイント以前にサンプルされたデータはすべて０クリアされてしまう。

すこし問題があるオリジナルのデザインを改良してマニュアル停止してもトリガポイント以前のサンプルデータも正しく表示できるようにすることは可能である。

まだリソースに余裕があれば、内部にレジスタを追加しST_STPとRAM_ADDのリセットを別にもうけて、それぞれH_WRとH_MODEでセットおよびリセットができるようにするというもの。これならOSC_CLKと同期もとれる。

反面ソフトウェアを修正してそれらの変更を反映した操作を行うようにしないといけない。

Cypressのファームウェアも独特でピンとこないがこちらはアプリケーションの指図に従っているだけなので変更する必要はないかも。

アプリケーションの方のソースを見るとなにやらbad_dataを０クリアとかしているのでこの変がもともと怪しいのかもしれない。どうやってもトリガーポイントから以前のサンプルデータが０にリセットされているのはおかしい。

カメレオンUSB+ロジアナ用のISEデザインプロジェクトをオプティマイズのサイトからダウンロードして中のVHDLソースを見てみた。

見てみたところで入出力仕様とかドキュメントがあるわけでもなくタイミングチャートも無いので途方に暮れる。

VHDLソースを読んでリバースエンジニアリングするしかない。

昔本職のLSI設計者の人が言っていた「他人の書いたRTLの動作を調べるにはシミュレーターで動かして波形を見るの一番」というのを思い出した。当時はシミュレーターを使える立場でもなかったのでしかたなく机上でVHDLソースを追っかけていたが確かに正確さには欠けるし大海の荒波に飲まれるのがおちだった。

ソフトウェアの場合には性質上モジュール単体で動作させるというのがやっかいということもあってもっぱら机上で読むのが一番。なにぶんやっていることはメモリとデータの操作が主体なので時間軸上でどうのこうのというのは関係ない。最後にどうなるかが問題だしハードウェアよりはかなり読むのが易しい。

今回はシミュレーターを使ってカメレオンUSBのロジアナのデザインの動作を調べてみることにする。

とりあえずOSC_CLKに100MHzのクロックを入れておけばいいのだろうとテストベンチを作成。

早速動かしてみるとRAM_CLK以外は波形が変化しない。サンプリングを開始するには別の入力信号を与える必要がありそうだ。見るとST_STPというのがある。これをHに固定してやってみるとRAM_ADDがカウントアップし始めた。どうやらこれでサンプル開始らしい。

あとはトリガー条件を与える。デフォルトではPROBE00の立ち上がりなので適当なところでPROBE00をHに立ち上げておく。それでずっとシミュレーションを続けるとRAM_ADDが0でサンプリングが停止するのが確認できた。

VHDLのソースを見る限りトリガー条件が成立するまではRAMに再クリックにサンプルデータを格納しているので本来であればトリガーPOSITIONがCENTERやLASTであればトリガー位置より以前のサンプルデータも読み出して表示されるべきである。トリガー後継続してサンプルする長さはトリガーPOSITION設定によって変わるようになっている。

CPLDとしてはそれができるようになっていることはシミュレーションで確認できた。あとはRAMを読み出しているカメレオンUSBのファームウェアかWindows上のロジアナソフトの問題ということになる。

ひとつデザイン上で気になるのがサンプリングをST_STPをLにすることで停止させた場合、RAM_ADDも0リセットされてしまい最後RAMのどまで書いたのかわからなくなってしまう点である。マニュアルでサンプルを停止させた場合には問題なような気がする。



よく見えないけどトリガー発生後にマニュアル停止した場合の波形。RAM_ADDが0リセットされているので最後に書き込まれたアドレスがどこだかわからなくなるという証拠。

今になって気づいたのだが、カメレオンUSB+ロジアナのソフトでトリガPOINTがTOP/CENTER/LASTを選択できるのだが、どれを選択しても共通してトリガポイント以降の信号しかサンプルされていない。Coolrunner-IIに万年時計のデザインをダウンロードして動作確認に使った時に初めて気づいた。

普通はトリガ発生するまではずっとサンプルし続けていてトリガがかかってからどれくら継続してサンプルするかの違いだと思っていたのだが違うようだ。

もう一度オプティマイズのWebの説明を見ると、どうやらトリガがかかってからサンプルを始めるようでその長さが違うようだ。

だめじゃん（´Д｀；）

CPLDのデザインソースを調べてみないと確証はないが、MyLa.exeを使っても同じ結果なのでたぶん間違いないだろう。

ソフト側の問題だとするとやっかいだな。普段使っているMyLa.exeのソースは非公開だ。

そういうものだと割り切ってこないだ買ったHPのロジアナを使うしかないのかも。安くて小さくて簡単でいいんだけどねカメレオンUSB+ロジアナは。

FLEX10K10のIDCODEを読み出した時の波形は以下の通り。



LSBからMSBの方向に32bitのデバイスIDコードが繰り出されてきている。

拙作のプログラミングケーブルは時々JTAGでエラーが出ることがあります。

得にIRスキャンでエラーが出ます。IRスキャンがエラーでもMIROUJTAGトラ技評価版は決め打ちのIR長でIDCODE命令をセットするのでIDCODE単独のスキャンはできたりします。

IRスキャンで時たまエラーを起こすので、繰り返しIRスキャンを行わせて失敗した時と成功したときのロジアナの波形を比較してみることに。



上が失敗した時、下が正常の時。正常ならIRデフォルト値としてLSBから順に1010101010の10bitがTDOに出てくるのが観測されます。失敗時にはどうやら最初と最後がうまくデータが出てきていないようだ。原因としてはTCKの立ち下がりでのIRシフト動作が時々抜けていることが想像される。基本的にはTCKの波形の品質によるものだろう。

MITOUJTAGトラ技評価版はMAXII CPLD基板に特化しているのでIRスキャンもMAXIIの固有値が出てくるのをチェックしているだけで汎用的なIR長検査とかはしてないようだ。なので10bit繰り出させてその内容が期待しているパターンと合致していれかだけチェックしている。

MAX+PLUS IIやQuartus IIそれにJam STAPL Playerなどは汎用なのでIRに1を繰り入れてそれを読み出してレジスタ長を知る操作をしているので大変長い処理になる。100MHzのサンプルだと観測できる時間は限られるので少し間引きしないと全部入りきらない。それにソフト処理が入るので間が開いてしまう。

一連のJTAG操作のシーケンス中で途中だけ観測したい場合には単純なトリガーではだめで、時間軸上で現れるシリアルパターンでマッチングをとらないとだめだ。

あらかじめ買い置きしてあった浅草ギ研の信号伝達コネクタとICクリップをケーブルでつないでプローブケーブルを作成。



なかなか良い感じ。

さっそく拙作プログラミングケーブルを自作FLEX10K基板につないでMITOUJTAGトラ技評価版でのIDCODE読み出しの動作を観測してみることに。その際にロジアナで観測する信号とかは右クリックメニューで任意に追加や削除それに名前の変更とかができることを発見。かなり使い易い。



ちょっと見た限りではIRの内容をIDCODE読み出しコードにupdateしてIDCODEレジスタをスキャンしている様子が見てとれる。

これはなかなか使えそうだ。