なひたふJTAG日記

Vivadoでは自分で作ったIPコアが薄い水色の四角になってしまって面白みがありません↓

ここに好きな絵を出せたらどんなに素敵でしょう。

その方法がわかりましたので紹介します。

まず、Edit in IP Packagerで子IPを開きます。

ここでは、以下のおでんの画像を貼り付けることにします。サイズは1024×768です。

IPコアのソースがあるディレクトリ(component.xmlのあるディレクトリ)に、表示させたい画像ファイルを置きます。JPGでもPNGでも構いません。

Vivadoの子IP画面で、Package IPタブを開き、File Groups→Advancedで右クリックし、Add File Groupを行います。

ダイアログが開くので、一番下にあるUtility XIT/TTCLを選びます。

Advancedの下にUtility XIT/TTCLというグループができるので、右クリックしてAdd Filesをします。

用意しておいた画像ファイルを追加します。

次のダイアログではそのままOKを押します。

追加したファイルのタイプがimageになっているので、

ここをLOGOに変更します。

Review and Packageを開き、Re-package IPを行い、閉じます。

Vivadoは更新されたことを認識するので、Show IP Status→ReRun→Upgradeの手順を行います。

すると、コアのアイコンに絵が貼りつきました。絵の大きさを基準にIPのサイズが決まるのですが、1024×768だとちょっとサイズが大きかったようです。

そんなときは、ブロックの角をつまんで引っ張れば、大きさを調整できるようです。

いろいろ試してみたところ、PNGとJPGファイルはOKでしたが、アニメーションGIFはだめでした。

また、いらすと屋さんあるような透過PNGのファイルは、透明色の部分が透けて薄水色の部分が透けてイイ感じになりました。

こんな、他社には真似できない特殊な電子回路になりました。

皆さん、ぜひ任意アイコンを貼り付けて、楽しくって特殊なBlock Designにしちゃいましょう！！

Digikeyからの国際便にはいままでUPSを使ってきました。

UPSは速いときには速いのですが、日本での通関が正午を過ぎるとその日のうちには配達されないという欠点があります。それは、12時を過ぎるとトラックが出てしまうからですが、こればかりは運なのでどうしようもできません。

先週の金曜日15日の夜（日本時間では16日土曜日の未明）に、Digikeyに部品を発注しました。

Digikeyはアメリカの時間で15日(金)の夜にUPSに荷物を引き渡し、16日(土)の未明(現地時間)にアラスカに到着しました。

本来ならば16日(土)の朝、アラスカを発って17日(日)の朝には日本に到着するはずなのです。日付変更線を超えるので4～5時間くらいで到着ｓるのでしょう。

しかし、今回のフライトは違いました。

なぜかLouisvileに戻っているのですが、おそらく本当に戻ってはいないと思います。UPSに電話して確認したところ輸出許可が下りなかったということですが、さらに悪いことに「UPSは月曜・火曜はアラスカから日本に飛ぶ飛行機がない」ということで到着は水曜日になるとのことでした。

月曜・火曜はアラスカから日本に飛ぶ飛行機がないというのが謎ですが、本当にアラスカで足止めされているのがわかります。

そして水曜日の11時ごろに成田に到着したのは良いのですが、通関が済んだのが12:40となっているため、その日のトラックには乗りませんでした。そのため本来は月曜日に届くはずの荷物が木曜日に届くという、UPSの輸送網の中で3日もロスする事態となったのです。

問題は2点です。

• Digikeyに金曜日～土曜日の朝に注文し、アラスカからの輸出に失敗すると２日ロスする。
• 12時を回って通関すると翌日の配達となる

こればかりはユーザ側からはどうやっても制御できないのですが、最近、DigikeyはUPSとFedexを選べるようになりました。

そこで、試しにDigikeyに発注する部品を2つに分け、UPSとFedexでほぼ同時に注文してみました。

まず、21日(木)の未明(日本時間)にDigikey＋UPSで注文しました。

アメリカではまだ前の日の昼ですが、現地時間で木曜日の午前にはアラスカに到着しています。そこから４～５時間程度で成田に到着し、金曜日の11:17に通関（空港上屋スキャン）しています。これは金曜日に届きました。注文を入れてから約34時間後の配達です。

一方、Fedexも同じような時間に出発して、11:25に通関というほぼ同じような輸送時間でしたが、アラスカを経由していないように見えます。

Fedexもおよそ32時間後に配達されました。

今回の発注はどちらもExceptionが起こらなかったのですが、UPSもFedexも、通常どおりの運行予定であればどちらも同じような時間に配達されることが確認できました。

Fedexの記録にはメンフィスから成田の間にアラスカが書かれていないのですが、メンフィスと成田を結んだ直線上にアラスカがあるので、本当は経由しているのかもしれません。

これから冬本番になってアラスカの天候が荒れたきに、どちらが安定して輸送してくれるかを調べてみたいと思います。

ET/IoT2019に行ってきました。

感想を一言でいえば、凋落感。

落ちぶれてすまん、という感じでした。

いつのまにか「過去最大規模で開催」のキャッチコピーもなくなり、ETフェスタの日なのに人も少ない。

かつては６コマ８コマ取っていた会社も２コマや1コマに減り、出展そのものを取りやめてしまった会社も。

会場全体を見まわしても尖ったボードがない。

ようやく緑色の四角い板を見かけても、産業用CPUモジュールという名のいわゆる組み込み用のパソコンだったりして、ここだけにしかないようなワクワクするような面白い物はない。

それでも基板を出しているだけまだましで、基板や機械を出さずにパネル展示とパンフレットだけだったりするところも多い。

日本の開発会社の多くは、毎年同じようなものを作っていて、一言で言ってしまえば「その会社の得意とする分野で顧客からの要求で作ったものを一般化して自社商品として売っている」のでしょう。だからワクワク感や目新しさが皆無。

一方、ギラギラとした目で自社製品の熱烈に説明してくれるのは、中国や台湾の企業。

日本、大丈夫かな。

認めたくないけど、日本より中国台湾のほうが活気がある。

本当に認めたくないけど、認めざるを得ない。

このままだと半導体メーカーさんも、世界の2%しかいないマイナー言語である日本語ドキュメントを用意してくれなくなるかもしれない。

元上流階級でプライドだけは高く、正面だけ立派なスーツで後ろが裸というびんぼっちゃまのようになりかけていないか。

10年前のETは本当に楽しかった。

かくいう私も２年前から出展していません。

私も、組み込み業界を盛り上げていきたいけど、できるかな。

とにかくFPGAやCPUで面白く、新しいことしなきゃね。

RTLを語る会16に参加してきました。

まず気になったのは、ReGenというコントロール・ステータス・レジスタを自動生成する話。Excelの表からVerilogのコードを出力してくれるのは便利そう。

一番気になったのはひでみさんの、RISC-Vをデバッグする話。

デバッグのコアにはOpenOCDを使い、JTAGケーブルはFT2232で、ユーザインタフェースはVSCodeのプラグインを作ったとのこと。RISC-Vのデバッグ仕様書を読んでデバッグ関係のレジスタをちゃんと実装すれば動きそうですね。これはぜひ試してみたい。

調べてみたらOpenOCDはARM7、ARM9、XScale、Cortex、ARMv7、ARMv8だけではなくRISC-Vにも対応しているようですね。OpenOCDのソースを見てみると、確かにデバッガのコードらしきものがあります。足回りもJ-LinkやSegger、ST-LINK、CMSIS-DAPなどいろいろなUSB-JTAGに対応している。うーむすごい。

一方、MITOUJTAGのCPUデバッグ機能は、ARM7の他は、MIPS、SH2、SH2A、SH4、SH4A、RX62くらいにしか対応してこなかったので、このOpenOCDのCPUデバッグ対応品種は魅力的に映ります。

しかしながら今からARMv8アーキテクチャとかCMSIS-DAPとか勉強するには時間がないので、MITOUJTAGからOpenOCDに接続して、うまいことデバッグ機能を拡張できないかどうかを考えることにします。

つまり、OpenOCDの上位にあるコマンドの受け付ける部分をMITOUJTAGからリモート接続して発行し、OpenOCDの足回り -JTAGケーブルの部分- を追加してMITOUJTAGに制御を戻して操作するというわけです。これならOpenOCDの豊富なCPUデバッグ機能を、MITOUJTAG経由で操作できるようになるはずです。

CPUのデバッガは逆アセンブラを内蔵させるのがとても大変だったのですが、うまいことgdbとも連携し、VSCodeとも連携させれば、RX、SHから最新のARMまですべてに対応したデバッガができるんじゃないかなと妄想しています。来年時間があれば試してみたい。

Cosmo-Zの16bit版を作り、その設計をISEからVivadoへ移行しました。

今回のCosmo-Zはトリガボード付きです。

ADCの分解能を12bit、14bit、16bitと切り替えるには上の赤で囲ったVivadoのコメントの部分を書き換えればよいようにTCLスクリプトを組みました。

125MHz 16bitだとAD変換結果は完全には止まらず、下の図のような正規分布となります。

1LSBが30μVで半値幅は7LSBくらいなので、入力換算ノイズはざっと210μVppとなります。

正弦波を入れたときのスペクトラムを見ると、極めて綺麗で、高調波などは見当たりません。

歪率は-80dB以下といってよいでしょう。

Cosmo-Zの16bit版は原価がすごくかかるので、失敗すると大きな痛手となります。これまでのところCosmo-Zは100台ほど作りましたが、
実装屋さんが良いのか、こんなにたくさんの部品があるのに実装ミスは0です。今回も十分満足な性能に仕上がりました。

ZYNQのスタンバイモード時に何が起きているかを詳しく調べてみました。

まず、JTAGバウンダリスキャンを使ってUARTとDDR3の信号を見たところ、/sys/power/stateドライバを操作されてから実際にスタンバイするまでの時間は150msくらいと推定されます。復帰はさらに早く数十ms以内でした。

Linuxのコンソールに戻れるので、完全にシャットダウンするよりも圧倒的に早く戻れます。

スタンバイモードでは、DDR3の信号はRAS=L、CAS=L、WE＝H、CS=H、CKE=Lで停止しているようです。

気になるのはPLも一緒に停止しているかどうかです。

PLが停止してしまったらEMIOを通したUARTからの復帰ができないのでそんなことはないと思うのですが・・

念のため、PLから各部のクロック信号を出してみたところ、MMCMを経由したクロックは停止していて、それ以外のクロックは極端に遅くなっていました。

実際にオシロで測ってみると、PSからPLへ送られるクロックが100MHzのものは3.33MHzになり、250MHZのものは8.33MHzになっていました。

スタンバイ前↓

スタンバイ後↓

つまり、FCLKが30分の1の速度になってしまっているのです。3.3MHzではMMCMはロックできないから動作を停止したのでしょう。

結論を言うと、

• スタンバイモードにしてもPLは停止しない
• PSからのクロックが怪しくなるので、PSクロックを使わない設計にするべし
• 当然ながらPLからもDDR3メモリは使えないと心得るべし

です。

PSが動いていることが確認できたので、例えばEMIO経由のGPIOで起こすようにしておけば、CPUは常にスタンバイモードにしてPLだけで計測しておいて、1分ごとにCPUを起こしてちょっと統計とか通信をしてまた眠るというアプリが作れそうです。

ZYNQを使った高速ADCのシステムを特注で作っていて、消費電力を半分しなければならないという課題に直面しました。

ADCや周辺回路の消費電力を細かくチェックして、あとはZYNQ自体の消費電力をどこまで減らすことができるかという先の見えないチャレンジとなりました。

ZYNQ自体には各部のクロックを止めたりしてこまめに消費電力を削減する機能はあるようなのですが、究極的にはWFIという命令を実行してスタンバイモードに入れるのが最強のようです。たどり着いたのがXILINX Wikiのページです。

ユーザアプリからWFI命令をいきなり実行するのではなく、ZYNQ版Linuxには最初からパワーマネジメントの機能が入っているようです。

使い方はとても簡単で、

echo mem > /sys/power/state

とやるだけです。

ここでmemって何？と疑問に思うでしょう。この/sys/power/stateというのはデバイスドライバになっていて、可能な引数にはmem、standby、diskの3つがあるようです。standbyというのは単純に低消費電力モードに入るもので、diskはノートPCのハイバネーションモードのようなものだそうですが、ZYNQではサポートしていません。

3つの引数のうちZYNQでサポートしているのはmemだけで、DDR3メモリが停止してPSがスタンバイモードに入ります。DDR3は停止するのでプログラムをOCMに退避してからスタンバイモードに入るそうです。

下の図はmem、standby、diskの3つの低消費電力モードを試してみた結果です。

スタンバイモードからの復帰にはUARTによる方法と、GPIOによる方法、デバッガによる方法の3つがあります。

何もせずに使えるのはUARTによる方法だと思います。やり方は、

echo enabled > /sys/devices/soc0/amba/e0000000.serial/tty/ttyPS0/power/wakeup

をあらかじめ実行しておくこと。これだけです。

その後、

echo mem > /sys/power/state

で、ZYNQはスタンバイモードに入り、何かキーを押すと復旧します。

どのくらい消費電力が減ったかといえば、大本の5V電源で890mAあった消費電流が560mAに減りました。約1.6Wの電力削減です。PSが完全に停止するのと、DDR3メモリを止めるのでこれくらいの削減ができるのでしょう。

DDR3メモリの内容を安全に退避しているはずなのですが、スタンバイに入るのも復帰するのも一瞬で、復帰したら何事もなかったのように計測が続きました。

スタンバイに入るときと出た後でFPGAがどう動いているのかをMITOUJTAGを使ってみてみました。

驚くべきことに、スタンバイ中でもJTAGバウンダリスキャンは動きました。

で、復帰するとすぐに元の動作に戻るはずなのですが、どうやらディゼーブルにしていたADCのチャネルも復旧しています。

スタンバイ中にPLがどうなっているのかは、もう少し解析したほうがよいかもしれません。

☀

なお、Linuxのカーネルを構築する際に

• CONFIG_CPU_IDLE
• CONFIG_CPU_IDLE_GOV_LADDER
• CONFIG_CPU_IDLE_GOV_MENU

というオプションを有効にしておけばcpuidleドライバが働いてIDLE時にWFI命令を実行して低消費電力モードに入るという情報もありましたが、全く効果は実感できませんでした。

実装の上がってきたCosmo-Zをアクリルケースに納めました。

アクリルの保護フィルムはもったいないので剥がしていません。出荷時にはがすことにします。

どういうわけかFANが在庫切れだったので、FAN付きはとりあえず1台のみです。

今回はトリガボードを装着した状態でフロントパネルを閉じられるよう、トリガボード用のフロントパネルも設計しました。