NGから芋づる式にバグが見つかる
ここ最近は論理シミュレーションをしているのだが、
2つのテストから、大量のバグを発見して、一体なんぼほど出てくるんだと思った。
テストの難しさってこういうところにあるんだろうなぁって。
そもそもことの発端は、とあるバグが修正されたこと。
このバグに関連してNGとなっていたテストがOKになったか確認しようと思ったら、相変わらずNGだった。
ただ、NGの出る場所が変わっていたので、新しく発生したNGの原因を探ることにしたのだが……
- 直接のNG要因はテスト条件の誤りだが、その場合の期待値とは一致しない
- その前に実行していたテストでおかしな値が格納されていることが発覚
- 1を修正するついでに、2を洗い出せるテストに修正すると、2の要因でNG
- 仮修正を行い、OKとなることを確認
というわけで、テスト条件の誤りをきっかけにして詳細を調べたら、別の問題もありそうだとわかって、
その問題を顕在化させるテストに書き換えたら、予想通り発生したわけですね。
ここまでなら大した話ではなかったのだが、上記4.の修正を行ったことで別のバグも直ったのでは? と予想した。
起きている現象はやや異なるが、結果として同じ修正で直りそうだと考えたのだ。
でも、実際にはこれだけでは直らなかったし、さらなるバグがどんどん発見されたのだ。
- テストにかかる時間が長すぎるので、リセットを省略するよう修正
- その上で実行すると、当初発見したバグAは直っていないし、別の要因でも期待値とずれてNG
- 想定とやや異なる波形なので、調査すると 既存製品のバグA' と 新規バグBの複合で発生したことが発覚
2.で発生したバグA’を再現するテストを作って既存製品の環境で動かすとNG - 3.以外にも期待値とずれているところがあるので調査すると、エラー発生後に異常な挙動が発生するバグCを発見
1.のリセット省略の結果、顕在化したことがわかった - バグA’を修正して改めて実行すると、バグB, バグCのNGだけ残る
- 5.の結果を見て、エラーレジスタのビット定義に不足があることに気づく(これは保留中)
- バグBの原因を調べると、本プロジェクト初期に行った設計に抜けがあることが発覚
- 7.の解析結果よりバグBを修正
4.の解析結果よりある種のソフトリセット処理を追加すればバグCは回避出来るので追加
これによりバグCは棚上げしてテストOK
と、1つのテストでバグA',B,Cの3つのバグを顕在化させたのだった。
さらに6.に書いたように仕様上の懸念も発見した。実際にはこれでOKな可能性もあるのだが、要確認だなと。
実は上のテストは当初OKだったらしい。ところが後に通すとNGになってしまったのだ。
上記のバグA,B,Cはいずれも新たに埋め込まれたバグではなく、テストOKの時点から存在していたのだが顕在化しなかっただけなのだ。
実はバグBは他のバグとの組み合わせにより、顕在化してなかったらしいんだよね。
そのバグが修正されたことで、バグBが顕在化した。さらに既存製品から存在したバグA’が顕在化した。
さらにテスト時間短縮のためにリセットを省略する変更を行ったらバグCが顕在化した。
実はもともとテストごとに通電時相当のリセット処理をするという非現実的なことをやってたんだよね。
非現実的だし、通電時相当のリセットは所要時間も長いから、こんなの消してしまえと消した。その結果がこれである。
発生条件を調べたところ、実際にそういう状態に陥ったら、ソフトリセットを叩くだろうし、そのソフトリセットにより復帰出来ることもわかった。
本来はリセットなしで復帰出来るように修正すべきだが、とりあえずは現実に合わせてソフトリセットで復帰するという想定に書き直したのだった。
バグが存在していても、それを顕在化させられるかというと、これは難しい。
操作AでエラーXを発生→操作Bを行うとバグが顕在化する というのはよくあるけど、
これを再現するには、操作A→操作Bを行った上で、なおかつ操作Aでエラーを発生させなければならない。
実機でガチャガチャと動かしていて、操作AでエラーXを起こせるなら発見できる可能性もあるのだが……
実は今回、シミュレーションで起こしたエラーというのは、実機で起こすのは極めて難しい。
なので既存製品でも発見されなかったという実情がある。論理シミュレーションで顕在化させなけば発見しようもないと。
実はそういう観点で言うと、バグCはよくシミュレーションで顕在化できたなと思うのだ。
操作Aの準備→操作AでエラーXを発生→エラーレジスタの確認→(リセット操作)→操作Aの準備(リセットを消すとここでバグが顕在化)
まず、エラーXが発生して、エラーレジスタに正しく格納されることを確認するところで終わってはバグが顕在化することは決してない。
このテストでは、パラメータを変えながら操作Aを繰り返し行うテストなので、顕在化させる余地があったのだが、
通常、操作Aの準備には、エラーを顕在化させる操作はやらないんだよね。
ユースケースに従ってテストを書くと、おそらくこんなテストにはならない。
でも、この変なテストのおかげで、リセット操作を消すだけでバグが顕在化できたのだ。
ただし、エラーXの後に、エラーを顕在化させる操作を行わない保証はないので、これはバグではないと強弁することはできない。
あと、テスト条件の誤りをきっかけとして発見されるバグもけっこう多いんだよね。
期待値が不一致となる直接の原因はテスト条件の誤りだが、そうすると別の矛盾が発見され、掘っていくとバグが見つかることもある。
結論から言えば、テスト条件が不足しているということになる。
テスト条件の誤りをきっかけに追加したテストはけっこうある。
過去に作られたテストを実行してOKとなると、それで満足してしまうけど、
NGになると、何がおかしいか詳しく調べるから、矛盾や不足に気づいちゃうんだよね。
そう考えるとOKとなったテストの裏には潜在的なバグがあるのかもしれないが……まぁ優先度は落ちちゃうよね。
Author : hidemaro
Date : 2018/03/23(Fri) 22:56
電気・数学・物理 | Comment | trackback (0)
実は書き込み専用レジスタ
ここのところは論理回路の設計をやっているのだが、
古い設計のモジュールがあって、ある種のマイコンとのインターフェースになっている。
かなり奇妙な設計のモジュールなのだが、それもこれも設計が本当に古いから。
重要性が低く、古い設計のままでも機能的に問題がないということで再設計のタイミングを逸してしまったというのが実情なのかなと。
それで、古くさい設計のモジュールAに関係する新しい機能を実装することになった。
関係する機能なんだから、モジュールAに新たに組み込んだ方がよくない?と提案したのだが、
いろいろな事情があって、他のモジュールの機能として組み込むことになった。
機能の実装ができたので、シミュレーションで動作確認してみようということで、
新機能のユースケースに沿って、テストシナリオを書こうとしたのだが……
そのユースケースはこんなのだった。
- 新しく追加したレジスタに書き込みを行い、新機能を作動させる
- モジュールAからマイコンをリセットする
- リセット解除後、マイコンは新機能へアクセスする
ということで、1, 2と順番にやって、リセット解除時点でマイコンから新機能へのアクセスが想定通りに動くか確認すればよい。
ここで2のリセットのために、モジュールAの関連レジスタ一覧を見たのだが、リセット機能に紐付いたものがない。
でもRTL見る限りはなんらかのレジスタを叩くとリセットできそうなんだけどなぁ。
と思って詳しく見ると、枠外に「リセットは xxxxxxxx番地に0x00をライト、リセット解除は0x80をライトする」という記述があった。
この記述を見ると、レジスタに紐付いていない特定のアドレスに書き込みを行うとリセットできると読めるが、
いやいや、それって書き込み専用のレジスタって言うんじゃないの?
このモジュールを設計した人がそこまで意識していたかは知らないけど、実態はそうだと思うんだよね。
確かにこのモジュールに関連する他のレジスタはどれもリードもライトもできるもので、
それとはかなり違う構造なので、別扱いをしたんだろうなと思ったんだけど、それが不親切だと。
レジスタには読み出し専用のもの、読み書きできるもの、書き込み専用のものがある。
読み出し専用のレジスタは状態を表示するレジスタ、例えばタイマのカウント値を表示したり、外部ピンの入力値を表示したり。
読み書きどちらもできるレジスタは状態の設定に使われることが多い。設定鎮の書き込みと確認ができると。
あと、リセットだけできるレジスタというのもあって、エラーログレジスタとかがそうなんだけど、
エラー発生時に値が設定され、レジスタリードで値を確認し、確認したらレジスタライトでリセットするというような使い方をする。
任意の値を書き込める必要はないレジスタだと、こういうやり方はよく行われている気がする。
こういうのはわかりやすいのだが、書き込みしかできないレジスタというのは特殊だよね。
値を書き込んだのに、リードしても書き込んだ値が確認出来ないということで、ちょっと不思議なレジスタだ。
このシステムでの書き込み専用レジスタの代表例がリセットレジスタだ。
マジックワードを書き込むとリセットが行われるようになっている。
書き込みだけできて読み出しができないのは、現状態を確認できる必要がないからだろう。
読み出せるようにしたところで、マジックワードを書き込む→リセット発生→リセット完了後にマジックワードが自動的に消える ってなるだけでしょうから。
というわけで、この問題提起をきっかけにして、モジュールAのリセット機能は書き込み専用レジスタという形で仕様書に記載されることになりそうだ。
xxxxxxxx番地にリセットレジスタがあって、このレジスタは書き込み専用で、7bit目が0のときリセット、1のときリセット解除という形で書かれるのかなと。
もともと書き込み専用レジスタだと思って作り込まれていないのでちょっと怪しい造りなのだが、
外部仕様としてはこれがわかりやすいでしょうからね。
Author : hidemaro
Date : 2018/03/15(Thu) 23:24
電気・数学・物理 | Comment | trackback (0)
タイミングがちょっと変化したらNG
最近、以前の開発で実行していた論理シミュレーションを開発中の製品に移植して実行している。
何も手を入れずに動くものもあるし、信号名などの変更を反映させればそのまま動くものもあるし、
今回、仕様変更になった部分は期待値など修正した上で実行しないといけない。
とはいえ、修正ポイントが明確ならば、それを修正した上でOKかNGかという話なので、そんなに難しくはない。
ところが、この以前の開発で作られたテストの中には、あまり出来が良くないものもある。
例えば、タイマレジスタの動作確認を行うテストがあったのだが、
とりあえず通してみてNGになったから、どういうこっちゃと思ってテストの中身を見たら、タイマレジスタの値を決め打ちで確認しているだけ。
おそらく、起動に要する時間を考慮して、起動直後に読み出して正しい値が入っているのか確認したのだろうけど、
システム構成の変更に伴い、起動時間も大きく変わったので、当然のことながら一致しない。
というか、このテストはちゃんとタイマレジスタの機能を網羅的に確認するものになっているのかというと、かなり怪しいんだよね。
というわけで、おそらくこのテストは捨てて、全く新しいテストを作る必要があるのだろう。
さすがにこれはあまりに雑だが、時間決め打ちというテストはけっこうある。
例えば処理Aの結果を確認するのに、処理Aの開始トリガをかけて、固定時間待って、結果が格納されるレジスタを確認するというのがある。
ところが処理Aの開始トリガをかけてから、実際に処理が完了するまでの時間が変化すると、処理Aが完了していない段階でレジスタを見に行くような場合も発生する。
こういう問題はけっこう発生しているのだが、実は処理A自体の動作時間が変わったことが原因ではなさそうで、
シミュレーション環境が変化したことで、トリガをかけてから実際に処理が開始されるまでの時間が変わったのが原因っぽいのよね。
とはいえ、時間決め打ちじゃなくて、外部仕様に基づいて完了信号の出力タイミングなどを基準にした方がよいことは確かで、
というわけで、この手の問題については、できるだけ時間決め打ちにならないように修正を行っている。
もっとも時間決め打ちになるのもやむを得ない場合もあるんだけどね。
サブシステムAとサブシステムBからメモリコントローラに同時にアクセスした場合の挙動を確認するテストがあるのだけど、
これも各サブシステムのアクセス動作開始のタイミングが時間決め打ちになっている。
各サブシステムの内部動作依存なので、外部仕様から明確なタイミングを規定できないんだよね。
なのでこのテストはタイミングの微調整を前提に作られている。
実行時に想定したタイミングでアクセスが入っているかチェックして、想定通りでなければNGにしてしまうと。
NGになった場合は、タイミングの微調整を行って、正しいタイミングでアクセスが入るようにすると。
そこまで考えられたものだったらよかったんだけどさ。
以前、テストの期待値で他の人と言い争いになったことがあった。
エラーログレジスタなのだが、特定のエラー時には仕様上、値が不定になるというものだった。
タイミングが少し変わるだけで、格納される値が変わってしまうというという代物で、それでテストNGが発生したんだよね。
でも仕様上は不定値なわけだから、僕は不定値となるレジスタは全てチェック対象から外しましょうと提案した。
不定値になるレジスタをチェック対象から全て外せばタイミング非依存になるので。
そしたら、もともとこのテストを作った人は、不定値のレジスタでも確認すべきだと主張してきた。
確かにレジスタAに格納される値は不定値かもしれないが、レジスタBにはレジスタAの値と同じ値が格納される仕様だから、そこは確認するようにとのことだった。
不定にならない場合はレジスタAもレジスタBも正しい値が入る必要があるのだが、不定値になる場合はこの値は使わないので食い違ってもよいような気はするのだが……
というわけでその指示に従ってテストを作り直したら、案の定というべきか、不定値になる場合にはレジスタAとレジスタBの値が食い違う例が発見された。
これを修正するのかはよくわからない。レジスタAが不定値の場合はレジスタBも不定値ですと定義すればおしまいだと思うのだが。
作り方次第では非常に再現性が高いテストも作れるんだけど、
なににおいても万全のテストを作るのはなかなか大変なことで、実際にはいろいろ妥協もある。
想定通りのタイミングでアクセスが入っているかチェックして、NGの場合は微調整をしてもらうというのは妥協の一例だろう。
そこまで考えられていたらあまり文句はないのだが。
Author : hidemaro
Date : 2018/03/09(Fri) 23:51
電気・数学・物理 | Comment | trackback (0)
外付けアンテナを付ければFMが勝てる
なんか改善方法がないかというところで、生駒山からのFM中継局を受信するという方法を考えた。
でも普通にやっても室内で受信できないのは確認済みで、外付アンテナが必要そう。
そんな中で先日買い換えたラジオ受信機が外付けのアンテナを付けられるようになっていたので、今回試してみた。
考えたのは2つ、1つは今も残っているはずのVHFアンテナを使うという方法、
もう1つは単に導線を外に垂らすという方法。
もともと生駒山からアナログテレビを受信していたのでVHFアンテナはあるはず。
FMラジオもVHFですから、これが使えれば好都合だ。
ただしアンテナの形状が違うし、インピーダンスにも差があるからか整合器というのを購入する必要がある。
ただ、もしかしたらうまくいかないかもしれないので、単純に線を延ばすという方法もあるだろうと。
自宅でも試してみたが、室外でアンテナを伸ばしてやっと受信できる放送局(実は隣市のコミュニティラジオなのだが)が、
適当な線でも長く外に出してつなげば室内で楽々受信できることが確認できていた。
VHFアンテナを使う方法だが、あまり期待通りにはいかなかった。
全く無意味ということもないのだが、期待したほどの効果はなかった。
一方で外に導線を垂らす方法だが、アンテナの張り方次第ではあったけど、
もっとも効果的に働いたところでは、放送局によっては多少の雑音は入るがよく受信できた。
ただし生駒山から送信しているすべての放送局がよく受信できたわけではなかったが。
でも受信環境の悪い放送局でも生駒山の中継局の方がAMラジオで受信するよりはよかったですからね。
というわけで外付けアンテナで工夫するという発想自体は正しかったらしい。
FM変調の復調には振幅成分を使わない。必要なのは周波数情報だけだから。
なので、リミッタなしで増幅して、振幅成分を消してしまうらしい。それから周波数成分を取り出すと。
そういう仕組みなので雑音に勝てる程度のS/N比さえ確保できればかなりクリアに聞けるけど、
ある一定のS/N比よりも信号が小さくなると一気に悪化する。これをスレッショルド効果というそうだ。
だから少しでも受信環境を改善すると、一気にクリアな音が聞けるようになるってことですね。
生駒山のFM中継局をうまく受信できるように工夫したのは、まさにそういう背景があったってわけ。
結局、既存のVHFアンテナを流用する方式はうまくいかなかったが、
単に線を垂らすという方法でここまで効果があるとは思わなかった。
また今度来るときもアンテナ用の線を持ってこようと思ったのだった。
Author : hidemaro
Date : 2018/03/04(Sun) 22:46
電気・数学・物理 | Comment | trackback (0)
CDMAってなにをやってたんだろ?
昨日、デジタル放送で使われている変調方式OFDMの話を書いた。
こういう通信の技術ってやたらと複雑なものが多くて、一体なんでそんなことができるんだよって思うことが多くて、
デジタル放送の単一周波数ネットワークは今まで謎の技術だった。調べてみるとなるほどって感じだけど。
そこで思い出したけど、CDMAもよくわからんのだよなぁ。
CDMAというと、第3世代の携帯電話の通信方式、W-CDMAなどで使われている。
そもそも、携帯電話というのは、複数の端末が同時接続できる必要がある。
複数の端末が同時接続する方式にはいろいろあるのだが、
一番わかりやすいのが周波数分割、この方式をFDMAという。アナログ時代の携帯電話がこの方式だった。
帯域を細かく区切って利用者ごとに割りあてて、使用中は1つのキャリアを占有していたと。
次にわかりやすいのが時分割、この方式をFDMAと言い、第2世代の携帯電話(日本ではPDC)がこの方式だった。
利用者ごとに時間を決めて通信してもらうわけだ。この方式にしたことで利用者増にもある程度対応できた。
ここまでは直感的にもわかりやすいのだが、3つ目の方式、CDMAはそう簡単ではない。
CDMAはCode Division Multiple Access、日本語で言うと 符号分割多元接続となる。
どうも、全ての基地局、全ての端末が同じ周波数を同時に使う方式らしい。
いやいや、それじゃあ全部混ざって区別できなくなるでしょ。
コードの違いで区別するんだって言うけど、コードってなんだよ。
ドコモR&Dのテクノロジー / 主要技術（ネットワーク） / マルチプルアクセス方式/ DS-CDMA方式の原理 (NTTドコモ)
この絵をみればわかるかな? 送信する波形にPN系列という波形を重畳することで区別できるようにすると。
このPN系列の波形を端末ごとに変えることで、区別できるようになると。
どういうことかというと、端末Aが 1という情報に (-1,+1,-1,-1,+1,+1,-1,+1)を重畳して送るのと、
端末Bが-1という情報に(+1,-1,+1,+1,-1,+1,-1,-1)を重畳して送るのと、端末Cが+1という情報に(+1,-1,+1,+1,+1,-1,+1,+1)を重畳して送るのと、
これらを全て重ねると(-1,+1,+1,+1,+3,-1,+1,+3)となる。これにそれぞれ重畳した信号列をたたみ込む。
端末Aの信号列をたたみ込むと+4、端末Bの信号列をたたみ込むと-12、端末Cの信号列をたたみ込むと+8となる。
プラスマイナスは正しく判定できてるね。これがCDMAってこと。
CDMAはコードさえ違えば端末を識別できるから、多くの端末を同時に収容することが出来る。
ただし、何も考えずにCDMAをやると、基地局近くの端末からの電波で、遠くの端末からの電波がかき消されるという問題が発生する。
でもこの問題は端末の出力を調整してもらえば解決できるから、それがCDMA実用化のポイントだったらしい。
あと、CDMA方式は送信する信号に、端末ごとに異なる速い信号を重畳して送る方式なので、占有帯域幅が広くなる。
FDMAは帯域を細切れにして1端末ずつ細く使っていた。これに対してCDMAは広い帯域をみんなで共有するという方法だったわけ。
帯域が広いので、その一部がノイズや干渉でやられても、残りの帯域で通信が成立するというメリットもあるようだ。
CDMAのおかげで携帯電話の利用者増に対応できたのだ。
というのだが現在のモバイルデータ通信の主力であるLTEはどちらかというとFDMAなんだよね。
LTEは下り(基地局→端末)はOFDMA、上り(端末→基地局)はSC-FDMAという方式を使っている。両方式ともFDMAって入ってるね。
OFDMAは昨日書いたOFDMそのもの。OFDMを多元接続用途で使っているというだけの話。
周波数を細切れにして(15kHz間隔)、細い占有帯域幅のキャリアを周波数空間で直交するように並べる。
干渉・ノイズなどの影響を受けにくく、受信しやすいキャリアをユーザーごとに割りあてると。
昔のFDMAに比べると、キャリアを緻密に並べられるようになり、ユーザーごとの周波数割り当てを動的に選べるようになった。
この結果としてLTEは周波数利用効率がよい通信方式となったのだという。
ただし、OFDMAは複数のキャリアを重ね合わせる方式なので、送信機の電力効率があまりよろしくないらしい。携帯電話でそれは困る。
というわけで、上りはSC-FDMAという方式を使っている。
ユーザーごとに帯域を割りあてて、その中で1つのキャリアで転送してもらうと。
ポイントはこの帯域は通信量に応じて加減できること。
通信量が少ない場合は、狭い帯域で低いシンボルレートにしてもらう、多い場合は広い帯域で高いシンボルレートにしてもらう。
OFDMAは低いシンボルレートの狭帯域キャリアを必要数束ねて使うが、SC-FDMAでは連続した帯域の幅を変えて、それに応じてシンボルレートを変えてもらうと。
やっていることは違うけど、根本にある考えは一緒なんですね。
これに周波数ホッピングを組み合わせt、周波数を動的に変えながら送信するので、干渉・ノイズで通信しにくい周波数があっても、影響を受けるのは一部で済む。
概念的にはLTEの方がわかりやすいよね。
動的に使う帯域を変えながら、通信量に応じた帯域幅、干渉・ノイズの少ない周波数を選んで使うと。
下りのOFDMAと、上りのSC-FDMAで考えには違いがあるが、狭い帯域の遅い通信をたくさん と 広い帯域で速い通信をドカン という考え自体は納得しやすい。
でも、それを実現する技術は複雑だ。動的に使う帯域を変えるというのはそういうことだ。
それに比べればCDMAはなんて直感的じゃないんだとは思うのだが、理屈が分かってしまえば、そんなに難しいことやってなかったんだなとわかる。
確かにこれなら1つの周波数でたくさんの端末と通信できるよね。
とはいえ、データ通信量の増大に対応するには、賢い帯域割りあてが必要だということでLTEに移行していったわけだけどね。
今は帯域がものを言う時代って話ですね。その考えからすればFDMAがシンプルでいいって話ですね。
Author : hidemaro
Date : 2018/01/27(Sat) 23:57
電気・数学・物理 | Comment | trackback (0)
なんでデジタル放送だと同一周波数でいいんだろ
地上デジタル放送の特徴として単一周波数ネットワークというのがある。
これができるおかげで、UHF53～62chを携帯電話用に転用したり、
茨城県・栃木県・群馬県でのNHK総合テレビの県域放送ができるようになった。
というわけで、すごく画期的な技術なんだけど、なんでできるようになったんだろ?
同一周波数ネットワークというのは、同じ周波数の送信所を並べてネットワークを作る方式だ。
i-dioがよい例だが、関東甲信越については全ての送信所が105.428571MHzで送信する。
親局の東京タワーも、秦野中継局も、将来できるかも知れない群馬県の送信所も、全てこの周波数を使う。
テレビで全ての送信所を同一周波数にしている放送局はないはずだが、複数の送信所で同じ周波数が使うことは普通にやっていて、
例えば埼玉県のNHK教育テレビの中継局で使っている物理Chを見ると26chと17chの2種類しかない。(cf. 受信情報 (NHKさいたま放送局))
アナログ放送では基本的にこういうことをしない。
なぜならば、同じ周波数で複数の場所から送信すると、複数の送信所からの電波が干渉して受信しにくくなる地域が生じるからだ。
それでも周波数を有効利用するために、同期放送という方法で同一周波数の中継局を設けることがある。
一部のAMラジオ局と、コミュニティラジオ局で採用されている。
複数の送信所の周波数を精密に合わせると干渉の影響を緩和できるという理屈なのだが、
この方式でも干渉が生じて受信しにくくなるエリアは発生するのが実情だそうで。そういうエリアを山間部とかに押し込めてるだけだと。
なんでデジタル放送では単一周波数ネットワークができるようになったのか?
その理由はOFDMという変調方式を使っているからだそうだ。
OFDMってどんな変調方式なのかと調べると、
- 与えられた帯域を細切れにして、多数のキャリアを並べる (ISDB-Tでは5.57MHz幅に432本×13セグメント=5617本)
- 各々のキャリアは周波数空間で直交するように選んでいるのでお互いに干渉しない
- 1つずつのキャリアの帯域は狭い分、シンボルレートは遅くする(ISDB-Tでは1008μsで1シンボル送る)
アナログテレビではキャリア(搬送波)は音声・輝度・色の3つだったはずだから、デジタルテレビは5617本だから3桁も多い。
アナログとデジタルで比べるものでもないとは思うが、キャリアの数が多いというのが大きなポイントだそうだ。
位相差のある複数の波を重ね合わせると、その時々で強め合ったり、弱めあったりする。これを干渉と言っている。
複数の送信所からの電波を重ね合わせたときにも発生するが、1つの送信所から受信する場合でも、長距離伝搬するときは発生する。
というのも、長距離伝搬するうちに反射などで、伝搬経路の違う複数の電波が重ね合わされるから。
遠くのAMラジオ局を受信すると、音量が大きくなったり小さくなったりするけど、これこそまさに干渉だ。
ただ、周波数ごとに弱め合うタイミングと強め合うタイミングが違うから、
キャリアが5617本もあれば、その時々で干渉して使えないキャリアもあるけど、使えるキャリアもたくさんあると。
ところが、これだけでは問題は解決しない。というのも、伝搬距離の差で遅延量にも差が発生するから。
電波が10km伝搬するには33μs、50km伝搬するには167μsかかる。
ということは、50km離れた送信所からの電波は、10km離れた送信所からの電波より134μs遅れて到達することになる。
アナログテレビではこの差がゴーストとして見えていた。ずれた画面が重ね合わされたように見える現象ですね。
音声ぐらいゆっくりした信号ならさほど問題はないんでしょうけど、映像だと大きな問題になる。
しかし、この問題もOFDMのキャリア数が多いという特徴により解決されることになる。
キャリア数が多い分、1つのキャリアで使う帯域幅を狭くする必要があり、そのためには伝送スピードは遅くせざるを得ない。
アナログ変調を例に取るとわかりやすいけど、AM変調でf[Hz]の信号を送るには、2f[Hz]の帯域を使う。
AMラジオは7.5kHz程度の音声しか送らないので、占有帯域幅は15kHzで済む。
これに対してアナログテレビの映像信号は4.2MHzもある。音声信号など含めて占有帯域幅は6MHzとなる。
狭い帯域幅では遅い情報しか送れないというのは、ここからも理解できると思う。
実際、ISDB-Tでは5617本もキャリアがあるが、1つのキャリアは1008μsで1シンボルしか送らない。
1シンボルには6bit(ワンセグ以外)、2bit(ワンセグ)を割りあてている。(1シンボルで表す情報量が少ないということは、その分ノイズに強い)
1秒に1000シンボル、1シンボルで6bitとしても6000bpsだが、これが5617本もあるので30Mbpsぐらいになる。
確かにハイビジョン映像送れそうな数字だね。(実際には情報を冗長化しているのでこれより低いが、実際のデータレートも16.8Mbps程度)
このシンボルレートが遅いという特徴により、複数の電波の重ね合わせで遅延が生じても無視できるようになる。
1008μsで1シンボルということは、1シンボル解読するのに1008μsかけてよいことになる。端は遅延の影響を受けても、真ん中が大丈夫ならOKだ。
さらにシンボル間に126μsのガードインターバルを空けてあるので、送信所同士の遅延量の差がこの範囲に収まれば、シンボル本体は何も影響が出ない。
周波数を細切れにして、多数の周波数に情報を散らし、それぞれの周波数ごとではゆっくり送る。
多数の周波数に情報を散らしているおかげで、干渉でダメな周波数があっても、問題ない周波数で救える。
情報をゆっくり送ることで、送信局同士の遅延量の差があっても、吸収できてしまう。
この結果、単一周波数ネットワークという仕組みが成り立つわけだ。
こういう変調方式が成り立つのはデジタルだからこそというのはあるんだけど、
いろいろあるデジタル変調方式の中でも、同一周波数ネットワークを構築できる条件を選んでいるのは言うまでもない。
遅延量の問題があるので、シンボルレートが速いとどうやってもできないですからね。遅いってのが大きなポイントではある。
他にデジタル放送では、チャンネルにすき間を空けずに敷き詰めてよいというのもある。
6MHz幅のうち、5.57MHz幅にキャリアを敷き詰めても(=片側あたり215MHzのすき間を空ければ)、隣接チャンネルには影響なしというほどだ。
アナログテレビは、隣接のチャンネルから干渉を受けることを防ぐため、すき間を空けて使っていた。
確かに、近畿広域圏ではVHFで2,4,6,8,10,12chと偶数チャンネルだけ使っていたよね。今はそういうことをしなくてよい。
むしろアナログのときはすき間が必要だったのかって話だけど、デジタルになって改善したことの1つではある。
Author : hidemaro
Date : 2018/01/26(Fri) 23:58
電気・数学・物理 | Comment | trackback (0)
実はよくわかっていないらしい
最近、設計のことで有識者といろいろ揉めているのだが、
果たして有識者はよく考えて反論しているのかと思うことがしばしば。
最近やっている仕事だが、あるモジュールで行われた設計変更を類似した別のモジュールに反映するというもの。
類似したモジュールAとXがあって、Aに対して設計変更を行ったBがすでにリリースされている。
これに次いで、Xに同様の設計変更をして新しいYを作っているのだが、これがなかなか難儀なのだ。
というのも、A,BとX,Yではアーキテクチャに差があって、A→Bの設計変更をそのまま反映するというわけにはいかないのよね。
X,Yの方が設計が複雑になりやすいので、Bをリリースしてから、Yを作るということをやってるわけだけど。
ここで問題なのが、Bの設計ポリシーと、元々のXの設計ポリシーのかみ合いが良くない場合があるということ。
単純に過去の設計ポリシーを組み合わせて作ればよいというものではないと思っている。
それで過去の設計にはこういうデメリットがあるので、新しく設計する部分はこういう設計にしましょうと提案してんだが、なかなか有識者が首を縦に振らない。
明確に問題点を指摘してくれればよいし、その場合はそれはごもっともだということで再考するのだが、
有識者といいながら過去のXの設計ポリシーに必ずしも熟知しているとも限らず、反論には決め手に欠けることばしばしば。
過去の設計ポリシーに従った場合の致命的なデメリットを示せると、これはさすがに首を縦に振らざるを得ないのだが、そこまで行かないとなかなか。
挙げ句の果てに「反論するのに手間を費やすぐらいなら、意味がわからなくても過去の設計ポリシーに従うべきなのでは」ということを言われることもあった。
すなわち言っている本人も意味がわからず反論していると告白しているのだ。
フルスクラッチで作るなら、あるべき姿を追求しやすいのだが、そういうものではないですからね。
特に今回の場合、過去のXのアーキテクチャを大きく変えることは難しい。
そういうわけで、多少の不都合であれば、それは仕方ないということで受け入れてやる必要がある。
ところが、A→Bの設計を反映していく中で、あからさまにおかしいところがいくつも見つかるんだよね。
アーキテクチャを大きく変えない範囲で、従来のXの設計ポリシーとは違った設計にするべきだとか提案してるんですけどね。
別のデメリットがあるということで不採用になったのもある一方で、これが問題提起になって大きな見直しが行われた部分もある。
なので、あるべき姿を考えることには意味があると手応えを感じているのだが、上のような問答になることもある。
実はこの仕事って他部署の応援でやってる仕事なんだよね。
ここの部署に応援に行くのは二度目で、実はA→Bの設計変更にも一部関わった経緯がある。
そのときの経験も踏まえて思うのは、どうもこの部署の人は過去の設計をなかなか変えたがらないということ。
過去の設計を元にした設計変更が多く、長年にわたってフルスクラッチで設計するという経験がなかったのもあるんだろうか。
過去の設計に長所があるだろうというのも確かな話ではあるが、短所だってないとは言えないんだよね。
あるべき姿を描いて、長所と短所を正しく理解できればよいのだが、なかなかそれができないと。
この点については、所属部署ではあるべき姿についてよく議論ができていたんだよね。
大きな新規開発があったこともあって、そこで新たなあるべき姿を描けたというのもあるんだろう。
その中で過去の設計に短所があるということも実感しており、過去の設計についても率直な議論ができている。
あと、今のところは過去の設計についてよく知っている人がちゃんといますからね。(現役ではない古い製品は別として)
あの部署の人が過去の設計をあまり変えたがらない割には過去の設計についてよくわかっていないというのは、、
所属部署のチームリーダーとも共通の認識ではあって、なかなか根深い問題ではあるのだろう。
ただ、無駄に手間をかけて、おかしな動きをするものを作るようなことは、設計・実装を行う人として不本意なので、
有識者とよく話し合って、あるべき姿を描けるように努力していこうとは思っている。
Author : hidemaro
Date : 2018/01/09(Tue) 23:59
電気・数学・物理 | Comment | trackback (0)
暗号化されたHDL
今日で年内の仕事は終わり、って今日まであるんかよって言う人もあるかもしれないが。
実際、今日は休暇を取ってる人多かったけどね。まぁガラガラってことは無かったが。
いつも仕事に出かける前は、NHKの「おはよう日本」を見ているが、今日はお休み。
なので、NHKラジオ第1の「マイあさラジオ」を聞いていた。この番組は本当に毎日やっているからちょうどいい。
さて、最近は論理回路のシミュレーションをいろいろやっている。
シミュレーションには自分の作った回路以外に、デバイスのモデルとか他の人の作ったHDLも合わせて使う。
これにより、結合テストをシミュレーション上でできるので、大変役立つと。
モデルが提供されていなければ、自分で作ることもあるけど、それはそれで大変ですから。
そんな中で、とあるIPコアのモデルが暗号化されたHDLで提供されていた。
このIPはFPGA内のプリミティブを使って、とある機能を提供するためのIPコアだ。
この機能を応用してとあることをやろうと思っているのだが、そのためにはこのIPと自作のロジックがうまく連携して動く必要がある。
なので、結合してテストをしたいのだが、そのモデルはなんと暗号化されていると。
そして、使いたいバージョンのモデルは、この職場で使っているシミュレーターに対応していないと。(違うバージョンなら対応しているようだが)
暗号化さえされていなければ、モデルを改造したりして対応できたんだろうが、暗号化されててはねぇ。
IPコアのIPって Intellectual Property、すなわち知的財産って意味なので、その中身というのは秘密にしたい物だ。
そこでIPコアの提供用に暗号化されたHDLが使われることがあると。
ただ、テスト用のモデルが表しているものって外部仕様なんだよね。
デバイスの外部仕様に従って、信号を受け、信号を出す、それがモデルの意義だ。
シミュレーション用モデルでの実現方法と、実際のIPコアでの実現方法が違うのは普通だけど、それでよい。
そう考えるとシミュレーション用のモデルが暗号化されてるのは、なんだかなぁと思う。
暗号化されたHDLを見るのは初めてだったのだけど、その仕組みを知ってなるほどと思った。
このHDLの暗号化には公開鍵暗号方式のRSAが使われている。
公開鍵暗号では、公開鍵を使って暗号化すると、秘密鍵がないと復号できない。
ここで秘密鍵の持ち主をシミュレーターのベンダーとすれば、
シミュレーターのベンダーが提供する公開鍵を使ってHDLを暗号化すれば、シミュレーターのベンダー以外にはHDLを秘密に出来る。
シミュレーターにはそのベンダーの秘密鍵が組み込まれ、シミュレーション実行時にその秘密鍵で復号しているということらしい。
こういう仕組みなので、シミュレーターベンダーごとに異なる鍵で暗号化されたHDLが用意されていて、適するものを選んで使うことになる。
主なシミュレーターには対応していると思ったのだが、バージョンによって対応状況が違ったようで、
使いたいバージョンではうちの職場で使っているシミュレーター向けに暗号化されたものがなかったと。
違うバージョンでは対応したのがあるらしいので、そっちを使うというのが代替案としてあるが、
多少の機能差分がありそうなので、そこをごまかしてシミュレーションするというところが狙い目かなぁって言ってるけど。
いずれにしても、よくわからないIPなので、年明けはこのIPの調査をいろいろやらんといかんね。
Author : hidemaro
Date : 2017/12/29(Fri) 22:19
電気・数学・物理 | Comment | trackback (0)
後で分かった設計ミス
チームリーダーから頼まれて、モジュールの故障解析手順の調査を依頼された。
サービスマンがこのモジュールは本当に壊れているのか、実はそうでもないのか切り分けをしたいと。
その調査をしていたのだが、設計がおかしくて、解析に難ありということがわかった。
うちの職場で開発している製品では、重故障・軽故障・正常動作 という3モードを持っている。
重故障は一度故障すると交換しない限りは復活しない故障、軽故障は外部要因で発生する異常状態を表している。
ところが、境界領域というのもあって、内部の故障で交換するしかないか、外部要因で発生しているか切り分けできない故障もある。
チームリーダーから依頼されたのは、モジュール交換をするべき故障なのか、まずは外部要因を疑うべき故障なのか切り分けをしたいという話。
モジュールが重故障・軽故障・正常動作であるかはインジケータを見れば容易に判別できる。
ここから具体的に何の故障であるか切り分け、内容によっては外部要因を疑ってもらう必要がある。
ところがアーキテクチャ的な問題でこのモジュールとのデータのやりとりは非常に制限されている。
それでも軽故障であれば、故障情報の確認は可能なのだが、
重故障の場合、通常の方法では故障情報の確認ができないのだ。
その上、外部要因で発生する重故障というのが存在しているという、もっと厄介な事情もある。
すなわち、この問題は以下の3点の問題があったわけだ。
- アーキテクチャ的にモジュールとのデータのやりとりがしにくい
- それでも軽故障なら故障情報の確認が出来るが、重故障は故障情報の確認が出来ない
- 仕様外の環境で使うと、外部要因で重故障を発生させられる
1はアーキテクチャ的な問題で、致し方ない面もある。ただ、それゆえの不都合というのは他にもいくつかある。
その弱点を一部補う機能があったのだが、2に書いたとおり、重故障ではうまく働かないという設計上の欠陥があった。
もともとデバッグ機能だったので、そこまで深く考えて作った機能ではなかった故の問題のようだ。
それでも外部要因で発生しうる故障は軽故障に分類してくれていればよかったのだが、
特定の故障は外部要因で起こせるけど、本当に内部回路が故障していたら怖いから重故障にしてしまったのだという。
僕はこの中では3が一番大きな問題だと思うんだけどね。
そのことでチームリーダーに当時の経緯を聞いてみたのだが、元になったモジュールの設計がそうだったから、それに従ったとのこと。
一方でこのモジュールは重故障と軽故障、どちらにしてもインジケータの表示が変わる以外の差はあまりない。
というのも、重故障の場合に取れる次善の策というのがこのモジュールにはないから。
他のアーキテクチャだと、重故障の場合は次善の策を取る仕組みがあるんだよね。軽故障は外部要因によるものと判断して次善の策には出ないんだけど。
故障の種類によっては次善の策があれば重故障、なければ軽故障という区別をすることがある。
その観点で言えば、このモジュールに重故障という概念は不要な気はするのだが、
一方で絶対に復活しない故障というのも存在していて、そういう場合は潔く交換しなさいという指示になるので、その点では重故障の意味はある。
ところが、なぜか外部要因でも起こしうる故障が重故障に分類されていたので、単純に「重故障の場合は交換しなさい」と言えなくなってしまったと。
それでも2の問題がなければ救いようはあった。
ところが重故障の場合は故障情報が取得できないというバグがあったのだ。
そもそもこの機能は純粋なデバッグ機能で、故障解析に使いたいという要求があって作った機能ではなかったと。
ところが1の問題があって、もジュールとのデータ交換には大きな制約があった。
その点ではデバッグ機能とはいえ、モジュールとやりとりできる貴重な機能の1つではあった。
ところが、しょせんはデバッグ機能、開発者以外が使うことは全く想定しておらず、出来の悪い機能だった。
その結果、重故障の場合は故障情報が取得できないというバグがあるまま、製品化されてしまったのだという。
当初、故障情報を取得して故障要因を切り分けしたいというニーズはほとんどなかったそうだ。
開発者はデバッグのために故障要因を知りたかったが、まさかその機能をサービスマンが使うとは想像もしてなかったのだ。
このモジュールの設計が、僕が今の職場に来る1年前ぐらいに行われたもので、僕は設計に関与していないのだが、
どうして「それ重故障にしちゃうんですか」という問題提起がなかったのかは本当に不思議な話だ。
確かに過去の同種のモジュールの設計に従ったという事情はあるのだが、そもそもそれの設計がおかしかったんだよね。
過去のモジュールの設計に従った結果、サービスマンが苦しむという展開は予想できなかったにしても、
そもそもの設計ポリシーとは矛盾しているので、原点に立ち返って考えるべきだったんじゃないかなぁと。
当時、僕が設計に関わってたら、この問題は回避出来てたんだろうか? どうにも悔しい思いがある。
(もっとも職場に来た直後だと、設計ポリシーを詳しく知らない状態だっただろうから、そういう意見は言えなかったかもしれないけど)
まぁもう世の中に出ているもので、なおかつ通常稼働では発生しない問題なので、どうしても修正しないといけないバグではないのだが、
そうはいっても悔しいというかなんというか。もうちょっとやりようがあったよねぇと。
なんか、バグ修正する機会があれば、上で書いた2の問題を修正したいところだけどね。
3は外部仕様にも絡む問題なので不用意に修正はできないが、2は元々デバッグ機能なので外部仕様とは無関係に修正できる。
修正後はデバッグ機能とはいえサービスマンにとっても役立つ機能になり、結果として新しい外部仕様として盛り込まれるのだろう。
チームリーダーには「他の設計変更するときにしれっと変更しましょ」と意見は述べておいたが、やるかは知らない。
Author : hidemaro
Date : 2017/12/07(Thu) 22:15
電気・数学・物理 | Comment | trackback (0)
色違いだけど色違いだけではない
以前、色違いの製品の話を取り上げた。
うちの職場で作っている製品には「色違い」呼ばわりされる製品がある。
その中には内部構成が大きく異なるものもあるが、中には論理的な区別はあるが中身は全く同じ色違いもある。
内部構成が大きく異なれば、職場内でも全く別物として理解されているのだが、ただの色違いとなればそれは同じものという認識になる。
最近、中身は全く同じで色違いの製品を使う試験の準備をしている。
あるシリーズに対して従来行っていなかった試験が必要となったのだ。
このシリーズはできるだけ他のシリーズの機器を流用しており、
- このシリーズ独自の機器
- 他のシリーズの単なる色違い
- 他のシリーズでも使っているが、異なる用途で使われている機器
- 本体は単なる色違いだが、周辺機器の使い方が違う機器
1は全く独自なので完全に新規に試験が必要となるのは明らか。
2は流用元シリーズと全く同じなので、試験を省略してもよい。(流用元では同様の試験を実施済み)
3は流用元のシリーズでは用途が違ったので試験対象外だったが、今回は新規に試験が必要になる場合がある。
4は周辺機器だけの問題ではあるのだが、周辺機器の試験をするには単なる色違いの機器も動かさざるを得ない。
僕はこのシリーズ独自の機器には関わってこなかった。
なので自分が関わる範囲では単なる色違いという認識でいた。
ところが実際には上で言うところの3,4に該当するものがちょこちょことあったのよね。
特に4に該当するものは、周辺機器が変わるとけっこう使い方のイメージが変わるなぁと思った。
周辺機器の差は本質的な差ではないので、これまでもさほど考慮してこなかったという経緯はあるのだが、
その一方で周辺機器まで含めて組み上がったものを見てみると、意外に差があるなぁと。
上で挙げた3,4のような単なる色違いとも言えない差分が生じた理由だが、
どうもこのシリーズは流用元のシリーズより省スペースになるように作ったからのようだ。
そのためにスペースを食う機器を省スペースのものに置き換えたり、省スペースになるように機器の選定を変えたのだろう。
流用元のシリーズはメンテナンス性重視のようで、極度の省スペース化は嫌われてきた経緯もあると聞いている。
当たり前なんだけど単なる色違いで別シリーズになるわけはないんだよね。
想定される用途に差があるからこそ別シリーズになるのであって、その中で共通化できる部分は流用したって話だね。
Author : hidemaro
Date : 2017/11/20(Mon) 22:28
電気・数学・物理 | Comment | trackback (0)