ラベル DesignCompiler の投稿を表示しています。 すべての投稿を表示
ラベル DesignCompiler の投稿を表示しています。 すべての投稿を表示

2024年6月11日火曜日

Resistance is Futile! Building Better Wireload Models を読む

 
論理合成で配線負荷を見積もる Wire-load Model を理解するために論文をサクッと読んでみた.
Steve Golson, "Resistance is Futile! Building Better Wireload Models", SNUG, 1999

Wire-load Model の基本

Wire-load Model は実際のレイアウト情報を使う事無く,配線の特徴(配線遅延)を予測する物である.配線とそれに接続されるファンアウトから,Wire-load モデルによって負荷容量,負荷抵抗,配線の面積を予測する.ライブラリによって設計される回路の統計的情報から,Wire-load モデルは作られる.回路の配線とその負荷容量をヒストグラムにできる.得られたヒストグラムのうち,度数の90%以下を10分割して Index を作成する事で非常に保守的な Wire-load モデルを作成できる.同じ方法で抵抗および面積のWire-loadモデルを作成できる.
一般にベンダーは面積条件に応じて複数の Wire-load モデルを提供している( Area-Based Wireload Selection ).

Wire-loadモデルの「神話(根拠の薄い社会通念)」


神話1:配置配線される回路の面積レポートを元に,Wire-loadモデルを選ぶこと

これは絶対的な教義であるが,実はフロアプランがなくてもおおよそ妥当な配線負荷を Wire-load モデルは提供できる.回路が大きかろうが小さかろうが論理的に隣接するセルは近傍に置かれる事が期待されるためである.
もちろん大きいブロックは長距離配線があるのでその部分は見積もりが悲観的にはなりやすい.

神話2:ある面積条件に対して一つのWire-loadモデルで十分である

十分ではない.同じ面積であっても,回路の条件によって異なる配線負荷となりうる.一方で「単一の Wire-load モデル」で十分との報告もある.

神話3:配線抵抗はゼロにすべき

誤っている.これは配線遅延をゼロにする事に相当する.ワイヤ容量だけでも配線遅延と電力見積もりには貢献しているが.

神話4:配線面積をゼロにすべき

実際には配線は面積を要求する.面積の情報を提供できると,DesignCompiler は配線面積を考慮しながらゲートレベルの最適化を実現する.

神話5:ベンダーの提供するWire-loadモデルを常に信用すべき

そうとは限らない.仮にベンダーの Wire-load モデルがあっても,以下の条件では精度が落ちうる.
  • 設計対象がベンダーの Wire-load モデルより大きい
  • ネットリストの条件が異なる(配線が多い,混雑している,IOが多い)
  • アスペクト比が異なる
  • 設計フローが異なる.
ベンダーによっては Wire-load モデルに求める精度が異なる事も考慮すべき.

神話6:カスタムしたWire-loadモデルが常によい

これは Design-Specific Wire Model と呼ばれており,最初に配置配線を試し,そこから得られた配線の統計情報からその回路専用の Wire-load モデル を構築するものである.神話1と同様に広まっているが,同時に疑わしいらしい.

例えば以下の条件によって精度が落ちうる.
  • ベンダーが用意した大量の回路から得た統計的モデルに対し,本モデルは限られたサンプルから生成される.
  • 設計初期の Netlist から Wire-load モデルは作成されるが,それは設計後期の条件とは異なる.
  • モデル生成ツールが設計者が想定していないモデルを利用する可能性がある.
  • 各インスタンスが独自の Wire-load モデルを取得するようにフローを一意にする必要があるかもしれない(マクロごとにWire-load モデルを使い分けないといけないということ?)

神話7:Wire-loadモデルは配線後の統計と一致していないといけない

これは神話6の背景にあるものだが間違っており,一致する必要は無い.Wire-load モデルの目的は形状(配線長)の予測ではなく,配線時のタイミングを予測する事が目的である.

論文は Wire-load モデルと実際の設計の相関の解析などを紹介しているけれど,そこは省略. Design-Specific Wire Model が良いのかなと思っていたけれど,そうとは限らないというのが意外であった.あとトレッキーだな.

2024年5月14日火曜日

DesignCompilerでモジュールごとの面積内訳を見る

 DesignCompiler でモジュールごとの面積内訳を見たい場合,階層構造の展開をやめた上で,report_area -hierarchy オプションを付ける.compile_ultra はデフォルトで階層を展開して論理と回路を最適化してしまうので,-no_autoungroup オプションを付ける.

dc_shell> compile_ultra -no_autoungroup
dc_shell> report_area -hierarchy

 

同じように,電力も階層ごとに見ることが出来ます.
dc_shell> report_power -hierarchy


compile_ultra はデフォルトで階層を展開するので,
dc_shell> compile -ungroup_all
dc_shellcompile_ultra
compile コマンドと compiler_ultra コマンドを併用する必要は無いようだ.DesignCompiler R-2020.09-SP4 でのお話です.

2024年1月18日木曜日

"Error: 'top' doesn't specify a unique design" in DesignCompiler

 学生が以下のような tcl で論理合成中に current_design コマンドでエラーが出ると相談しにきた.
このエラーはファイル中に同じモジュール名の回路が複数ある場合に生じるエラー.しかし読み込んでいる Verilog ファイルは1つしかない.今回の例では,read_file コマンドで Verilog ファイルを読み込み,analyze コマンドで同じ Verilog ファイルを再読込しているため,メモリ中に同じモジュールが2つある事になっていたらしい.この場合,
list_design -show_files
list -designs
などでどのようなモジュールが読み込まれているか表示させてデバッグできる.今回についてはファイル読み込みが重複していたので,read_file コマンドを削除し analyze コマンドだけ実行することで解決した.

参考:
Pran Kurup and Taber Abbasi, "LOGIC SYNTHESIS USING SYNOPSYS® 2nd Ed.", KLUWER ACADEMIC PUBLISHERS

2023年9月3日日曜日

compile コマンドと compile_ultra コマンドの違い

DesignCompiler には compile コマンドと compile_ultra コマンドがあるけれど,その違いは何か調べた.compile_ultra の方が上位互換と考えて良いみたい.

compile: DC Expert を起動する.DC Expert は HDL を最適化されたテクノロジ依存のゲートレベル記述に変換する.
compile コマンドの基本機能は以下の通り.
・GUI と CLI をサポート
・階層的コンパイルをサポート
・フルコンパイル,インクリメンタルコンパイルをサポート
・FF およびラッチを利用した順序回路の最適化
・タイミング解析

compile_ultra: DC Ultraを起動する.より高速で厳しいタイミング条件における回路の合成,また回路の QoR (Quality of Results) の向上が可能.
compile コマンドの機能にさらに以下の機能が追加されている.(専用のライセンスが必要)

・DesignWare library をサポートし,DW library の中からベストな回路構成を自動的に選択,最適化.
・Alib と呼ぶ仮想ライブラリを生成する事で,より大規模な解空間の中から面積と遅延のトレードオフを探査する事を可能にする.
・階層構造を自動的に分解することで,DesignCompiler が回路中の論理の共有を可能にしタイミングをより向上させる.
・階層構造を持つ回路の特に下層の階層境界のポートを変更を許可する.
・データパス抽出を行い算術演算をデータパスブロックに変換し,データパスジェネレータを利用する事でよりより実装を実現する.
-retime オプションを利用すると,レジスタリタイミングを実施する.
・topological mode を利用すると,DesignCompiler は以下の処理を行う.
 ・より高精度なポストレイアウトタイミング,面積,電力の見積もりを wire-load model を用いず行う.
 ・マルチコア CPU を利用した論理合成の高速化
 ・多電源設計をサポート
 ・multicorner-multimode 最適化を実施し論理合成を高速化
-spgをオプションを利用する事で DesignCompiler Graphical を利用に可能にする.それによって
 ・physical guidance technology によって IC Compiler に対してセルの初期配置情報を提供する事でよりよい QoR を実現する.
 ・論理合成時の配線混雑度を軽減する.
 ・信号配線層の最適化を実現.
 ・floorplan exploration によって設計者がフロアプランの修正を可能に.

DC Expert と DC Ultra の違いを挙げると,Expert は以下を実施する.
・マルチプレクサの最適化
・順序セルのマッピング
・ブール代数最適化とマッピング
・Auto-Uniquilization
・Implement Synthetic Parts
・タイミングドリブン,電力ドリブンの組み合わせ回路最適化
・遅延とリーク電流の最適化
・デザインルール考慮
・area recovery

Ultraはさらに以下を実施する.
・面積のアングルーピング
・データパスの最適化
・レジスタリタイミング

2023年7月1日土曜日

電力解析でのスイッチング確率の設定する (set_switching_activity)

論理合成 (DesignCompiler) や静的遅延解析 (PrimeTime) における電力計算をスイッチング確率ベースで行う場合,スイッチング確率を外部から指定するために set_switching_activity コマンドを使う.DesignCompiler における set_switching_activity コマンドのオプションや使い方をまとめる.

dc_shell> set_switching_activity
[-static_probability static_probability]
[-toggle_rate toggle_rate]
[-state_condition state_condition]
[-path_sources path_sources]
[-rise_ratio rise_ratio]
[-period period_value | -base_clock clock]
[-type object_type_list]
[-hierarchy]
[object_list]
[-verbose]

-static_probability static_probability
電圧の High(1) の確率を指定する.引数は0から1.0までの小数である.0.25を指定すると,その時間における電圧 High の確率が25%として計算する.

-toggle_rate toggle_rate
正の小数として,0->1および1->0にトグルするトグル確率を指定する.単位時間におけるトグル確率として指定する.単位時間は -period オプションを用いて指定する.時間の単位はライブラリの物を利用する.クロックがある場合は,-base_clock オプションを用いる事で指定したクロック周期に対するトグル確率として指定する.(後述の利用例を見るとよい)

-state_condition state_condition
状態遷移条件によって振る舞いが異なるピンやセルなどの状態依存トグル確率を指定する.ただしセルやピンの電力の状態遷移依存性がキャラクタライザによって適切にキャラクタライズされている必要がある.このオプションはセルのリーク電流の状態依存性などをアノテートする事を可能にする.指定する state_condition が電力テーブルの内部表現と一致している必要がある.

-path_sources path_sources
パス依存のトグル確率を計算する時にパスの source を指定する.セルの電力のパス依存性がキャラクタライズされている必要がある.指定する path_source が電力テーブルの内部表現と一致している必要がある.

-rise_ratio rise_ratio
ピンのトグル数のうち立ち上がり波形の確率を,0から1の小数で指定する.0の場合はすべての入力が立ち下がり,1の場合はすべての入力が立ち上がりとして指定する.本オプションを利用する場合はトグル確率をユーザーが指定しなくてはいけない.初期値は0.5.

-period period_value
-toggle_rate オプションで指定したトグルが発生する時間期間を指定する.時間の単位はライブラリのものである.本オプションが指定された場合,実際のトグル確率は -toggle_rate オプションで指定した数字を本オプションで割った数字となる.本オプションを明示的に指定しない場合数字として1.0が利用される.

-base_clock clock
トグル確率を計算するために利用するクロックを指定する.本オプションによってクロックが指定された場合,際のトグル確率は -toggle_rate オプションで指定した数字を本オプションで指定したクロック周期で割った数字となる.クロック周期を変更しながら複数回 report_power コマンドを実行する事も可能で,その場合トグル確率は毎回クロック周期ごとに計算しなおされる.クロックとしてワイルドカード"*"を指定する事も可能で,その場合PowerCompiler はそのデザインに関係するクロックを自動的に検出してトグル確率を計算する.

-type object_type_list
スイッチング確率を設計者が明示的に指定したい場合に,対象となるオブジェクトを指定する.オブジェクトとしては以下を選択できる.
registers (sequential cell outputs),
tristates (tristate cell outputs),
black_boxes (black box cell outputs),
inputs (input design ports or hierarchical instance pins),
outputs (output design ports or hierarchical instance pins),
inouts (inout design ports / hierarchical instance pins),
ports (design port or hierarchical instance pins),
nets (nets),
regs_on_clocks clock_list (outputs of flip-flips clocked by the clocks in
clock_list),
clock_gating_cells (clock gating cell outputs),
memory (memory cell outputs).
本オプションを特定のインスタンスに指定する事でスイッチング確率を明示的に指定する事が可能である.registers もしくは regs_on_clock を指定した場合,順序セルの反転出力(QN),非反転出力(Q)が共にアノテートされる.その場合非反転出力は指定のトグル確率が,反転出力は1から指定のトグル確率を引いた値がアノテートされる.regs_on_clock を対象とする場合は,クロック名のリストである clock_list 引数を指定する必要がある.registers はフリップフロップおよびラッチが対象となるが,regs_on_clock はフリップフロップのみ対象であり,クロックゲーティングも対象である.
object_list 引数は対象を明示的に指定するが,-type は対象を暗黙に指定する.オプションは相互に排他的である.

-hierarchy
-type オプションと共に利用し,指定したオブジェクトの下位の階層すべてにアノテートする.本オプションを利用しない場合は,指定したオブジェクトのトップ階層のみアノテートする.

object_list
-static_probability オプションおよび -toggle_rate オプションの対象となる,ネット,ピン,ポート,セルなどのオブジェクトのリストを指定する.

-verbose
スイッチング確率をアノテートした結果を詳細に報告する.


コマンド例
次の例では,set_switching_activity は入力ポートのトグル確率を 33 / 1320 = 0.025,静的分布確率を 0.015 に設定する.
dc_shell> set_switching_activity -toggle_rate 33 -period 1320 
-static_probability 0.015 [get_inputs]

次の例では,入力ポートのトグル確率を0.25,静的分布確率を0.015に設定する.ここではクロック CLK が関連するクロックとして定義されているので,電力を計算する時のトグル確率はクロック周期 10 を用いて実際には 0.25 / 10 = 0.025 として計算される.
dc_shell> create_clock CLK -period 10
dc_shell> set_switching_activity -toggle_rate 0.25 -base_clock CLK -static_probability 0.015 -type inputs

次の例では状態遷移依存の静的分布確率を or1 セルにアノテートする.
dc_shell> set_switching_activity -static_probability 0.10 -state_condition "A & B" [get_cell or1]
dc_shell> set_switching_activity -static_probability 0.35 -state_condition "A & ! B" [get_cell or1]
dc_shell> set_switching_activity -static_probability 0.25 -state_condition "! A & B" [get_cell or1]
dc_shell> set_switching_activity -static_probability 0.30 -state_condition "! A & ! B" [get_cell or1]

次の例では,パス依存トグル確率を xor1 セルの Y 出力にアノテートする. 
dc_shell> set_switching_activity -toggle_rate 0.022 [get_pin xor1/Y]
dc_shell> set_switching_activity -toggle_rate 0.020 -path "A" [get_pin xor1/Y]
dc_shell> set_switching_activity -toggle_rate 0.002 -path "B" [get_pin xor1/Y]

次の例では現在のデザインにおけるすべての順序セルのアノテートされたスイッチング条件を除去する.
dc_shell> set_switching_activity -type registers -hierarchy

次の例ではクロック clk1 と clk2 を使うすべてのレジスタのスイッチング確率をアノテートする.
dc_shell> set_switching_activity -toggle_rate 0.1 -static_probability 0.5 -type {regs_on_clock {clk1 clk2}} -hierarchy

次の例では related_clock 属性としてワイルドカード"*" を指定したオブジェクトに対し,すべての入力にトグル確率0.2を,静的分布確率0.5を,アノテートする.電力解析結果は report_power コマンドで表示される.関連するクロックは自動的に推論され,トグル確率0.2がそれぞれのクロックの周期に会わせて相対的にスケールされる.
dc_shell> set_switching_activity -toggle_rate 0.2 -static_probability 0.5 -base_clock "*" -type inputs
dc_shell> report_power

2022年10月12日水曜日

DesignCompilerの電力解析結果

 ボスが面白いデータをくれた.DesignCompiler の電力解析結果である.乗算器を遅延制約を変えて合成している.

Period Intl     Switch Leak         Total
1 ns 636.4446 uW 523.31 uW 2.20E+04 nW 1.18E+03 uW
10 ns 63.6445 uW 52.331 uW 2.20E+04 nW 137.9381 uW
100 ns 6.3645 uW 5.2331 uW 2.20E+04 nW 33.5603 uW

すべて電力(ワット)で書かれているが,単なる和では Total は求まらない.

変換するにはエネルギーに変える.回路が同じだから処理あたりのエネルギーは同じ.
Intl+Sw (Power)        Intl+Sw (Energy)
1159.7546    nW 1159.76 fJ
115.9755     nW 1159.76 fJ
11.5976     nW 1159.76 fJ

リークもエネルギーに変える.単位時間に応じてリークは増える.
Leak (Energy)
2.20E+04 aJ
2.20E+05 aJ
2.20E+06 aJ

和を取ってエネルギーを求め,それをクロック時間で割って時間あたりのエネルギーである電力を計算する.結局,DesignCompilerの電力解析結果は,サイクルあたりの電力の総和を計算している事になる.
Total (Energy) Total (Power)
1.18E+03 fJ 1.18E+03 uW
1.38E+03 fJ 1.38E+02 uW
3.36E+03 fJ 3.36E+01 uW

[内部電力] = [内部エネルギー] / [時間]
[外部電力] = [外部エネルギー] / [時間]
[処理あたりのエネルギー] = [内部電力 + 外部電力 + リーク電力] * [時間] 
ということですね.



2022年1月5日水曜日

Procedural-continuous assignments

Verilog では以下のように always の中に assign 文を入れることが出来るらしい(@ryos36さんのTwitterから).
always 文の中に assign を入れる構文は Procedural-continuous assignments (手続き文の継続的代入?)と呼ぶらしく,DesignCompiler では「Procedural-continuous assignments は合成できないよ」とエラーが出た.純粋に動作モデルを立てるために使うのだろう.

2021年1月18日月曜日

DesignCompilerにてパラメータを伝搬しパラメタライズ化したモジュールをつなぐ

RTLが parameter 文などでパラメタライズドされていると各回路はその初期値でインスタンス化される.そのため上層の回路と下層の回路の parameter文の初期値が異なると,回路の接続をうまく見つける事ができない.

例えばプロセッサコアとその下に命令デコーダがある回路を対象に試してみる.
read_file -format sverilog { \
riscv_id_stage.sv \
riscv_core.sv \
}
current_design ${design} 
check_design



左上のLogical Hierarchyを見てもプロセッサコアしか見つからない.

これを解決するには,analyze文を利用して回路の仕様を中間表現としてライブラリに登録し,elaborate文を利用してその中間表現を読み取って回路を接続する.

file mkdir ./work
define_design_lib WORK -path ./work
analyze -format sverilog {riscv_id_stage.sv riscv_core.sv }
elaborate ${design}
check_design




上層の回路のパラメータが下層にきちんと伝搬して,インスタンス化されたモジュールが見つかり接続されたことがわかる.

参考:Link带参数的Verilog模块(Design Compiler)
https://www.cnblogs.com/kathywh/p/8550670.html

2019年1月18日金曜日

DesignCompilerにおける電力を考慮した論理合成

compileコマンドを使うとき
set_max_dynamic_power [val]
set_max_leakage_power [val]
compile -power_effort [none|low|medium|high]

compile_ultraコマンドを使うとき
set_leakage_optimization true
set_dynamic_optimization true
compile_ultra

compile_ultraはデフォルトで-area_high_effort_scriptオプションが
ついてしまい取り消せないので,上記の2つのコマンドの場合,compile -power_effort highの方が電力は減るっぽい(dynamicが2/3ぐらいになった).

2019年1月17日木曜日

Design Compilerの論理合成のコスト関数

Design Compilerで論理合成を行うとき,あるコスト関数を仮定してそれを最小化するように論理合成を行う.
コスト関数は以下の順になっており,太字のパラメータはset_cost_priorityコマンドで順番を変えられる.制約は,デザインルールと最適化係数の3種類に分かれている.

優先度(上ほど高い)制約の種類
connection classes Design rule cost
multiple_port_net_cost Design rule cost
min_capacitance Design rule constraint
max_transition Design rule constraint
max_fanout Design rule constraint
max_capacitance Design rule constraint
cell_degradation Design rule constraint
max_delay Optimization constraint
min_delay Optimization constraint
power Optimization constraint
area Optimization constraint
cell count

仮に最大遅延制約を最優先するには,set_cost_priorityコマンドで以下のように指定する.
set_cost_priority -delay
仮に,最大遅延制約,最小遅延制約の順に制約を優先するには以下のように指定する.
set_cost_priority {max_delay min_delay}

論理合成時にデザインルールを無視した合成を行うには,compileコマンドもしくはcompile_ultraコマンドに-no_design_ruleオプションをつける.論理合成を複数行うときにデザインルールについてのみ修正するには-only_design_ruleオプションを付ける.

2018年10月10日水曜日

論理合成で回路の活性化率を指定する

入力ピンの活性化率によって,回路の動的電流とリーク電流の割合が変化する.
これを論理合成時に考慮させるには,以下のオプションを使う.

set_switching_activity -toggle_rate trate -clock clk -static_probability staticp -select inputs
staticp は0.0から1.0の値で,入力が1となる割合.
trate は0.0から1.0の値で,入力の遷移確率.

2018年4月10日火曜日

DesignCompilerでDFFが見つからない(Target library contains no replacement for register)

DesignCompilerで論理合成したら以下のようなWarningが出た.

Warning: Target library contains no replacement for register 'PRODUCT_INST_reg[9]' (**FFGEN**). (TRANS-4)

これはライブラリに対応するDFFが存在しない時に出力されるエラー.例えば今回のライブラリは普通のDFFしか存在しないが,RTL記述に非同期リセット付きDFFを必要とする記述を書いてしまうとDCは論理合成ができないのでDCの持つ理想FF(FFGEN)を使って論理合成を行う.理想FFは物理的に存在しないので配置配線はできない.

読み込むLibraryの生成に失敗しているか,Libraryの持たないセルによる挙動なのか切り分ける必要がある(非同期Set-Reset付きDFFやトライステートインバータなど).

Libraryのチェックは以下のコマンドで行える.

check_library -logic_library_name logic_library.db

2014年2月26日水曜日

SDCの単位を指定する

論理合成で利用する遅延制約(Synopsys Design Constraint: SDC)において,容量や抵抗,時間の単位を明示するために,set_unitsコマンドを利用する事が出来る.

set_units -capacitance cap_unit -resistance res_unit \
-time time_unit -voltage voltage_unit -current current_unit \
-power power_unit

単位を明示しない時は読み込むライブラリ(.db)の単位が使われるが,明示した方が安心だろう.

2012年2月21日火曜日

配線負荷モデル

配線負荷モデルってなんですの?ということで調べてみた.

配線負荷モデル(Wire Loading Model)とは,DesignCompiler等で論理合成する際に,ゲート間の配線に寄生する容量,抵抗等を論理合成ツールに考慮させるためのパラメータである.

実際の回路ではゲート内のRC以外にも,ゲート間の配線に寄生する容量(C)や抵抗(R)が存在する.これらのパラメータは配線長,およびファンアウト(次段につながるゲート数)に依存して変動する.
一方論理合成する際は正確な配線長はわからない.正確な寄生容量/抵抗を知るためにはレイアウトを行う必要がある.そのため過去に設計したレイアウトから回路の面積やファンアウトに対する寄生容量/抵抗の値を統計的に抽出し,この統計情報を利用して論理合成した回路内の配線の寄生容量/抵抗を考慮する.

セルのキャラクタライズを行った後のデータベース(.lib)がファブから提供されている場合,配線負荷モデルの値は.libファイルに書かれている.配線負荷モデルの一例を挙げると以下のようになる.

wire_load hoge_area200 {
resistance : 0 ;
capacitance : 1 ;
area : 0 ;
slope : 10e-10;
fanout_length: 1.0 10e-4 ;
fanout_length: 2.0 20e-4 ;
fanout_length: 4.0 40e-4 ;
}

"hoge_area200"は配線負荷モデルの名前を示す.後述するが配線負荷モデルは回路面積(想定される配線長)に応じて使い分けることができる.
"area"は配線が占める面積,"capacitance"は単位配線長あたりの容量,"resistance"は単位配線長あたりの抵抗,"slope"はファンアウト数あたりの波形の傾きである.fanout_lengthはファンアウト数に対する配線資源を示す.


配線負荷モデルの選択は

wire_load_selection Libname {
wire_load_from_area : 0.00 200 hoge_area200 ;
wire_load_from_area : 200.50 400 hoge_area400 ;
wire_load_from_area : 400.50 800 hoge_area800 ;
}

の様にかける.ここで"wire_load_selection"内の"wire_load_from_area"の値,つまり回路面積に応じて対応する"wire_load"に分岐する事ができる.

今回は回路面積に対する配線負荷モデルを示したが,たとえば消費電力の最悪値を見積もるために,別の配線負荷モデルを使い分ける事もできるようだ.