画像技術に挑戦

私のターニングポイント

1997年、私はソフトウェア開発課の課長をしていました。その頃、ソフトウェア技術だけでは、開発受託を続けていくのは難しいのではないかと考えるようになりました。
ソフトウェア技術＋αの得意技術を修得してわれわれの武器とするために、画像処理開発に挑戦することにしました。

画像処理への挑戦

松下通信工業 AVC研究所で携帯電話用MPEG-4画像コーデックDSP開発プロジェクトがスタートすることを知り、新人2名と共に参画する決断をしました。

横浜のAVC研究所に滞在して開発がスタートしました。初めての画像処理開発で、画像のY/Cb/Crや 4:2:2形式の意味も知らなかったので画像の基礎からの勉強です。

MPEG-4規格書を解読しながらソフトウェア構造を設計していきました。また、新しいDSP命令セットを理解して、新人を育成しながらプログラム設計を進めました。MPEG-4エンコーダとデコーダーを同時に動作するマルチコーデックを実現する方式についても検討が必要でした。携帯電話用で無線通信するので、通信エラーに対してのエラー耐性アルゴリズムも検討して組み込みます。
勉強すべきことがたくさんありました。

数々の課題発生

開発が進むとともに、数々の課題が発生しました。

設計段階で課題となったのは、MPEG-4エンコーダーでストリームを生成する時、画像圧縮結果の3つの要素（LAST=1bit , RUN=6bit , LEVEL=4bit）に対して200個程度のVLC(Variable Length Coding)と呼ぶ可変長符号が割り当てられます。どのようにして、VLCに変換するか？

3つの要素をつなげると11bitになりますので、2048ワードの大きなテーブルが必要になりメモリを圧迫する上に、ほとんどが参照されない無駄な領域となります。ソフトウェアの定石としては、バイナリサーチ・アルゴリズムを使用しますが、DSPにおいてはメモリアクセスがボトルネックとなってしまいます。

何度も考え抜きました。ふと、ハッシュ手法が使えないか検討しアイデアを整理しました。ハッシュとは、『細かく切りくだきめちゃめちゃにする』という意味があり、キーとなる情報からデータ配列のインデックス値へ写像関数を作るものです。

一般的なハッシュ手法を使うには、課題が二つありました。

ハッシュ関数はキーをハッシュして mod(N)の剰余計算を行います。Nは素数が望ましいのですが、DSPには除算命令がありません。
複数のキーが同じインデックスを示すシノニム発生を解決する手段が必要であり処理量が増加します。

課題1に対しては、Nを2のべき乗数としてマスク演算で代用できるようにしました。課題2に対しては、テーブルを少し大きく確保してハッシュ関数を工夫してシノニムの発生自体を防ぎました。

その結果、キーから直接インデックスを計算するたるの計算量は増加するのですが、メモリテーブルの参照を最小限とすることにより、高速にVLCコードに変換することができました。

DSPによる開発

DSP(Digital Signal Processor)とは、デジタル信号処理に特化した機能をもつマイクロプロセッサです。いろんなマイクロプロセッサの開発を経験したことがありましたが、このDSPアーキテクチャは面白いほど特徴的でした。

デジタル信号処理を高速に行うために、大量のデータに同じ演算を同時に実行するSIMD (Single Instruction Multiple Data )機能や、積和演算を高速に実行するための命令や、特殊なメモリアドレッシングモードをもっていました。

MPEG-4では、8×8ブロック(64バイト)単位に処理することが多く、1個のDSP命令で複数バイトのデータに対して同一の処理を行うことが可能でした。DSP内部には、高速・小容量なメモリブロックを3個搭載していました。DSP命令は、3アドレス方式で別々のメモリブロックを指定して、データバスの衝突を起こさずにメモリブロックに対してひとつの演算を行うことができました。
外部の大容量のDRAMとは、DMA転送で内部の演算処理と同時に行います。

また、VLIW(Very Long Instruction Word)命令もあり、限定的ですが複数の命令を同時実行することも可能でした。

RISC(Reduced Instruction Set Computer)系マイクロプロセッサでは一般的である遅延分岐もありました。遅延分岐とは、内部のパイプライン処理の都合で次の命令を実行した後に分岐が行われるものです。開発はアセンブラ言語で行いますので、ソースコードでは分岐命令の直後に分岐前に行う処理があり、ちょっと混乱してしまいそうなソースコードとなってしまいます。

開発当初は、DSPチップの仕様が決まりかけた頃で実際に動作するDSPはまだ存在しません。開発環境としてUNIXを使い、ソースコードを機械語に変換するアセンブラとDSPシミュレータがありました。

マイクロプロセッサ系でC/C++言語による開発が定着したこの時期に、特殊なアセンブラ言語での開発ですので、１０年ほど時代が逆行した感じを受けました。

デバッグしているときに、正しい結果にならないことがあります。普通は自分の書いたプログラムを疑うのが正道なのですが、今回の開発においてはいろんな原因が考えられます。

自分のコードに不具合がある
DSPシミュレータの動作に不具合がある
アセンブラに不具合があり、生成した機械語に誤りがある

最初に自分のプログラムを疑うのですが、正しい場合は別の原因を特定するために簡単なテストプログラムを書いて原因を特定して対策を依頼します。

このころは、ソフト開発部隊に応援メンバーを増員して7名体制で開発していました。DSPチップのハード開発部隊は博多にありましたので、開発途中から博多に集結し、ハード開発メンバーの近くで一緒にソフト開発を進めていました。

DSPエミュレータ、そしてDSP実チップ

DSPシミュレータは実時間で動作するわけではなく、機械語のインタプリタのようなもので、とても処理速度が遅いものでした。ソフトウェアの論理的なデバッグをする目的としては十分使用できました。

DSPハード開発部隊は、回路シミュレーションでハード設計のデバッグを進めています。完成したRTLコードをエミュレータに乗せて、DSPハードの動作確認のフェーズとなりました。

私たちDSPソフト部隊は、エミュレータにDSPコードを乗せて、ほぼ実時間でプログラムが動作するようになりました。ここでも、デバッグしているときに、正しい結果ににならないことがあります。

自分のコードに不具合がある
DSPハードのRTLコードに不具合があり、DSPハードが正常に動作しない
DSPシミュレータの動作に不具合がある

不具合の原因を解析して、問題のある部分を対策します。
DSPシミュレータの実行結果とDSPエミュレータの実行結果が一致すれば、その部分のモジュールは完成です。

DSP実チップが完成すると、実機を使用したテストとなります。ハードウェアのテスト漏れや実行タイミングの微妙なズレで想定外の不具合が発生しました。ハード屋さんは、エラッタと呼ぶメモを発行して、不具合の発生する使い方を仕様として制限します。つまり、動作しているものを仕様としてしまうのです。
そのため、ソフト屋はエラッタ条件をソフトウェアで回避して別の方法による対策をします。

DSPハード屋さんとソフト屋さんが協力しながら、目的としたDSPチップとソフトウェアは完成に近づいていきます。

ブートプログラム

私は、MPEG-4コーデック部のプログラムのほかに、ブートプログラムも書きました。一般的なブートは、外部記憶からプログラムをロードしてブートします。
しかし、今回のシステムにおいては、携帯電話機能を担当するアプリケーションCPUがあり、CPUが外部メモリからDSPコードをロードして、CPU-DSP間で通信してDSPの命令メモリにロードするというブート方式でした。

当初のCPU担当者の提案では、CPU-DSP共用メモリブロックにプログラムを書き込んだタイミングで割り込み入れて通知する方式でした。DSPブートプログラムはマスクROM化するので不具合があったら修正する方法はなく、失敗したチップとなる可能性があります。そこで、私は慎重になり割り込み方式ではなくフラグによるハンドシェーク方式を提案して、ブートI/Fを変更してもらいました。

さらに、ブートストラップ方式も隠し機能として組み込みました。この方式は、最初にCPUから渡された512バイトのプログラムだけを命令メモリに格納する方式です。もし、ハンドシェーク方式のブートプログラムに不具合のあった場合は、このブートストラップで最小限のブートプログラムをロードして、本物のプログラムをロードする奥の手を仕込んでいました。

幸運にも、ブートプログラムは実DSPチップで動作しましたので、隠し機能は使われることはありませんでした。しかし、実チップの開発が進む中で多数のエラッタが発行され、ある特殊なタイミングの割り込みに不具合があることが判明しました。もしかしたら、割り込み方式のブートプログラムで開発を進めていたら、ブート不具合でチップの完成が遅れた可能性があると考えると背筋が凍りました。