メモリーテスト〜フェイルビットマップに関する補足

以前のエントリーでSRAMのテストについて書きました。

この中で、テスターにSRAMのアドレス端子を教えてあげれば、不良を起こしているメモリーセルの物理的な位置を知ることの出来る、フェイルビットマップという便利なものがある、というような内容の説明を書きました。

これについて、若干補足したいと思います。

テスターにロウアドレスとカラムアドレスのピンを教えてあげるとフェイルビットマップを作ってくれる、と書きました。しかしこれには色々と条件があります。

筆者が使っていたアドバンテスト社のT3340シリーズには、ALPG（Algorithmic Pattern Generator）というメモリーテスト用テストパターン発生機能がありました。これは、テスターがメモリーテスト用の色々なテストパターンを自動生成してくれる仕組みですが、これを使ってテストパターンを発生させるというのが、特に特別な準備をしなくてもフェイルビットマップを取得できる条件でした。他社製のテスターにも似たような機能はあるのではないでしょうか。

しかし、ALPGを使わないテストパターンを使ってフェイルビットマップを作成しようとすると、一筋縄ではいきませんでした。

フェイルビットマップを作成するためには、期待値不一致が発生したときの、以下の情報が必要です。

• 発生したパターンの前から何ステップ目で発生したか？
• 不一致が出たデータ端子はどれか？
• ロウアドレスには何が入力されていたか？
• カラムアドレスには何が入力されていたか？

LSIテスターに於いて、テストパターンで期待値不一致が発生したことは、テスト結果がFailだったということでテストプログラムから簡単にわかるのですが、どのピンに期待値不一致が発生したのか、という情報や、期待値不一致が発生したときのアドレス入力が何だったかを知るためには、そのときのテストパターンがどういう内容かを知る必要があり、そのためにはシステム制御系の操作を行って、パターンメモリーを読み込んでビット演算をする、などという特殊な操作をする必要がありました。

これに対して、ALPGはテスター自身がテストパターンを発生するので、期待値不一致が発生したときにメモリーに与えているアドレス値が何かはテスターが自分で知っています。

ただ、ALPGは、記述の仕方が難しく、さらに、ロウデコーダーやカラムデコーダーが素直な配列で作られていないと、正しいビット配列にならないので、製品展開には使いにくいものでした。

特に、私が担当していたマイコン搭載ASICにおいて、お客様の回路の中に搭載するSRAMには、コンパイルドRAMという、ビット数とワード数を指定してEDAにSRAMを自動生成させるという仕掛けが使われていましたが、このコンパイルドRAMのアドレスデコーダーの作られ方が特殊で、ロウデコーダー、カラムデコーダーの出力が素直な並び方をしないのに加えて、その規則性がよくわからない、というものでした。

規則性がきちんとわかれば、それに基づいてALPG使用テストパターンの自動生成も可能なのでしょうが、規則性がわからない以上、製品展開においてALPGを使用するのは無理、ということになったのでした。

製品展開グループでは、この辺の事情を考慮したフェイル・ビット・マップ描画プログラムを自前で準備していたようです。