ASIC製品では、中身の回路は基本的にお客様の回路なので、お客様が論理設計をしたネットリストと論理検証用テストパターンを頂いて、それを元に製品開発をスタートするのが普通です。中には仕様受けと言って、お客様から回路仕様を頂いて、それを元にベンダー側が論理設計をすることもありますが、その場合でも回路はお客様のものです。
中には、回路仕様のドキュメントもろくにない、イメージ受けと言っても良いような製品もあるようですが、こういう切り口の開発は、回路仕様の最終的な確認の段階で責任の所在が不明確になるので、トラブルの元かもしれません。
この製品では、お客様の回路はお客様が設計しましたし、製品仕様は明確だったので、そのようなおかしな話にはなりませんでした。
この製品の開発に於いて、まず、お客様とのやりとりが発生する、開発フロー上の解決しなければならない課題を挙げたいと思います。
開発手順やらツールチェーンやら、決めなければならないことはたくさんあります。
まず、お客様の回路をどのように設計していただいて、どのような設計データとして半導体メーカー側に提出していただくかをお客様に提示する必要があります。後の工程でトラブルが出ないように、論理設計には色々な設計制約というものがあり、これを守った設計をしていただく必要があります。
また、マイコン搭載製品に於いては、お客様の回路とマイコンコアがLSIの中で接続される訳ですが、単体LSIでは外部ピンに出ていない内部信号もマイコンコアの端子として存在する中で、誰がどうやってお客様の回路とマイコンコアを接続するのがよいのか、そしてその手順をどうするのか、これを決めなければなりません。
そして、作業分担をどうするかを明確化して、お客様にこれで行きいましょう、と提案しなければいけません。お客様と共同作業をすることになるので、お客様、半導体メーカー側の両方が仕事のやりやすい、効率的な方法を提示する必要があります。その中には、当然ながらスケジュールの話も入ります。
論理設計完了を最終的に宣言する為の論理検証に使うシミュレーターをサインオフシミュレーターと言いますが、これに何を使うかは、設計作業着手前に定義しておく必要があります。
面倒な話に思われるかもしれませんが、半導体メーカーは、公式に認められたツールを使って得られた設計・検証結果でなければ、設計結果に対して保証ができない、というスタンスを取ります。半導体メーカーが公式に認める、というのは、私がいた会社の場合は、社内のEDA部門がツールの検証を行って、EDA部門から使っても大丈夫、とリリースされる、という意味です。
世の中、半導体設計の為のツールは沢山ありますが、EDA部門がチェックしたものでなければ、製品開発には使っちゃいけません、ということです。
この製品の開発に当たっては、論理シミュレーターはVerilog-XLを使ったと思います。非常に順当な、ある意味当たり前、それ以外にあるの？というほどのツール名ですが、それを確認、合意しておくことが重要です。DFT回路（スキャン回路等）付加は、この時期はまだ内作ツールを使っていました。
なお、お客様回路は、ネットリストで頂いたと記憶しています。論理合成は半導体メーカーサイドではやっていないはずです。論理合成は色々と難しい場面がありますので、お客様サイドでできるのなら、やっていただいてネットリストとして提出していただくのがありがたいですね。
それに加えて今回の製品では、マイコンコアが2つとマイコン周辺機能が搭載されます。これらのブロックは半導体メーカーの設計資産ですが、このマイコンコアのシミュレーションモデルがないと、お客様サイドで全体シミュレーションができません。これをお客様にどのように提供するか、あるいはしないのかを決めなければなりません。
今でこそ、設計資産を提供することで売り上げを得るIPベンダーなどという業者もあって、設計資産を買ってくることも当たり前ですが、当時はまだそういう世の中ではありませんでしたし、半導体メーカーの社内資産は少なくともお客様に提供できるような綺麗な作りにはなっていないのが普通です。
過去のマイコン搭載ASICでは、こういった課題を標準化して定めて、お客様にマイコンコアをどういう形で見せるか、お客様に対して論理シミュレーションのシミュレーションモデルを、どのシミュレーターをターゲットにしてどのようなものを準備するか、ということを、ASICのシリーズ開発のたびに毎回悩んでいたようです。
自社開発品では考慮する必要の無い問題ですが、ASICではお客様が設計する、ということから、このような悩みが発生します。
この製品では、Verilog-XLの機能である、ネットリストを暗号化する機能を使って中身をわからなくして、マイコンコアのシミュレーションモデルをお客様に提供しました。
中には、回路仕様のドキュメントもろくにない、イメージ受けと言っても良いような製品もあるようですが、こういう切り口の開発は、回路仕様の最終的な確認の段階で責任の所在が不明確になるので、トラブルの元かもしれません。
この製品では、お客様の回路はお客様が設計しましたし、製品仕様は明確だったので、そのようなおかしな話にはなりませんでした。
この製品開発の課題
開発フロー上の問題
1．開発ツール選定と設計フローの構築
まず、お客様の回路をどのように設計していただいて、どのような設計データとして半導体メーカー側に提出していただくかをお客様に提示する必要があります。後の工程でトラブルが出ないように、論理設計には色々な設計制約というものがあり、これを守った設計をしていただく必要があります。
また、マイコン搭載製品に於いては、お客様の回路とマイコンコアがLSIの中で接続される訳ですが、単体LSIでは外部ピンに出ていない内部信号もマイコンコアの端子として存在する中で、誰がどうやってお客様の回路とマイコンコアを接続するのがよいのか、そしてその手順をどうするのか、これを決めなければなりません。
そして、作業分担をどうするかを明確化して、お客様にこれで行きいましょう、と提案しなければいけません。お客様と共同作業をすることになるので、お客様、半導体メーカー側の両方が仕事のやりやすい、効率的な方法を提示する必要があります。その中には、当然ながらスケジュールの話も入ります。
論理設計完了を最終的に宣言する為の論理検証に使うシミュレーターをサインオフシミュレーターと言いますが、これに何を使うかは、設計作業着手前に定義しておく必要があります。
面倒な話に思われるかもしれませんが、半導体メーカーは、公式に認められたツールを使って得られた設計・検証結果でなければ、設計結果に対して保証ができない、というスタンスを取ります。半導体メーカーが公式に認める、というのは、私がいた会社の場合は、社内のEDA部門がツールの検証を行って、EDA部門から使っても大丈夫、とリリースされる、という意味です。
世の中、半導体設計の為のツールは沢山ありますが、EDA部門がチェックしたものでなければ、製品開発には使っちゃいけません、ということです。
この製品の開発に当たっては、論理シミュレーターはVerilog-XLを使ったと思います。非常に順当な、ある意味当たり前、それ以外にあるの？というほどのツール名ですが、それを確認、合意しておくことが重要です。DFT回路（スキャン回路等）付加は、この時期はまだ内作ツールを使っていました。
なお、お客様回路は、ネットリストで頂いたと記憶しています。論理合成は半導体メーカーサイドではやっていないはずです。論理合成は色々と難しい場面がありますので、お客様サイドでできるのなら、やっていただいてネットリストとして提出していただくのがありがたいですね。
2．半導体メーカーの設計資産の提供
ASIC製品では、お客様サイドで論理設計をしていただくことから、プリミティブセル、NANDやNORなどの基本的なセルからSRAM、ROMなどといったライブラリはお客様に提出する前提で開発キットが用意されています。したがって、これらの基本的なセルライブラリはあるものをそのままお出しすることになります。ただし、メモリーに関しては使うメモリーのビット・ワード構成にしたがって、必要なものを作成してお出しします。
今でこそ、設計資産を提供することで売り上げを得るIPベンダーなどという業者もあって、設計資産を買ってくることも当たり前ですが、当時はまだそういう世の中ではありませんでしたし、半導体メーカーの社内資産は少なくともお客様に提供できるような綺麗な作りにはなっていないのが普通です。
過去のマイコン搭載ASICでは、こういった課題を標準化して定めて、お客様にマイコンコアをどういう形で見せるか、お客様に対して論理シミュレーションのシミュレーションモデルを、どのシミュレーターをターゲットにしてどのようなものを準備するか、ということを、ASICのシリーズ開発のたびに毎回悩んでいたようです。
自社開発品では考慮する必要の無い問題ですが、ASICではお客様が設計する、ということから、このような悩みが発生します。
この製品では、Verilog-XLの機能である、ネットリストを暗号化する機能を使って中身をわからなくして、マイコンコアのシミュレーションモデルをお客様に提供しました。
設計フロー概略
具体的な設計フローこの製品の設計フローは以下のようになりました。
- こちらからお出しするデザインキット、デザインガイドを元に、お客様にて製品仕様、LSIピンの仕様、電気的特性のご要求値を策定。
- こちらからセルライブラリー、デザインルール、マイコンコアのモデル（端子情報のみ）、マイコン周辺機能のモデルを提出。
- お客様サイドにて、お客様ブロックの論理設計を行っていただき、Verilogゲートネットとして設計データをテストベクタと共に提出いただく。
- こちらサイドにてお客様ブロックの受け入れ作業としてDRCによる設計制約チェック、受け入れ論理シミュレーションを実施。
- こちらサイドでLSI Topレベルのネットリスト（DFT付加前）を構築する。
- DFT回路として、モジュール単体テスト用引き出し回路、スキャン回路、JTAG回路、及びテストモード選択用テストモードセレクタを挿入する。
- DFT回路付加後ネットをお客様に提出し、お客様、こちらサイド両方でDFT回路付加後ネットの論理検証と、仮想負荷によるタイミング検証を実施する。そのために、マイコンコアのシミュレーションモデルを提供。
- 上記検証に問題なければ、1st サインオフとし、レイアウトにネットリストを払い出し。
- レイアウト作業終了後、レイアウトデータからネットリストの抽出と実負荷情報の抽出を行う。
- 抽出ネットと実負荷情報を使用して、論理検証とタイミング検証を実施する。
- 上記検証に問題なければ、2ndサインオフとして、アートワーク、フォトマスク作成、及び試作工程に入る。
DFT回路付加後のネットリスト、及びレイアウトから抽出したネットリストが元々のネットリストと論理的に等価であることの確認は、今の時代だと数学的な論理等価性を検証するFormalityやConformal LECといったツールを使うのでしょうが、この時代にはまだ社内でオーソライズされたものではなかったように記憶しています。ですから、ダイナミックシミュレーションで検証していたと思います。
また、タイミング検証についても、この頃はまだSTAによるタイミング解析の環境が整っていなかったと記憶しているので、DTAでタイミング検証をしたはずです。
その他細かな問題点
このフローに従って設計の作業を進めていけば、LSIが出来上がる、と言う訳なのですが、細かなところで色々と問題はありました。筆者が記憶している問題点で、結構厄介だったのが、お客様の論理の中で使うSRAMのインターフェース仕様の変更でした。
この製品の前の製品で使われていたSRAMは、ライトパルスが出ていないときは常にアドレスに従ったデータが出力される、という仕様だったのですが、この製品の開発を着手する前に、読み出しの時にはリードパルスを入力しないと正しくリードできない仕様に変わりました。
そして、この変更をお客様にお伝えするタイミングを逸してしまい、こちらサイドで、SRAMの外側にリードパルスを生成する回路を入れた額縁をかぶせる、という作業をして仕様の差を吸収したのです。実際の回路を作ってくれた実務取りまとめの人に感謝しなくてはいけません。
アナログ的にパルスを立てる回路になるわけですが、特性的に大丈夫かどうか、試作評価をしてみないとわからないところがあって、試作評価が終わるまで冷や汗ものでした。
論理設計について、お伝えするのはこのぐらいだと思います。次回からいよいよ評価の話に入っていこうと思います。
正直言うと、製品を担当していたときには、設計の進め方の話とかは断片的知識としては知っていたものの、自分が担当したことはなかったので、訳がわからないまま仕事を進めていたようなところがありました。随分勉強になりました。
注記
STA、DTA、形式等価判定について
LSIの開発において、集積度が増えることによってLSIに搭載可能な回路の規模は飛躍的に大きくなっています。従来通りのタイミング検証や論理検証の方法で検証をしていたのでは、テストベクタの量の増大によって検証期間が大きく増えてしまいます。
そこで、タイミング検証ではSTA（Static Timing Analysis）と呼ばれる手法が普及しています。また、論理等価性検証は、形式等価判定ツールが普及しています。
タイミング検証
クロック同期設計の回路では、回路が正しく動くかどうかは、隣り合うFFにクロック周期の時間以内に信号が伝達できるかどうかで決まります。データが伝達できる前提で設計されている回路で、決まった時間内にデータが到達できなければ、それは誤動作となります。
従来はこの検証を、実際に論理シミュレーションを実施して検証を行うDTA（Dynamic Timing Analysis）という手法で実施していましたが、検証時間を短くするために、STAによるタイミング検証を実施するのが一般的になっていると思います。
これは、FFとFFの間に挟まれたセルの遅延、負荷容量や抵抗による配線遅延の総量がクロック周期よりも小さいかどうかを全ての信号経路について計算、検証するものです。膨大な計算にはなりますが、それでも論理シミュレーションを行うよりはかなり早いのです。
ただし、STAだけでタイミング検証をOKとするのは色々な意味で恐いので、一部のテストベクタを使って、DTAと併用する場合も多いのではないでしょうか。
形式等価判定
従来は、DFT回路の付加を行った際の論理等価性やレイアウトから抽出したネットリストとレイアウトに投入したネットリストの論理等価性を検証する為には、論理シミュレーションを実施していました。
しかし、そもそもデジタル回路はデジタルの世界で動いている回路ですから、入力と出力の関係を数学的に調べれば、回路的に等価かどうかがわかる、という考え方で作られているのが形式等価判定ツールです。
論理シミュレーションを行わずに検証できるので、非常に高速です。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。