LPB FormatはM-Foramt, C-Format, R-Format, G-Format, N-Formatの
5つのフォーマットで構成されています。その中のG-FormatはLSI、パッケージやプリント基板などのレイヤスタックアップ構造 のレイアウトデータを定義するためのフォーマットで、 構想設計時の電気・熱解析を手軽に行うことを主目的としたものです。
構想設計時にPower PointやVisio等のドローイングツールを使って プリント基板のフロアプランや配線パターンを検討することがあります。 これらのドローイングツールは手軽に使えるものの、検討した配線パターン の電気特性を解析するには解析ツール上でパターンをトレースし直す必要がありました。 また検討結果を次工程のEDAツールに直接引き渡すことも渡すこともできませんでした。 G-Formatは構想設計段階で電気・熱解析を手軽に行いたい、検討結果をレイアウトEDAツールに 正確に伝達したい、という要望から策定されました。 G-Formatは単純な図形情報に解析に必要な層構成と素材の物理パラメータを追加したものです。 非常に単純な構造なので簡単なプログラムで自動合成することも容易です。
G-Formatは手軽にレイアウトを表現できる半面、基板製造に使えるほどの精度は有りません。 従ってレイアウトEDAツール間でのデータ交換は目的としていません。 またGerberやODB++のように製造工程への情報伝達も目的としていません。 あくまでも軽量さを重視し、構想設計時の電気・熱解析を手軽に行うことを目的としたものです。
本連載では具体例を示しながらG-Formatの文法を解説していきます。 また応用例としてG-Formatを使った電気特性の解析例を紹介します。 実際に手を動かしながらG-Formatを学ぶことができるように配慮しました。
なお、本書では実際のツールを使った解析例を示しますが、例示されている解析例に 関するご質問は JEITA SDTCまでお願いします。 ツールの開発元にお問い合わせることはご遠慮頂きますようお願いします。
G-Format裏話
いきなり裏話から入って恐縮ですが、まず最初にG-Formatの不思議な 部分の説明から始めます。 仕様書をご覧になればわかると思いますが、G-Formatは他のFormatとは 違った部分が多くあります。まず言語の書式自体が違います。 方言やバグではないかと思われるような仕様も含まれています。 それらはG-Formatの成り立ちに起因しています。
元々、半導体&システム設計技術委員会は現在のLPB Formatのような 標準言語を制定することは目的とはしていませんでした。 EDAツール間でインターフェイス用のファイルフォーマットが統一されていないことは、 協調設計における問題ととらえていましたが、当初は設計言語を作ることは 考えていませんでした。 すでに存在するデータフォーマットの中からインターフェイス用に使用する ものを決めて、それを標準的に使うように推奨していこう、と考えていました。
ところがいざ始めてみると既存のものは協調設計では不要なほど詳細で有ったり、 想定する範囲をカバーしていなかったりと、一つのデータフォーマットだけでは 目的を達することが難しいことが分かりました。 しかし、それ以上に問題となったのは権利関係（ライセンス）でした。 一般公開されているように見えても他社のEDAツールが読み書きするとなると ライセンスが障害となりました。 いいところまで話が進んだのに土壇場でひっくり返されたことも有りました。 結局、ニュートラルな立場で作ってしまおうと作成したのが、 C-Format, R-Format, M-Formatです （ネットリスト(N-Format)は既に標準化されているVerilogを使うこととしました）。
G-Formatですが、これは幸いなことに、当時ワーキングに参加されていた ベンダー様から「一つ古い」バージョンであれば使用しても構わないとの 許可を頂くことができ、それを採用しました。 現存するフォーマットということもあり、幾つかのEDAツールに それを入力する機能が実装されており、すぐに実務で使用できるという メリットもありました。 その後のM&A等のが有り、現在ではANSYS/Mentor/図研等の主要EDAベンダーが G-Formatの入力機能を備えており、LPB Formatの中では最も普及している 言語となっています。
ただし、半導体&システム設計技術委員会で標準化する前に流通していた 言語であるため、ツール毎にフォーマットの解釈の齟齬が発生していました。 仕様がバグっているのでは思われるような部分もあります。 すでの実務で使用されていたこともあり是正が難しく、 「そうなっていたから」と甘受した部分があります。
委員会では可能な限り是正しようとしていますが、未だ完全ではありません。 とは言えLPB Formatの中で最も多くのEDAツールが対応しているFormatで あることには変わりはありません。筆者自身も実務で使用してます。 ベンダー側で対応しきれていない部分の多くは、委員会からリリースしている LPB DesignKitのGHUBで対応するようにしてしています。
今回の連載では、それらの部分も含めて解説していこうと思っています。
G-Formatの書式
G-Formatは他のLPB Formatと異なりXML言語をベースとはしていません。 独自の書式となっています。G-Formatは複数の セクション で構成されています。 一つのセクションは、ドット(.)に続きキーワードから始まり、 .end で終了します。 例えば、下記の例はネットを定義するセクションの記述例です。 セクションは .netlist で始まり、 .end netlist で終了します。
|
1 2 3 4 5 6 7 8 |
.netlist "GND" G 0 { } "NA1" S 0 { XA1 P1 B { 25.08 50.18 1 } XA2 P1 B { 74.92 50.18 1 } } .end netlist |
また、一行だけのセクションも存在ます。一行セクションは .end は有りません。 改行までが一つのセクションとなります。例えば、下記の例は G-Formatのバージョンを 定義するセクションの例です。
|
1 |
.version 1 1 |
ブレイス({}、かぎかっこ）は、G-Formatの中で重要な役割を持ちます。 ブレイスで囲まれた部分が、一つの意味の塊となります。 フレイスの前後には、空白を入れてください。例えば、以下のような書き方は ツールによってはエラーになる恐れがあります。
|
1 2 3 4 5 6 7 8 |
.netlist "GND" G 0{ } "NA1" S 0{ XA1 P1 B {25.08 50.18 1} XA2 P1 B {74.92 50.18 1} } .end netlist |
# で始まる行はコメント行となります。 行の途中にコメントを入れることはできません。
|
1 2 3 4 5 6 7 8 9 10 |
# 井桁(#)で始まる行はコメント行となります .netlist "GND" G 0 { # このようなコメントの書き方はエラーとなります。 } "NA1" S 0 { # XA1 P1 B { 25.08 50.18 1 } この行はコメントとして無視されます XA2 P1 B {74.92 50.18 1} } .end netlist |
G-Formatのファイル名
LPB Formatの使用ではG-Formatのファイル名にルールは設けていません。 しかし多くの場合、慣習的にファイル名のサフィックスを .xfl としてます （ xml ではありません、 xfl です。ややこしいですね）。 これは、元々G-Formatが XML と呼ばれていたことに起因しています。 EDAツールによってはサフィックスを .xfl としないと G-Format wo入力できないケースがあるかもしれません。G-Formatが入力できない場合は、サフィックスを変更してみてください。
以上、G-Formatの概要について説明しました。それでは次回から具体例を挙げながらG-Formatの詳細について説明していきます。