自作CPUで遊ぶ 9

定年になって再雇用社員になったというのに何故か仕事がめちゃくちゃ忙しい。給料はほぼ半減したのに下手したら定年前よりも忙しい。先日は仕事帰りに急に喉がヒリヒリ痛く微熱も出てきた。職場で高熱で休んだ人がいるという話も聞いていたので、これはいよいよ私も何かに感染したかしら？とか思ったのだが一晩寝たら回復した。かなり疲労が溜まっているので免疫力が低下しているのかも知れない。 こんな時は好きことをやって気分転換だ。…やってることは仕事とあまり変わっていない気がするが…　全部、自分の思い通りに・好きなように・作りたいものを作る。というのが気分転換になる。 

さて、今度はステッピングモーター（パルスモーター）を制御して見たくなってジャンク箱からモーターを出して来た。 パルスモーターの制御を習得したいなーと思って集めていたら、いつのまにか沢山所有してしまった。 ここに写っているのはその内の一部だ。

モータードライバはDM556Dというやつを使うことにした。これもいつかこれで遊ぼうと思い数年前にAmazonで購入して死蔵していたやつだ。 回転させるだけならHDDのスピンドルモーターと同様の方法で良いが、位置決め制御等もやってみたいので今回はこれを使うことにした。

なので、FPGAからはEnable、Dir （回転方向）、Pulseの３種の信号をDM556Dに与える。

7年位前にCNC4030Zという中華製のCNCを購入した。今はまったく使っていないがまだ所有している。 この装置のコントローラはI/Fが古く、PCのプリンタポートと接続する必要がある。また制御するソフトウェアもWindows95用のものなので今動かすの色々と難しい。 最終的には、コントローラと制御ソフトウェアを自作してこれを動かしたいと考えている。これで最高４軸迄は制御してみることが出来る。

とりあえず、普通に回転させてみた。プログラムはHDD用スピンドルモーター用のやつをベースに若干手直しして使った。 とても容易に回せた。このモーターの場合、回転数は9000 [rpm]が上限のようだ。

自作CPUで遊ぶ 8

前回のデザインをベースにしてCPUをMicroBlazeに変えてzumi32版との違いを色々と見てみた。MicroBlazeの設定はzumi32と同等にするために乗算器等は入れずにBarrel Shifterのみとした。

このデザインでImplementしUtilizationを見てみた。MicroBlazeの部分はSlice LUTsが1053だった。これに対してzumi32は1066と同程度の規模だった。但し、規模は同程度だが内訳はかなり違う。レジスタ数は770(MicroBlaze)に対して512(zumi32)。LUT as Logicは851(MicroBlaze)に対して1022(zumi32)。LUT as Memoryは7(MicroBlaze)に対して0(zumi32)。zumi32はF/Fをあまり使っていない。これが動作速度を上げられない要因なのかも知れない。

次に前回と同等のプログラムをMicroBlazeに実装し、生成されるコードの規模や処理速度を見てみた。コンパイルされたelfのtext、data、bssのサイズはそれぞれ 1588、276、3112だった。 これに対して、zumi32はLinkerが出力したmapファイルから各セグメントのサイズを見ると、textが0x284 (644)、dataが0xc (12)、bssが0 とかなり違う。textは約1KByteもの開きがある。最適化オプションは何れも-O2にしている。

MicroBlazeのelfを逆アセンブルしてmain()の部分を見てみた。命令数は31なのでかなりコンパクトだ。これで何故text sizeが1.588Kバイトになるのか謎だが、もしかするとstartup部や例外処理などのコードが大きいのかも知れない。 1KByteは１命令32bitなので命令数にして256命令分。。小規模なFPGAにCPUを実装する場合等は結構厳しいサイズかも知れない。

一方、zumi32をコンパイルして得られたアセンブラは以下のようだった。命令数が38もあるが、while loopの部分のみを抜き出してMicroBlazeのコードど比較すると以下のようだった。

zumi32の命令数が多いのは命令セットの違いもあるが、gccをzumi32にportingした時の私の工夫が足りていないのが要因だろう。 zumi32は遅延分岐があるが遅延スロット部をnopで埋めている。最適化の部分をもっと工夫すればMicroBlazeと同等にはなる筈だ。ちなみに手動で最適化すると命令数は14まで削減できる。

次に、それぞれのデザインとプログラムでXsimでsimulationしてwhile loopを１回実行する時間を見てみた。zumi32のプログラムはgccでコンパイルしたコードをそのまま使った。 上がzumi32、下がMicroBlazeの波形だ。MicroBlazeが11.37usecに対してzumi32は18.31usecと1.6倍も遅い。上で見たとおり命令数の差はあるが19:22なので1.15倍程度の差でしかない。したがって遅い要因は命令数の差だけでは無い。

速度を遅くしている要因はload命令のlatencyと分岐時のfetch unitとexecution unit間のlatencyにあった。そこでそれらを修正し、且つzumi32のコードを手動最適化したコードに入れ替えて再度simulationをしてみた。 その結果、while loop１回の処理時間は10.1 usecまで短縮することが出来た。

MicroBlazeより約12%速くなった。但し、手動で最適化したコードを使った場合なので現状のgccを使い続ける限りはMicroBlazeと同等になるんじゃないかな？と思う。 

前向きに捉えるとzumi32-gccにはまだまだ伸びしろがある。！！！ってことだが。。。これを改善するのは大変なんだよな。 portingに数年を要したからなー。

まぁ・・・、でも 最小構成とは言えベンダー製のCPUの性能にかなり近づけているというのは嬉しいことではある。

自作CPUで遊ぶ 7

外では鈴虫が鳴き始めている。酷暑も少し和らいできているが残暑はまだまだ厳しい。去年から私の部屋のエアコンが故障していてまったく冷えない。今年も在宅の時は部屋の温度は平気で３６℃に到達していた。今この瞬間も32℃もある。まぁでももう少し辛抱すれば涼しくなるんじゃないかな。

さて、今日はモーターからちょっと離れて別のことをしてみた。

zumi32にAXI Master I/Fを付けてVivadoのIPを接続できるようにして見た。私はIPは可能な限り自作する派でベンダー製のIPはできることなら使いたくないと思っている。また、趣味で遊ぶ分にはそれで十分というのもあるのだが、ふと思い付いて zumi32にAXI Master I/Fを付けて見たくなった。 AXIにはPeripheral I/Oを接続することを考えていて、主記憶となるMemoryの接続は考えていない。そのためアクセスはシングルアクセスのみになるのでAXI-Lite相当のAXI-I/Fにした。それにAXI-Lite-Masterなら簡単にサクッと作れる。

以下のようなブロックデザインにした。AXI-GPIO２つとAXI-Timerを接続した。プラットフォームはCMOD S7を使っているので、それに実装されているカラーLEDと４つの単色LEDをそれぞれ別個のGPIOで制御できるようにした。

このデザインでまずはLEDを点滅させるプログラムを書いて実行してみた。以下はプログラムとBSPだ。

実機にダウンロードして動かしてみた。

   

普通に動いた。

これが出来るとAXI-I/Fを持った色々なIPを簡単に接続してシステムを構築できるってことだよな。

自作CPUで遊ぶ 6

手持ちのモーターの内どれが一番高速に回せるか見てみたら下の写真の左上のやつが一番高速に回せた。 これを無負荷（円板とか何も付けない状態）で回してみたところ 45000 [rpm]まで回せた。電源電圧は通常は5Vにしているがこの時は12Vにした。5Vだと27000 [rpm]位が上限だった。zumi32のプログラムは基本的に前回と同じで、回転数の上限だけを変えた。

次に磁気ディスクを装着して回してみることにした。そしたらこれまでと全く様相が変わりαx^4の制御曲線では回せなくなった。負荷が重くなったためと思う。モーターを脱調しないで起動出来る回転数の上限は無負荷時は300[rpm]位だったのだが、これが60[rpm]、つまり 1 [rps]になった。また制御曲線は一次式のαxにする必要があった。αの値は0.01になった。この曲線での回転数の上限は10500 [rpm]だった。（電源電圧は5V）　ディスクが重いので慣性力（イナーシャー）が大きく、駆動を停止してもディスクの回転がなかなか下がらない。 当然だがこのディスクは偏心していないので高速に回しても音はそれほど大きくならない。

負荷の有り無しで結構違う。勉強になった。 

Youtubeに壊れたHDDを改造してディスクグラインダーにする動画があって、ウソクセーと思っていたのだが、これくらいのイナーシャーの付き方ならもしかしたら出来るのかも知れない。

自作CPUで遊ぶ 5

これまでのプログラムは１個のタイマーを使いタイマー割り込みハンドラ内で割り込み周期を段階的に変えることでモーターの駆動パルスを作っていたので制御が粗くなってしまっていた。 そこで今回はやり方を変えて、タイマー割り込みの周期は一定とし代わりにモーター制御用のパルス生成器を作ることにした。

パルス生成器の構造はシンプルにアキュムレータ方式とした。アキュムレータを acc とすると、accは毎クロック acc = acc + αで更新される。また、acc が閾値 N を超える場合は0に戻す。この時パルスが１つ出力される。下図はaccのαが1, 2, 3の場合のaccの軌跡を表している。現在回路は100MHzで動かしているのでNは100_000_000に設定する。すると、αが１の場合１秒に１回パルスが発生し、αが２の場合１秒に２回、αが３の場合は１秒に３回発生する。つまり、αはパルスの周波数を設定することになる。今回のモーターの場合パルス１２発で１回転するので、モーターの回転数を RPS (Rotate Per Second)で表すとするとαは 12×RPS になるがこの変換はIP内で行うことにした。つまり、ソフトウェアは秒当たりの回転数を何らかの方法で算出して設定すれば良い。

次に回転数の生成だが、前回採取した波形から起動時の立ち上がりの部分（左下の緑色の曲線）を式化してそれを使って回転数を決定してみることにした。

色々試してみた結果、y = ax^4、a = 1.97499e-11 を使うことにした。 多項式にすると計算に時間が掛かるのでなるべく単純な式にした。タイマーの割り込み周期は1msecにして、割り込みハンドラで y = ax^4 でモーターの回転数 RPS を計算してIPに設定する。 aの値が1.97499e-11とかなり小さいので固定小数演算にすると32bitを超えてしまう。そこで計算はfloatで行うことにした。zumi32-gccはfloatも使えるのでfloat演算自体は問題ないが、zumi32の演算用リソースとしてはバレルシフタのみなのでコンパイル後のマシン語のステップ数と演算に要する時間が気になるところだ。 そこで、コンパイルしたマシン語列をシミュレーションで流してみたところ、割り込み処理時間は約28usecであることが判った。タイマー割り込み周期は1msecにするのでまったく問題ない。（シミュレーションではタイマの割り込み周期は50usにしている。）

で、これを実機で動かしてみたのだが結果はNGだった。起動直後に脱調してしまう。aの値を小さくしたりx^4をx^2にしたりして立ち上がりを遅くすると動くのだが最大回転数は50 [rps]（3000 [rpm]）が上限だった。そこで、モーターのdrv_A, drv_B, drv_Cの駆動パターンを変えてみることにした。具体的には従前は 011、110、101のパターンを繰り返しており常に２つのコイルを励磁するようにしていたのだが、これを001、011、010、110、100、101と１コイルのみが励磁されるパターンを入れることにした。 これにより今までは12パルス＠1回転だったのが24パルス＠1回転になるので、IPの設定値を12倍している部分は24倍に変更した。 この他にaの値を色々調整したりした結果 120[rps]（7200 [rpm]）まで動くようになった。 ヤッタ!! 以下はロジアナで採った波形だ。

Sensorの周期が120Hzなので7200[rpm]で回転していることが判る。

以下は動かしている様子。7200[rpm]ともなると風切り音がすごい。

ということで、zumi32でモーターを制御して7200 [rpm]で回転させることが出来た。また、zumi32のプログラムでもfloat演算を問題なく使えることを確認することが出来た。＼(^_^)／

自作CPUで遊ぶ 4

ジャンク箱を確認したら今回使っている以外にもHDD用スピンドルモーターが５個出てきた。電極は殆どが４極だが１つだけ３極の物があった。電極間抵抗を測ると全て同じ値なのでコイルはデルタ型の接続になっているんだろう。

コイル抵抗は全部違っていて（多分品種毎に異なる）、Nidecのが1.8Ω、JVCのが1.6Ω、CAO*が3.3Ω、JBY*が1.2Ωだった。これらはコモン端子とその他の端子間の抵抗値なのでコイル１個の抵抗値だ。また、デルタ型の電極間抵抗は2.8Ωだった。デルタ型の電極間は Rと2R の並列回路として見えるのでR１個当たりに換算すると、2.8Ω = r // 2r = r(2/3) → r = 2.8 (3/2) = 2.8 * 1.5 = 4.2Ω の筈だ。抵抗値が大きいということはコイルの巻数が多いことを意味するのか？もしそうなら抵抗値が大きい方が回転数も大きいかも知れない。。。(ホントか？）　後で動かしてみようと思う。 モーターの駆動波形と実際のモーターの回転数を見たくなったのだが、所有しているデジタルオシロスコープは２CHでCH数が足りないのと、ちょっと測定結果をグラフ化したりしたかったのでロジック・アナライザーで測定することにした。このロジアナは2014年にこのブログで開発したもので、Lattice社のMachXO2-7000評価ボードにロジアナの自作IPを実装した。アクイジションメモリとして16MBのSDRAMをウラ面に無理やり実装している。（以下は当時撮影した写真）

SDRAMは150MHzで動かしている。これに対してロジアナはCH数24、サンプリング速度は100Mspsなので一見スループットが不足するように見えるが、このロジアナは取得したデータをValue Change方式でSDRAMに格納する。この方式はデータ圧縮の効果があり（詳細は当時のブログを参照） 圧縮の程度はデータの変化率に依存するが常にサンプリング周波数に近い速度で変化する信号を測定でもしない限りはまあまあ使える。 　このロジアナで使用した評価ボードはLH2232HLを搭載しておりPCとはこれを介してUARTで通信する。UARTは8Mbpsで動かした。また、この後にMachXO2-7000搭載のFPGAボードを自作しこれにもUSB I/F用にLH2232HLを搭載したがFPGAとは非同期FT245モードでも通信出来るようにした。 このモードは非同期8bitパラレルでデータをやり取りするので測定データのアップロードを高速に行うことが可能であり、実際UARTモードよりも6.7倍程度高速に転送できた。今回はモーターの起動からSDRAMの最大容量までデータを取得したい。そのためアップロードするデータ量も多くなるので上記写真の機体ではなく後者のFT245モードが使える方のボードを使用することにした。

モーターの回転数はフォトインタラプタを使って測定することにした。具体的には１箇所穴の空いたボール紙で作った円板をモーターに貼り付け、この穴をフォトインタラプタのスリットに通過させた。

ロジアナの制御は専用のGUIアプリで行うが、久しぶりに起動しようとしたら使っているwxWidgetsのライブラリのバージョンが古すぎて起動しなかったため wxformbuilderでGUIを再編集・生成してビルドし直した。信号はモーターの駆動信号（drv_A, drv_B, drv_C）とフォトインタラプタの信号（Sensor）を採取した。 SDRAMを全領域使って起動時から11秒程度の期間のデータを取得できた。単純に100Mspsの速度でデータを取得した場合、(4*1024*1024)/100e6 ≒ 42msecの期間しか採取できないが、上述の圧縮効果により260倍の期間のデータを取得出来ている。

このGUIアプリには波形の表示機能は無い。その代わりVCDファイルを出力するのでこれをGtkWave等を使って波形表示を行う。以下は取得した信号の波形だ。モーターに貼り付けた円板の穴は１つだけなので１パルス/１回転発生する。従って、このパルスの周期を測れば回転数を求められる。また、前回 drv_A, drv_B, drv_Cに１秒毎にパルスを与えてモータパルス12個で1回転するとしたが、波形からこれが正しかったことが判った。

GtkWaveのExport機能を使って波形データをTIM形式でファイルに出力し、テキストエディタで信号毎のCSVファイルに編集してlibreofficeのcalcに読み込み、回転数に変換してグラフ化した。横軸は起動してからの経過時間、縦軸は回転数 [rpm] だ。 緑色のグラフ(real)はフォトインタラプタの信号から算出した回転数、オレンジ色のグラフ(drive)はdrv_Aの周期から算出した回転数だ。　これを見るとFPGAの駆動に対してモーターの応答に遅れがあることが判る。また、回転速度の上げ方が粗すぎるようだ。モーターの回転数にリンギングのような振動があるのも判る。このリンギングはモーターをちゃんと固定していないのと円板が若干偏心しているのも影響している可能性がある。何れにしろ、測定の分解能が高いのでこの辺の挙動が観測出来ている。なかなか面白い。  … でだ。　どうやったらもっと旨く動かせるんだろう？　この系で測定しながら試行錯誤すれば出来るのかしら？