CAN IPのDEBUG 9

自作CAN IPの実機動作確認の為の準備を進めている。
先日はSpartan3E (XC3S250E)用のRTLを作成したが、
Resourceにまだ空きがあるのでTimerを2つに増やし且つPWM出力もできるように変更した。
PWMの設定要素としては周期とDuty比があるが、
このTimerの場合は周期をTW registerに、Duty比をDUTY registerに設定する。
DUTY registerの設定値は8bit固定小数形式で小数点はbit7-bit6間にある。
つまり設定したい値をduty[%]とすると、設定値DUTY = 128 * duty[%] / 100
Timer用counterは32bitで今回の実装では50MHzで動作させるつもりなので、
周期は最大でおよそ85.9秒まで設定できる。

下図は１周期の設定を100にして、dutyを10%づつ変化させたsimulationの結果だ。



下図はdutyとしてsin(x)の値を入れた場合だ。
（つまり、設定値DUTY = 128*(50+50*sin(x))/100とした場合）


このPWMのDUTYをCAN I/F経由で設定するようにしてLEDの調光やDC MOTOR
の制御等の実験が出来るんじゃないかなと考えている。

合成結果だがNumber of occupied Slicesが97%になった。


通信相手だがInterface誌2011年5月号付属のRXマイコンがCANを内蔵している
ことが判ったのでこれを使うことを考えている。

CAN IPのDEBUG 8

simulationはほぼ終わった。
StateMachineの分岐も100%確認できた。



これでこのProjectを終わりにするのは、あまりにもこの子が不憫なのでちょっとだけ実機で動かしてみることにした。ただし、ちょっとだけ動かすとは言っても実機で動かすとなるとそれなりの構成の物を構築する必要がある。
という訳で、下図のようにちょっとしたマイコン風味の構成にした。



Peripheralとして、zumi32のbusにCAN, I2C, TIMER, GPIO, INTC（割り込みController）が繋がっている。TIMERは32bit 1ch、GPIOはGPI 15bit, GPO 15bitだ。 I2Cは不要な気もしたが、一応入れておいた。 各PeripheralのRegister構成はこんな感じだ。



また、図にはUARTもあるがこれはzumi32の命令のDownload等に使うため、zumi32の支配下には入っていない。 zumi32にはDebug用の回路は入っていないが実行中のPCの値位はこのUART経由で見ることは出来る。
Target FPGAはXC3S250E(Spartan 3E)で、CQ出版社のDesignWave 2007年7月号の付録に付いていたSpartan3E基板を使う予定だ。 XC3S250Eに入るか若干不安もあったが何とか収まった。



下の左側がXC3S250Eの付録基板だ。また、写真手前の3つのICはCAN Transceiver ICだ。



ここまでの環境は出来たがこれだけでは不十分で通信相手を用意する必要がある。

CAN IPを合成してみた

動作検証もだいたい出来てきたので、ISEで合成をしてみた。
入力CLOCKは50MHzで合成したがMetした。



ここまで来ると実機で動かしてみたくなるがどうすっかなぁ？
もう少し検証のCoverageを上げてから考えようか。

CAN IPのDEBUG 7

CANの規格では発振器の許容誤差、つまりCLOCK周波数の許容誤差は最大1.58%となっている。
これに対してBoschのVHDL Reference Modelでは1.7%で評価するようになっている。
今日はこの許容誤差について見てみた。
私のtest benchには自作IPが3つとOpenCoresのCAN IPが1つの計4つのNodeがCAN busに
繋がっているが、自作IPに供給している各々のclock周波数についてNode1を-1.7%、Node3を+1.7%
Node2は±0%でsimulationしてみたところ、正常に通信できた。


CAN busではclockは伝送されないため、受信側は受信信号の切替り部を見て内部で生成しているSampling clockの位相調整を行う。従って例えばIDも0、DATAも0のような信号変化が少ないdataの伝送の場合は位相調整が難しくなってしまうことになるが、CAN規格ではbit stuffingという手法で同じ値が5bit連続したらその反転したbitを1bitその後に挿入して、最悪でも6bit期間に2回は信号の切替りが発生するようになっている。

この波形は上記波形の一部を拡大したものだ。b2t_txenはCAN IP内部で生成している送信用clockでb2r_spenは受信用clockだ。（正確にはclock enable信号）

Node1～Node3はそれぞれclock周波数が違うのでの信号変化が無いと徐々にズレていくが、信号変化があると位相が調整されている。

次の波形は信号が1bit毎に反転する場合だ。

ということで、±1.7%は問題ないことが判った。
では1.8%ではどうだろう。。。simulationしてみた。



ErrorでRetryが起きているようだ。
最初のErrorの部分を拡大してみた。
Reference Modelとして使っているOpenCoresのCAN IPが、CRCが一致せずError Flagを送信している。上記の波形を見るとNode3, Node2の信号の受信には成功しているので、マイナス方向の周波数誤差が許容できていないのかも知れない。



Simulationでこういった点が評価できるのは、面白い気がした。

LatticeECP3 Versa Development Kit

Lattice ECP3 Versa Development Kitを購入した。
まだ、ATLYSでも十分に遊べていない状況だが、このKitはPCI ExpressとDDR3を装備していて
これらのお勉強もしたいと考えていたこともあり、購入できる内に買っておこうと考えた。
定価は$299だが、Latticeのweb storeだと今なら$99（手数料、配送料込みで$145.45)で購入できる。
PCI Express I/F, DDR3 SDRAM, 3.2Gbps Serdes I/F等を装備して、1万円程度で購入できるので
結構お買い得かも知れない。

CAN IPのDEBUG 6

VHDL Reference CAN User's Manualに記載されている検証内容を参考にして
simulationを進めているが、3.2.2 biterrorの各項目についてほぼsimulationできた。
ただし、このManualに記載されている項目は規格と矛盾する箇所もあった。 
Test of transmitterの項目14ではError Passive状態時のreserved bitがdominant
の場合と、Passive Error Flagの先頭でdominantが検出された場合の動作を検証して
いて後者については、
The transmitter detects a bit error and starts sending a Passive Error Flag again.
となっている。 しかし、規格書には次のような記述がある。
A TRANSMITTER sending a PASSIVE ERROR FLAG and detecting a 'dominant'
bit does not interpret this as a BIT ERROR  (ERROR HANDLING / Error Detection / BIT ERROR)
CAN busに繋がっている全てのnodeの状態がError Passiveとは限らず、Error Active
のnodeも存在する可能性はある筈だ。 Error Passiveが出力するPASSIVE ERROR 
FLAGはRECESSIVE、 Error Activeが出力するACTIVE ERROR FLAGはDOMINANT
でこれらが競合した場合はDOMINANTになる。 従って、Error PassiveのnodeがPASSIVE
ERROR FLAGを出力したのにDOMINANTが検出されたからと言って、それは、bit error
とは言えないと思う。従って、User's Manualの記述は誤りだと思う。 ということで、
この部分は無視することにした。
User's Manual記載の項目以外にも検証項目を幾つか追加した結果、Line coverageは
100%にすることができた。

ただし、改めて規格書を読み返してみると、まだまだ検証できていない項目がある。

CAN IPのDEBUG 5

これまでの検証内容についてどうも不安が払拭できないので、BoschのVHDL Reference CAN
User's Manual（ここから入手できる。）に記載されている検証内容を参考に進めることにした。
このbit_errorのTest of receiverの各項目のvectorを作成してsimulationしたところ、
案の定というかやはり、幾つかbugが見つかった。
うーむ、なかなか手強いでござる。

CAN IPのDEBUG 4

今日は、OpenCoresのtest bench及び自分のtest bench用のvectorの結果を総合して、
coveredでline coverageを見てみた。
受信部(can_rxpp)はかなりの部分がcoverできているがまだ、error処理に関連する箇所でcover出来ていない箇所がある。



送信部(can_txpp)はまだ78%しかcover出来ていない。これもerror処理に関する箇所が残っている。



can_errはerror counterを保持しているmoduleだが、こちらも殆ど送信関係部が残っている。


line coverageはRTL記述がsimulationで実行されたか否かを見ている。冗長な記述やRTL simulationでは実行されないような箇所以外はcoverされるべきであるが、全てcoverされたからと言って、回路の正常動作が保証される訳ではない。記述していない部分はcoverしようが無いのであり、仕様解釈を間違ったりして実装漏れがあった場合には、検出しようがない。 そういった部分はOVL Assertion等でcheckして行きたいと考えているが、まだそのcodeは記述していない。（何やかんや言って面倒くさい） CAN I/Fの用途（自動車内部の通信や工作機械の通信I/F等に使われている）を考えると、 このIPの不具合は人命に関わる事故に繋がる可能性も否定できないので、商用として開発する場合には面倒でも徹底的に検証をするべきだろう。 私の場合は今のところ、CAN I/Fの勉強の為に作ってみているというスタンスであり、FPGAにprogramして実機動作確認までやるかどうかも今のところ未定だ。
何れにしろ、もう少し検証を継続しようと思う。