SKILL for the Skilled: Continued Introduction to SKILL++

この記事は、
Continued Introduction to SKILL++
の超訳です。

By Jim Newton on January 25, 2011

前回の記事で、階層をたどって様々な処理を行う単純だがパワフルな関数(walkCvHier)を使って、SKILL++を紹介した。もう一度、そのコードを載せる。

(defun walkCvHier (cv consume)            ;(1.1)
  (foreach inst cv~>instances             ;(1.2)
    (walkCvHier inst~>master consume))    ;(1.3)
  (consume cv))                           ;(1.4)

重ねて言うが、この関数はあくまでデモンストレーションのためのものである。読者の皆さんであれば、ちょっとした改良で、もっと複雑な階層関係を扱うことのできるロバストな関数を作ることができるだろう。この記事が改良の手助けになれば幸いである。もし、提案や質問があれば、このブログのコメントに記載して欲しい。

次からのパラグラフでは、walkCvHierの有効な使い方について説明したい。この記事で使っているソースコードは、全てSKILL++のものであり、拡張子.ilsファイル内で記述している。

Local (private) function -- 局所(Private)関数

前回の記事では、グローバル関数_reportCvを使ったreportCvHierの実装の方法を説明してた。すぐに分かることだが、SKILL++を使用すると、大域領域の名前空間を汚さずに、関数を記述することができる。すなわち、このクライアント関数を世界に見えるような形で作らなくても、walkCvHierの関数として渡すだけで実現できる。

もし、IC6.1.5を使用しているならば、新しく利用可能になったfletマクロをしようすることで、さらに簡潔にプライベート(ローカル)関数を記述できる。

(defun reportCvHier (top_cv)                  ; (4.1)
  (flet ((reportCv (cv)                       ; (4.2)
          (println (list cv~>libName          ; (4.3)
                         cv~>cellName         ; (4.4)
                         cv~>viewName))))     ; (4.5)
    (walkCvHier top_cv reportCv)))            ; (4.6)

fletマクロは、1つもしくは複数のローカル関数を定義できるマクロである。このローカル関数は、fletマクロ本体内で名前を渡すことで利用できる。このサンプルコードでは、(4.6)行が名前で参照しているところである。このreportCv関数は、flet本体内でのに、参照したり呼んだりすることができる(つまりfletが囲んでいるカッコ内)。このローカル関数は、引数として一つcvを持っている。これはSKILL++なので、(グローバル、ローカルに関わらず)関数名と変数名を(4.6)行目のように、同じように使用できる。

グローバル関数にはないローカル関数の優位点として、スコープ内にあるレキシカル変数に安全にアクセスできる、と言う特徴がある。例えば、ローカル関数reportCvから、top_cvを参照することができる。reportCv関数は、reportCvHier関数の定義内で定義されているため、reportCvHier関数が束縛しているローカル変数(引数であるtop_cvも同様)にアクセスすることができる。後に示すコード(6.4), (7.4)にも同様の例を示している。

もし、IC6.1.5が使用できない場合、下記のコードを使うと、同じことができる。この例では、無名関数を作って、reportCvHierの引数として渡している。

(defun reportCvHier (cv)                              ;(5.1)
  (walkCvHier cv (lambda (cv)                         ;(5.2)
                   (println (list cv~>libName         ;(5.3)
                                  cv~>cellName        ;(5.4)
                                  cv~>viewName)))))   ;(5.5)

Functions that manipulate state -- 状態を扱う関数

次に示す例(6.1-6.5)は、welkCvHier関数を階層内のcellViewの数を数えるために使用した例で、(7.1-7.5)はハッシュを使って、階層内で同じセルビューが何度現れるかを数えた例である。これらのケースでは、walkCvHier関数に渡されるcosumer関数は、呼ばれた関数の中で状態(この例では、カウンタとハッシュテーブル)を変化させる必要がある。

このコードに対して、伝統的なSKILLの知識でどのように立ち向かえばよいだろうか？ このcosumer関数を伝統的なSKILL関数で記述した場合、カウンタを維持するために、グローバル変数を使用する必要がある。しかしながら、この方法では次の二つの問題が生じてしまう。

1. この関数はリエントラントではない。つまり、walkCvHier関数にconsumer関数としては渡すことができないかもしれない。
2. もし、consumer関数がエラーに直面した場合、このグローバル変数は不完全な状態のままになってしまい、次にこの関数が呼ばれるときに、どのような状態になるか保証できない。

SKILL++ and state manipulation -- SKILL++と状態のハンドリング

SKILL++では、なぜこのような問題が存在していないのだろうか？ それは、グローバル変数が必要ないからである。(6.2)行、(7.2)行にあるように、変数はローカルかつレキシカルのままにできる。

countCvHierは、階層をトラバースするごとに、変数occurencesをインクリメントするために、walkCvHierに渡される。walkCvHierは、ローカル変数occurrencesのことを何も知りません。それどころか、walkCvHierで同じ変数名が使用されていたとしても、countCvHierには何の影響もありません。

(defun countCvHier (cv)                 ; (6.1)
  (let ((occurrences 0))                ; (6.2)
    (walkCvHier cv (lambda (cv)         ; (6.3)
                     occurrences++))    ; (6.4)
    occurrences))                       ; (6.5)

occureHier関数では、ローカル変数occurencesに束縛されているハッシュテーブルを変更するために、walkCvHier関数に渡すという、同じテクニックを使っています。

(defun occureHier (cv)                                             ; (7.1)
  (let ((occurrences (makeTable 'occur 0)))                        ; (7.2)
    (walkCvHier cv (lambda (cv)                                    ; (7.3)
                     occurrences[cv] = (add1 occurrences[cv])))    ; (7.4)
    occurrences))                                                  ; (7.5)

もし、SKILL++ではなくSKILLを使用しているならば、このテクニックは、失敗してしまうことを強調しておく。この問題は、ダイナミックスコープとグローバル変数に終始している。ダイナミックスコープを持った変数は、興味深く、パワフルなものであるが、このようなシチュエーションでは使用することができない。このような微妙な違いに対して、簡単に説明すると、問題は以下のようになる。

• walkCvHier関数の中ではなく、(6.2), (6.4), (6.5), (7.2), (7.4), (7.5)のように、外側で使用しないといけない。
• walkCvHier関数に渡されるconsumer関数は、walkCvHier関数内では異なる関数としてコールされるため、同じ変数を使用することはできない。
• walkCvHierのソースコードを見ないとわからない。しかし、ソースコードがない場合もある。

Purging the hierarchy -- 階層をパージする

階層化にある全セルビューがをパージしようしとした場合、(walkCvHier cv dbPurge)としようとするかもしれないが、これはいい考えではない。なぜか？ まず、同じセルビューが何度も現れているかもしれない。階層を下っているときに、同じセルビューに対して、何度もパージしたくはないはずだ。本当に必要なのは、セルビューを一度だけパージして、さらに、子どものセルビューは常に親のセルビューよりも先にパージされるような関数である。これを実現するのが、下の関数だ。

(defun purgeCvHier (cv)                           ;(8.1)
  (let ((visited nil))                            ;(8.2)
    (walkCvHier cv (lambda (cv)                   ;(8.3)
                     (unless (memq cv visited)    ;(8.4)
                       (push cv visited))))       ;(8.5)
    (mapc dbPurge (reverse visited))))            ;(8.6)

これはどのように動作するのか？ consumer関数も階層をトラバースするwalkCvHier関数も何もパージしない。consumer関数は訪れたセルビューのリストを作るだけである。walkCvHier関数は、親のセルビューにconsumer関数を適用する前に、子セルビューの階層を下っていくので、purgeCvHier関数では単にSKILLのpushマクロを使用して、親セルが子セルよりも先(左)に並ぶリストを作っている。この問題(親セルが子セルよりも先に並ぶと言う)は、reverse関数を呼ぶだけで解決できる。

walkCvHier関数をもっとロバストに実装するためには、次の2つのconsumer関数を使えば良い。一つは、子セルに階層を下る前に適用する関数で、もう一つは、階層を下った後に適用する関数である。もしくは、consumer関数の適用を階層を下る前か後かを指定するために、walkCvHier関数のオプショナル引数として用意するのもよいだろう。

More about flet -- flet関数についてもう少し

局所関数が定義できるfletには、重要な制約がある。それは、自分自身を再帰的にコールすることができないことと、一つのfletマクロ内で複数の局所関数を定義したときに、お互いをコールできないことである。これについて、最初は制約だと思うかもしれないが、後の記事で説明するが、実際には重要な機能なのである。もし興味があるならば、このブログ欄にコメントして欲しい。

もし、局所関数を再帰的に呼びたいのであれば、labelsを使って、他の関数をコールするような、幾つかの局所関数を書いてやれば良い。シンタックスはfletと同じであるが、スコープのルールは異なっている。

Common LispやEmacs LispのようなLispの方言は、fletとlabelsの両方を提供している。

Summary

SKILL++の機能について、基礎と応用例を示した。局所関数の機能を使うと、モジュール化を維持したまま、よりコードに情報を含めることができる。さらに、SKILL++を使用した方が、問題を直接的に記述することができる。

参考資料

• Lexical vs. dynamic scoping
• flet and labels in Common Lisp and Emacs Lisp.

Jim Newton

HSPCIE SIG 2011 in Japan

昨日は、http://www.synopsys.co.jp/events/seminar/hspice_sig/index.html に行っておりました。
本当は、懇親会等で伝えればよかったと思ったのですが、何となくフラフラっとそのまま外に出てしまって、モヤモヤっとしているところがあるので、ブログに書きます。

HSPICEの強みとは

日本における回路シミュレータの使い分けを見ると、半導体ベンダでは、ほぼ2つに集約されるでしょう。CadenceのSpectreとSynopsysのHSPICEです。さて、この使い分けは？　ざっくりとは

• Spectre: Pure Analog, Pure RF, Mixed-Signal
• HPSICE: 上記以外、セル設計, Signal Integrity between Chip and Package

と言う感じを持っています。そして、今回のイベントでもユーザトラックと言いつつ、Pure Analog系の人が誰もいなかったことが雄弁と状況を語っているように思えます。

アナログに関して、なぜHSPICEのポジションが低いかというと、アナログの設計環境が各社ともCadenceであり、Spectreはその設計環境(Virtuoso)とタイトに連携しているため、HSPICEとは言えども牙城が崩しにくいところではあります。

一方で、Signal Integrity, Power Integrityなどの解析では、Sパラメータを等価回路モデルとして、過渡解析で解く必要があります。ここは、HSPICEの独壇場となっており、数百を超えるポートを持つSパラでも解析することが出来ています。また、収束性もなかなかのものです。

今後もこのような使い分けが続くのだなぁ、と、確信したイベントでもありました。

電磁界ソルバとの連携

上でも書いたとおりですが、SI/PIの解析には、等価回路にはSパラメータが標準となっています。しかしながら、Sパラメータは周波数テーブルです。ある周波数でのポート間の伝達関数が数値で記載されているだけです。このような周波数テーブルをシミュレータは受け取って、時間応答を計算しています。

要は、周波数応答を逆フーリエして、時間応答にしているわけですが、困るのが、周波数テーブルは離散値であって、連続値ではない。つまり、回路シミュレータが必要としている特性は、周波数テーブルから適当に補間して求めることになっています。ここで矛盾が生じると、発散などの憂き目に合ってしまいます。

HSPICEは優秀なシミュレータで、Sパラテーブルの補間方法が非常に充実しているので、結構ヒドイSパラでも解くことができます。しかし、少し限界があるのではないでしょうか？

今の問題は、情報が電磁界ソルバから回路シミュレータ側に一方通行になっていることだと思っています。逆に回路シミュレータ側から、「この付近の周波数が足りないから、電磁界ソルバで再計算してよ」と言う文句を言ってくれてもいいと思っています。

非常に難しいことだとは思うのですが、HSPICEの中では、高度な補間計算をしたり、有理関数を作ったり、Sマトリクスを自動的に分割して、とか、さらに高度なことをやっているような気がするので、上記のサジェスチョンくらいできるのではないか、と思ってしまいます。

ネットリストの革新

HSPICEなのかSPICEなのかはわかりませんが、誕生してから30年だそうです。この間、DC収束法、積分法、マルチテクノロジの解析、など色んな革新があったと思います。しかし、唯一変わったと思えないのが、ネットリストのシンタックスです。

HSPICEの新機能の紹介などで.StatEyeとか、.TranNoiseとか見るたびに、「レガシーやなぁ」と感じてしまいます。ぼちぼち革新しませんか？　現状のネットリストでは、拡張に拡張を繰り返しているため、

• パラメータパッシング(グローバルかローカルか、見た目でわかるようにしてください)
• オプションの有効範囲
• 各種記述の豊富さ(抵抗素子一つをとっても記述方法が多すぎる)
• includeによる他のテクノロジの読み込み(Verilog-Aモデルとか、インラインで読めるようにしませんか？)
• 構造記述は.subcktのみ

などなど、私にはカオスになっているように思えます。デジタルとの協調シミュレーションがいまいち進まないのも、SPICEのレガシーさが足を引っ張っているようにも思えます。

どこかのタイミングで、SPICEのネットリストを捨てて、Verilog-AMSにしませんか？ 素子レベルの記述も可能ですよね。もしくは、新フォーマットを考えもらってもいいですよ。

各々のシミュレータのネットリストコンパチビリティなんて、不要なので、統一的なSPICE2.0を考えていきたいものです。

How to Design Analog/Mixed Signal (AMS) at 28nm

この記事は、
"How to Design Analog/Mixed Signal (AMS) at 28nm"
の超訳です(^^;

ワイヤレス、ネットワークチップ、データセンター用、計算機用、FPGAアプリケーション用のLSIは、低消費電力化、高速化、小面積化を実現するために、積極的に微細化を進めてきた。今日、これらのアプリケーションは、アナログ/ミックスドシグナル(AMS)回路やRF回路をデジタル回路の中に集積され、年々占める割合が大きくなってきた。特に、AMS回路がチップ面積の50％以上を占めるようになると、プロセスマイグレーションするときに、これまでのやり方では、微細化の優位点が小さくなるどころか、むしろ優位点が全くなくなるようになってきた。

今日では、1世代の微細化でも物理効果やデバイス性能が大きく変わるため、単純なマイグレーションだけでは、スペックを満たせない。AMS回路はスペックを満たすように最適化をするとともに、再デザインが必要なことが多い。このため、先端プロセスでは、デジタル設計と同時か、もしくはそれよりも早くAMS設計フローを構築する必要がある。

2011年3月のCadence Mixed-Signalセミナーで行われたアンケート(150を超える企業の設計者とCADエンジニアから回答があった）によると、65nmが主流になっていることがわかった。また、40〜28nmでもAMS回路が設計されていることがわかった。

Figure 1 - Analog/mixed-signal designers look to lower process nodes
(オリジナルのブログを参照)

Challenges of Advanced Process Nodes

先端プロセスでAMS回路を設計する場合、既存の問題だけでなく、新たな問題にも直面する。主な問題は、パラメータのばらつき、デバイスの信頼性、レイアウト依存効果、そして設計期間(生産性)である。

従来、回路性能がスペック値の真ん中になるように(デザインセンタリング)、パラメータ変動の影響を分析したり、よりロバストな回路トポロジを採用したり、統計解析を行うなどして、設計を行っていた。先端プロセスにおけるアナログ回路設計では、パラメータ変動やプロセス変動に対処するために、セルフキャリブレーションを行う必要性に迫れている。セルフキャリブレーションは、デジタル回路で構成されるため、ピュアなアナログ設計技術だけでなく、ミックスドシグナルのデザインフローが必要となる。

また、先端プロセスのデバイスは、TDDB(経時絶縁破壊), HCA(ホットキャリアによる劣化), NBTI(負バイアス温度不安定性)などの影響を非常にうけやすい。長期間にわたって、高電圧を受けた場合、このような現象によりデバイスは破壊されてしまう。そのため、設計初期段階における信頼性シミュレーションによって、どのデバイスが過電圧になりやすいか、を特定することは非常に重要である。

レイアウト依存効果(LDE)によって、デバイス電流やしきい値電圧は周りのレイアウトの形状により変動する。特に、ウェル近接効果やストレスの影響により、10%以上の変動が起こることもある。設計最終段階でのレイアウトの修正やスケジュールの遅延を避けるために、レイアウト依存効果が回路の性能に与える影響を理解しておっかなければならない。特に、感受性の高いデバイスを特定して、それらをより変動が少なくなるように、周りの影響を考慮しなければならない。

このように先端プロセスにおいては、クリアしないといけない課題が多い。そのため、デザインの生産性を維持するために、より進んだ設計ツールが必要となる。

TSMC AMS Reference Flow

AMSリファレンスフローを通して、CadenceとTSMCは28nmプロセスにおけるAMSの設計課題を解決するために密接な関係を築いている。このコラボレーションによって、AMS V1.0を昨年(2010年)リリースし、さらに、今月(2011年6月)、AMS V2.0をリリースした。AMS V2.0には、レイアウト依存効果を考慮したレイアウト手法、先進的なモンテカルロ解析、デバイス信頼性解析、アナログドリブンのサブ回路最適化(ABS)、3D-IC/パッケージを考慮したマルチテクノロジシミュレーション(MTS)が含まれている。

Figure 2 - Cadence track in TSMC AMS v2.0 Reference Flow
(オリジナルのブログを参照)

AMS2.0では、レイアウト依存効果の計算エンジンは、Virtuoso設計環境に完全に組み込まれている。これにより、レイアウトデザイナーは、デバイスを配置した位置でのVthと飽和電流の変動を直ちに知ることができる。Virtuoso-ADEで使用されているWorst-Case Distanceを使用した歩留まり見積もり技術は、10000万サンプルの中から任意に抜き出した200サンプルで検証した結果、1%以内で合っていることがわかった。

デバイス信頼性の問題に対しては、Virtuoso-ADEのSpectre/APSのアサーション機能が役に立つだろう。これにより、デバイスがオーバードライブされたときに、知ることができる。また、Virtuoso-ADE-GXLにある回路最適化技術は、アナログセルのリターゲティング時に使用することができるだろう。さらに、Spectreのマルチテクノロジシミュレーション技術とAllegro SiP ArchitectとVirtuosoの連携により、3D-ICの検証も可能となる。

TSMC AMS V1.0, V2.0のフローを築くことによって、Cadenceは28nm世代におけるAMS回路の生産性、予測性という点で大きな強みを持てた。TSMC AMSリファレンスフローについて、さらに知りたい場合は、私かTSMC,Cadenceの担当者に聞いて欲しい。

Mladen Nizic

3D-IC TSV Realization: The Race Has Begun!

この記事は、
"3D-IC TSV Realization: The Race Has Begun!"
の翻訳です。誤訳がふんだんに含まれていると思いますので、詳細は、オリジナルの英語のブロクを参照してください。

今日では3D-ICはバズワードとなりつつある。特に、3D-ICに触れない学会はほとんどない。これは、TSVを使用した3D-ICが性能と消費電力の面で大きな利点があり、現在急速に成長しているネットワークやグラフィックス、ワイヤレス、コンピュータ産業などに大きなインパクトを与えるからである。そして、消費者は非常に軽く薄い電子機器を求めていることも重要である。

もし、メモリやGPUに関わっていたり、アナログ回路やRFコンポーネントに関わるデジタル回路を設計しないといけない人であれば、私が言うことはよく理解できるだろう。また、今、3D-ICに関心がないならば、知るのにいいタイミングだろう。

What's Needed for 3D IC Realization -- ３D-ICの実現には何が必要か？

3D-ICの実現には、幾つかの技術的な課題がある。

• デジタル・アナログのパッケージング内の集積化: これは、異なったプロセスを積層するような場合、例えば、アナログ回路、RF回路、ロジック回路、メモリなどのヘテロチップを積層する場合に、必要となるものである。このプラットフォームが実現できなければ、どの解も不完全なものとなる。
• 3Dプロアプランニングと配置配線: この環境は、TSVを支えるマイクロバンプの配置や、タイミングの最適化、熱管理、多数の層を横断する信号線と電源線の最適化、パッドの配置、を実現するために必要な技術である。
• 熱解析とIRドロップ解析: シグナルインテグリティ、IRドロップ解析、熱解析と熱のマネージメントは、チップ積層において非常に重要な問題と鳴っている。もし、何の考慮もなしにメモリ回路とロジック回路を積層した場合、チップ(特にメモリ)が動作しなくなることは容易にわかるだろう。ヒーティングもクーリングも重要な点である。
• テスト容易化設計: 最近のLSI関連の学会における３Dのパネルディスカッションでは、三次元のDFTが大きな課題になりつつある。どのようにして、全体のシステムを検証すれば良いのか？ また、故障の可能性をどのようにして診断するのか？ またスタックすることによる歩留まり悪化は、誰が保証するのか？ ファウンダリか、OSATs(Outsourced Semiconductor Assembly and Test)か?
• システムレベルの最適化: 3Dのフロアプランニングも重要な課題であろう。しかしながら、私はこの種の議論をする前に解決すべき別の問題がたくさんあると思っている。

私は、このようなデバイスを実現するために、上記の技術について、数年前に研究を始めた。私には、22年前に3D-ICの記事を書いた同僚を知っている。しかし、現在では、3D技術が実現性を帯びており、さらにニーズが差し迫ったものとなっているため、より現実的に考えることができる。Mooreの法則はもはや今までとは意味合いが異なり、"More Moore"がCMOSの微細化を意味し、"More than Moore"が三次元化を意味している。

我々は、実際のチップをテープアウトした顧客にとって、魅力的に思えるようなものを持っている。3D-IC技術は、当初破壊的な技術のように思われるかもしれない、しかしながら、性能と電力両方に対して大きな利点がある。そのため、この技術の開発には、今までとは異なった戦略を取れる数少ない人間によってもたらされるであろう。

競争はすでに始まっている。

あなたはすでにその中にいますか？ あなたがこの技術に関してどのようなアクションをとろうとしているか教えて欲しい。

Samta Bansal

SKILL for the Skilled: What is SKILL++? (訳)

本記事は、
"SKILL for the Skilled: What is SKILL++?"
の訳です。誤訳がふんだんに含まれていると思いますので、詳細は、オリジナルの英語のブロクを参照してください。

ここから

関数の扱い方という点で、SKILL++は従来のSKILLとは異なっている。この記事では、SKILL++でデザインの階層をたどっていく方法を紹介することで、SKILL++を紹介したい。

What is SKILL++?(SKILL++とは何か？)

SKILL++はSKILLとは異なる言語だと考えているかもしれませんが、実際にはSKILLのサブセットです。SKILL++の構文は非常に小さいものですが、1990年代中頃には、SKILLコアに強力な拡張性をもたらしました。そして、今ではたくさんのCadenceツールの中で使用することができます。実際、SKILLがロードされ実行されるプログラム(例えば、Virtuoso, VirtuosoXL, pipo, Assura, Dracula, PVS, Allegro-PCB, cdnsip, その他色々)であれば、SKILL++で置き換えることができます。

基本的な言語の機能は以下のとおりです。

• レキシカルスコープの変数
• 単一関数/変数名前空間(Lisp-1)
• CLOS準拠のオブジェクトシステム

対照的に、SKILLはダイナミックスコープの変数システムであり、変数と関数の名前空間も別々であった(Lisp2)。ダイナミックもレキシカルスコープもどちらもそれぞれの目的を達成するために便利なものである。

What are dynamic and lexical variables? (変数におけるダイナミックスコープとレキシカルスコープとは?)

この二つの違いは文法的なものではなく、セマンティックなものである。SKILL++に現れる変数は全てレキシカルスコープであるのに対して、SKILLでは、全ての変数はダイナミックスコープである。

両者のセマンティックの違いは以下のものである

• ダイナミック変数は、SKILLが実行中(つまり、関数もしくは、その関数から呼び出された関数が評価を一時停止している間)に特定の値をコントロールするための仕組みである。この評価が一時停止している期間では、ダイナミック変数は、明示的に他の閉じた環境に隠蔽されない限りは、大域環境から見ることができる。
• レキシカル変数は、関数からオブジェクトの可視性を分離するためのものである。そのため、限られた表現のみでしか、名前を通して値にアクセスすることができない。評価が一時停止している間でもアクセスすることはできない。

Perceptions of SKILL++

この記事では、SKILL++のオブジェクトシステムについては説明せずに、SKILL++の上の二つの特徴について述べる。ここは、SKILL++がSchemeの方言と呼ばれる部分である。残念なことに、他のSchemeの方言は市場に通じる名前を持っていない。そのため、我々は、SKILLの名前を借りて、SKILL++ Scheme方言ではなく、SKILL++と呼ぶことにした。

もし、SKILL++をまだ使ったことがないなら、基礎はあなたが考える以上にシンプルであることに驚くだろう。
また、もしSKILL自体が初めてだとしたら、SKILL++が簡単でかつ直感的であることに驚くだろう。もし、あなたがベテランのSKILLプログラマだとしたら、あなたがSKILLを学び始めた25年前と同じように、SKILL++を使えるようになるであろう。つまり、あなたは既に困難なことは習得済みなのである。今や簡単に習得することができるだろう。

How to create SKILL++ code(SKILL++コードの作り方)

SKILLインタプリタにSKILL++として解釈させたい場合、プログラムの拡張子に.ilsを付けるだけで良い(ちなみに、.ilはSKILLプログラムのことである)。つまり、file.ilsはSKILL++プログラムと解釈され、file.ilはSKILLプログラムと解釈される。

ここから先に出てくるコードは全てSKILL++用のものである。

SKILL++ by example

最初の例は、walkCvHierである。これは、デザインの階層を辿る最もシンプルなプログラムである。あなたが必要な機能は満たしていないが、例としては分かりやすいものである。

(defun walkCvHier (cv consume)              ;(1.1)
  (foreach inst cv~>instances               ;(1.2)
    (walkCvHier inst~>master consume))      ;(1.3)
  (consume cv))                             ;(1.4)

この関数は、引数の一つに関数をとっている。すなわち、高階関数である。後の記事で紹介する予定であるが、SKILL++では、引数に応じて、実行時に他の関数を作ったりすることが可能である。SKILLでも高階関数をつくることは可能であるが、もし、高階関数を作る必要があるならば、常にSKILL++を使ったほうがよいであろう。

これは、どのように働くだろうか？ walkCvHier関数は、指定されたcell view(例えばlayout view)を通って、下層のインスタンスマスターに階層ダウンする。それぞれの階層で、引数として与えた関数が適用される。関数がその引数としてcellViewを取れる限り、関数を実行することができる。walkCvHier関数は階層を持ったcellViewと関数を指定したら、全てのインスタンスに対して、関数が実行される。

Saving the hierarchy?

walkCvHierを使用した例を示す。saveCvHier関数は、階層内の全cellViewに対して、dbSaveが呼ばれるように、walkCvHier関数に渡したものである。

(defun saveCvHier (cv)        ;(2.1)
  (walkCvHier cv dbSave))     ;(2.2)

walkCvHier関数は、1.1行で宣言されているように、ローカル変数consumeを持っている。そして、consumeは、1.4行で関数呼び出しの位置(consume cv)で使われている。このプログラムはSKILL++なので、consumeと言う大域関数を参照しているのではなく、consumeと言うローカル変数に束縛されているモノを使用しているのである。今の場合、consumeが束縛している値は関数である(単なる変数が束縛されている場合、実行時エラーとなる)
。2.2行目では、saveCvHier関数は第2引数としてdbSave関数を呼んでいる。以下に、このプログラムの重要な点を書く。

• 2.2行目のdbSaveの指定時にクォート(')を付けていない。なぜだろうか？　これは、SKILL++では大域関数の名前を変数名と同様に扱えるためである。
• consume関数は、1.4行で通常の関数と同じように呼び出されている。なぜだろうか？ SKILL++では大域関数もローカル関数も同じ文法で呼び出すことができるからである。
• consumeと言う名前は、camlケースでもアンダースコアでも書かれていない。真にローカル変数の命名ルールに従っているからである。

Reporting the hierarchy(階層的なレポーティング)

階層ツリーでdbSaveを呼ぶのではなく、ビルトイン関数ではない何かを呼ぶことを考える。例えば、階層を下っていって、cellViewが見つかるたびにcellViewの情報をレポートしたい場合、一つのcellViewの情報を出力する関数を定義してやればよい。一つの方法としては、以下のように、_reportCvと言う補助関数を定義する方法である。

(defun _reportCv (cv)                 ;(3.1)
  (println (list cv~>libName          ;(3.2)
                 cv~>cellName         ;(3.3)
                 cv~>viewName)))      ;(3.4)
                                      ;(3.5)
(defun reportCvHier (cv)              ;(3.6)
  (walkCvHier cv _reportCv))          ;(3.7)

ここで、_reportCvはプライベートな関数であり、一度しか呼ばれないにも関わらず、_reportCvはdefunで定義されているため(procedureでも同様)、大域の関数になってしまう。すなわち、プライベートな状態にはならないのである。過去、SKILLでは名前付けの慣習やドキュメントに記載することで、アクセシビリティを実装していた。SKILL++では、もっとシステマチックな方法で、データを隠蔽することができる。

...to be continued...

つづく

What's next?

次回の記事では、局所関数、クロージャ(状態を持った関数)、そして、walkCvHierの別の例を示す。

Jim Newton

UVM-MS - Metric-Driven Verification for Analog IP and Mixed-Signal SoCs

本記事は、
"UVM-MS – Metric-Driven Verification for Analog IP and Mixed-Signal SoCs"
の訳です。誤訳がふんだんに含まれていると思いますので、詳細は、オリジナルの英語のブロクを参照してください。

デジタル回路の機能検証に用いられるメトリックドリブンな検証方法と制約のついたランダムパターンの生成は、アナログIPの検証やミックスドシグナルSoCの検証にはほとんど使われない。しかし、この文化もUVM-MSと言うCadenceとLSI社がDVConで発表する方式で変わるかもしれない。

UVM1.0はAccelleraによって、まもなく標準化されるであろう。CadenceとLSI社はUVMの元となったOVMでミックスドシグナルのメトリック検証の取り組みをスタートさせた。去年のシリコンバレーで開催されたCDNLiveで発表したSoC Realizationの論文は、今年のDVConで発表するアナログIPとミックスドシグナルSoCのOVMベースの検証手法の予告となったものである。

今回のDVConで発表される"UVM-MS: Metrics Driven Verification of Mixed Signal Design"と言う論文は、CadenceのNeyaz KhanとYaron KashaiとLSI社のHao Fangが書いたものである。私はNeyazとYaronに詳細を聞いた。

Metric-Driven for Analog - アナログにおけるメトリックドリブン検証とは

メトリックドリブン検証方法とは、実行可能な検証プラン(vPlan)とテストパターンの自動生成、そして検証カバレッジの進捗をトラックする、と言う包括的な検証方法のことである。この方法により、いつ高品質な検証が達成できるか、を知ることができる。MDVのフローは以下のとおりである*1

では、なぜこのアプローチをアナログとミックスドシグナルにも適用しようと考えているのだろうか？ Neyazは次のように指摘している。「SoCの中でのアナログの占める割合が増えている。それに比例して、検証の数が増えている。特にアナログとデジタルのインターフェースの部分だ。」さらに、Neyazは「過去10年から15年にわたり、デジタル側ではMDVの適用によって、大きな進展があったにも関わらず、アナログ側では何も進展していない。」と言う。

UVM-MSは周波数やゲインの測定と言った機能のカバレッジを第一とした手法である。例えば、可変アンプのゲインが所望通りのスペックになっているかどうか検証したいとしよう。このアンプを検証するために、指定された入力周波数レンジをカバーする入力信号を自動生成した後に、ゲインの設計レンジが完全にテストされたかどうかを確認するための自動チェッカとともに、機能カバレッジを使うことができる。

アナログ検証を行うために、この手法ではアナログのパラメータを測定する"signal ports"を作成するためにe言語を使用する。Neyazは、「SystemVerilogの制約のため、UVM-MSは現在のところe言語をベースにしている。しかし、最終的にはSystemVerilogと協調するつもりだ」と言っている。Cadenceは、MDVがUVMに代わる手法だと業界団体に提示している。

Supporting Existing Styles - 既存の方法のサポート

アナログシミュレーションは、伝統的にインタラクティブ実行であり遅い、それに対して、デジタルはバッチ実行であり速い。設計者はこのギャップをどのようにして埋めることができるのか？ UVM-MSは全てのアナログのドメインをサポートしている。例えば、SPICE, Verilog-AMS, 実数モデルをサポートしている。さらに、速度と精度のトレードオフも考慮できる。低レベルなアナログの動作は、ハードウェアの検証コード下で実行されるVerilog-AMSが担当する。コンポーネントライブラリは、アナログ信号とテストベンチの間のインターフェースに使用される。

全体の検証手法に関して、Yaronは次のように言っている。「デジタル回路におけるメトリックドリブン検証と全く同じある。ただし、アナログ回路を統合を手助けするために、ある種のものが必要となる。このように、モデルはテストベンチと固く結びついてしまう。ここがアナログ設計の検証環境が少し異なっているところある。アナログポートと通信するためや、アナログ信号をドライブするために、これらのデジタルブロックをインスタンス化する必要があるだろう。」

Neyazは、この手法は、チームがアナログIPの検証に時間を費やす必要があるだろう、と指摘している。さらに「IPが一度設計されると、多数のチップに使用されるため、高品質のIPを持つことは、良い投資になるだろう」と言っている。論文では、LSI社の現在の設計が、どのようにコンセプトの検証をしているか、について詳細を述べている。

(最後の1文は省略。学会の情報などが書いてました)

Richard Goering

*1:Cadenceのブロクを参照

DAC Panel: Users Describe Mixed-Signal Verification Challenges, Solutions

この記事は、Cadence社のブログを訳したものです。
http://www.cadence.com/Community/blogs/ii/archive/2011/06/13/dac-panel-users-describe-mixed-signal-verification-challenges-solutions.aspx
(This article is quoted from Cadence's Blog with translation from English to Japanese.)

DACパネル: Mixed-Signalの検証のチャレンジとソリューションについて、ユーザーが語る。

by Richard Goering on June 13, 2011

アナログ/ミックスドシグナルの検証はデジタル回路の検証のように、検証専門チームにより、統一検証手法(UVM)やメトリクスドリブン検証手法(MDV)が取り入れられた方向に進むのだろうか？　「そうなるだろう」と、6/8にCadence EDA360で行われたパネルディスカッションで、ミックスドシグナルのエンジニアが答えた。

パネルは、"考えることをやめ、行動を始めよう。- 検証漏れを無くすための手法"と銘打たれた。パネリストは、以下の3つの質問に答える形で進行した。

• なぜミックスドシグナルの検証は、チャレンジングとされるのか？
• あなた達は、今日の課題に対して、どのように立ち向かっているのか？
• EDAツールに求められるものは何か？

私は、モデレータとして参加した。そして、パネリストは以下のとおりである。

• Jonathan David, senior staff engineer, Qualcomm (speaking in photo below)
• Martin Barnasconi, product manager for AMS/RF System Design Methodologies at NXP Semiconductors (seated at left)
• Hao Fang, senior design manager, LSI (seated in middle)

どのパネリストもこのミックスドシグナル検証の課題、解決法、EDAツールへの要望について、短いプレゼンテーションを行った。

Qualcomm: Speed, Power, and Timing Closure

Davidは、彼のグループが検証したワイヤレストランシーバー(プロセッサ、A/D, D/A, フィルタが含まれる)のブロック図を見せた。その図を使用しながら、まず、アナログ/ミックスドシミュレータがとても遅いことを説明した。特にRFの周波数をもった信号を同時に解析する場合、非常に遅くなる。次の課題は低消費電力設計に関してである。アナログ回路の消費電力は、回路図に直接現れているが、デジタル回路は、CPFのような消費電力専用のファイルとして表されている。

タイミングクロージャーはもうひとつの問題である。タイミング解析ツールは、ミックスドシグナルを含んだネットリストを解析することはできない。例えば、テストパターンを自動生成するATPGは、RTLがないデザインを扱うことはできない。しかし、チップをテストするためには、テストベクタを生成する必要がある。最後に、典型的なアナログのボトムアップ設計では、アナログと他の部分を統合するのが非常に遅いため、テスト期間が短くなってしまう。

Qualcommが使っている一つの解は、アナログ値とデジタル値を両方表現できるように、実数でモデリングすることである。しかしながら、この方法は、モデル開発と検証に追加のリソースがかかる。また、EDAへは、モデルの自動生成ツール、回路図からの消費電力の自動抽出、ミックスドシグナルの寄生素子を含んだタイミング解析、ミックスドシグナル対応のATPG, Virtuoso Analog Design Environment (ADE)　上でのUVMのサポートを挙げた。

アナログ検証チームを別に作るか、と言うことに対して、Davidは科学フィクション作家のDavid Brinの言葉「criticism is the only known antidote to error」を引用して、回路を設計した人とは、別の人が検証すべきである、と言うことを主張した。また、「OOPやUVMでの検証を始めるに当たって、アナログ回路に精通した人を集める必要はない。アナログの検証を行う技術は、設計とは分けるべきだろう」とDavidは主張した。

LSI: Increasing Digital Circuitry Calls for Changes

最初に、LSI社及びFang氏のバックグラウンドを説明する。Fangは、以前ブログで説明したDVConで発表したUVM-MSのCadeceとの共著者である。なので、彼がDACでデジタルの検証をアナログの世界にも導入すべきだ、と言ったのは自然なことである。

HDDに搭載されるLSIには、read-channel SOCだけではなく、プリアンプや顧客のtranceducerなどが搭載される。プリアンプには、超Gpsのデータレートの実現、多チャンネル化、有損失回路での伝送など、大きな技術的課題がある。"Large A, Small D"のデザインは、デジタルアシステッドの回路やキャリブレーション、トリミング、パワーマネージメント、テスト回路の増加によって、"Large A, LargeD"の回路になると、Fangは述べた。

LSI社では、現在、アナログブロックのシミュレーションをSpectreで、デジタルブロックの検証をUVMで、チップの最上位レベルの検証をAMSシミュレータで行っている。CadenceとLSI社はこれらのシミュレーションの高速化に共同でとりかかっている。今、必要なことは、専任のデジタルとアナログの検証チーム、実行可能な検証プラン、セルフチェックテストベンチ、アナログカバレッジ、アナログアサーションであると、Fangは指摘している。Cadence Accelated Paralles Simulator (APS)を使用すると、4倍以上に高速になる、とFangは言う。

近い将来、ミックスドシグナルからアナログの検証までUVM-MSが使用されると、Fangは指摘している。Fangは、「ボトムアップのアプローチではなく、設計と検証をスペックからドライブするためには、トップダウン的なアプローチが必要だろう」とFangは言っている。

NXP: Verification from Chip to System

NXPでは、チップの検証だけでなく、ネットワークシステムを含めて検証する必要がある。そのため、アナログ/デジタル、また、ハードウェア/ソフトウェアの垣根なく、協調検証をする必要がある。NXPのシステムには、トランシーバーなどのアナログ/ミックスドシグナル回路、コントローラなどのデジタル回路、そして、組み込みソフトウェアがある。フェイルセーフシステムを保証するために、カバレッジベース、アサーションベースのミックスドシグナル検証技術が必要だと、Baranasconiは言う。

「我々は、スペックからデザインをどのように生み出すか？また、検証プランからテストベンチをどのように生み出すべきか？」という問に対して、NXPは"Structured"アナログ/ミックスドシグナル検証手法を導入したと答えた。NXPは、プロプライエタリの検証用IPをミックスドシグナルフローの自動化のためと、セルフチェックテストべンチの作成のために使っている。

今日の課題は、UVMやMDV、アサーションべースの手法をアナログ/ミックスドシグナルに導入する道筋をつけることである、とBarnasconiは言っている。彼は、Open SystemcC InitiativeのAMS working groupのチェアを勤めており、そこでUVM, SystemVerilog, SystemCのAMS拡張を行なっている。

Much Work Ahead

Q&Aの時間では、デジタルの手法をミックスドシグナルの検証に持ち込むことの様々な課題(今日のアナログ設計者の技術、アナログにおけるカバレッジの意味合い、アナログアサーションの開発、ミックスドシミュレーション言語のサポート、直接的、ランダム的テスト)が明らかになった。

最後に、Qualcomm社のDavidが「もし、十分な人を集めずに、新しい検証手法を試そうとしたら、思うようにカバレッジを挙げられずにテープアウトを迎えるリスクがあるだろう」と述べた。「私なら十分な人を集めて、リスクが少ない状態にして、プロジェクトを進めるだろう」「そして、プロジェクトへのこの手法の適用が全てのプロジェクトのリスクを緩和する方向に進むだろう」とDavidは言った。

Richard Goering