Design Vision
目的と設定
DCグラフィカルデザイン検査と合成の対話型操作。再現可能なヘッドレス合成にはDesign Compilerを使用。Design Visionは階層、タイミング、回路図調査に有用。
design_visionはユーザーの設定済み環境またはツールプロファイルから解決する。
実際のリリース、サポートオプション、ライセンス、ドキュメントをローカルで発見する。
環境発見を使用すること。特定のインストールディレクトリ、アカウント、ライセンスエンドポイント、起動シェルを前提としない。
インストールインベントリ、ログ、ドキュメントインデックスはプライベートローカル状態に保持する。
呼び出しとコマンド規約
準備された環境から設定済みの実行ファイルを直接使用する。そのラッパーファイル名を保持すること。ディスパッチャの呼び出し名を変更すると、異なる製品が選択される可能性がある。そのリリースのドキュメントで対話型とバッチの規約を確認すること。このリファレンスはコマンド候補を提供するものであり、すべてのリリースに存在する証明ではない。
design_vision -f design.tcl
サポートされているステージスクリプトについては、flow.pyがシェルラッパーを必要とせずにコマンド、ステータス、ログ、成果物、チェックポイントを取得する。ツールは類似フラグに対して異なるセマンティクスを持つネイティブインターフェースを提供する場合がある。
入力と出力
DC .ddcまたはサポートされているRTL/ネットリストと、対応するライブラリ、SDC、デザインセットアップ。GUI使用には動作するディスプレイが必要。探索的編集にはチェックポイントのコピーを使用すること。
DC互換のデザインチェックポイント、レポート、セッションログ。サポートされている場合、明示的にエクスポートされたGUI成果物。検査中に承認済み合成チェックポイントを上書きしない。
ステージ操作
新しいコマンドを構築する前に、インストール済みのコマンド構文、引数タイプ、デフォルト、制限、例、機能要件、デザイン状態の前提条件を取得する。各操作が状態のクエリ、派生状態の更新、デザインの変更、成果物のエクスポートのいずれであるかを特定する。
| ステージ | コマンドまたはネイティブプロシージャ | 前提条件とチェック |
|---|---|---|
| ロード/検査 | read_ddc current_design report_hierarchy report_timing | 保存されたデザインに一致する合成ライブラリ/制約コンテキストを使用。 |
| 合成 | analyze elaborate compile | 再現可能な合成とフォーマルゲート検証はsynopsys-design-compilerに委任。 |
| 保存 | write_file write_sdc | デザインの変更はすべて検証が必要な新しい候補として扱う。 |
Tcl、検査、ドキュメント
DCデザイン/コレクションコマンドは文書化されている箇所に適用：current_design、get_designs *、report_hierarchy、report_timing、report_area、check_design。GUI固有のAPIは個別に調査すること。
Tclインターフェースでは、パス/引数をTclリストとして構築し、サポートされているコレクションAPIを使用してコレクションを処理し、エラーをキャッチし、明示的なコマンド戻り値を検査する。構文的に有効なTclファイルはコマンドの利用可能性を保証しない。ネイティブドライバの場合は、文書化された入力形式を使用すること。
python3 scripts/docs.py search '' --tool design-vision --limit 20
# 複数の一致がある場合はインストールバージョン/インストールを選択。
# エントリを取得するには: python3 scripts/docs.py show DOCUMENT_ID
例はバンドルディレクトリから実行する。コマンド発見を読んで、プライベートインデックスの作成、範囲指定取得、実行時利用可能性、ライフサイクルチェックについて確認すること。マニュアルエントリは呼び出し可能なコマンドではなく、変数や診断情報を記述する場合がある。ドキュメント不足はサポートされていないコマンド選択に対する障害となる。
制御パラメータと依存関係
合成設定はDCポリシーに従う。GUI表示/レイアウト設定は観察目的。マッピングされたデザイン編集は下流の等価性および物理的証拠を無効にする。
同じDCリリース/データベース/ライブラリコンテキスト。GUIライブラリ/表示はdc_shellとは独立に失敗する可能性がある。正確なラッパー名を使用すること。これは製品の personality を選択するため。
元の値/提案値、レポートでサポートされる仮説、マニュアルリファレンス、有効なステージ、期待されるメトリックを記録する。最適化を使用して、不変機能とハード制約のもとで範囲指定された比較を行う。
障害回復と検証
表示/GUIのセットアップの問題は合成エラーと分離して診断する。ラッパー名とデザイン/ライブラリコンテキストを保持する。デザイン編集は、下流プロモーションの前に新しい合成/フォーマル証拠を必要とする。
コマンド/ステータス、内部ログ、レポート、状態/チェックポイントIDを取得する。原因を分類し、関連するインストール済みドキュメントを参照し、最も混乱の少ない正当な修正を適用する。最後の有効な受信チェックポイントの書き込み可能なコピーを復元し、影響を受けるステージを再実行する。変更を保持する前に検証済みメトリックを比較する。拒否された試行は保持する。回復判断にはトラブルシューティングを使用すること。
機能変更には明示的な許可が必要。タイミング要件を緩和したり、必要な制約を削除したり、検証をバイパスして成功と報告したりしない。正当な修正が残っていない場合、または設定されたバジェットを使い果たした場合は停止し、どの入力または環境の修復が必要かを報告する。
テンプレートと承認基準
実際の出力と製品固有のレポートを要求されたスコープに対して検査する。合成/実装では、マッピング/リンクされた成果物と保存された制約を必要とし、変換後の機能を再証明する。検証では、完全なカバレッジとクリーンな必須チェックを必要とする。シミュレーション/デバッグでは、レビューされた診断とともに意図されたタスク/テストが完了することを必要とする。
ドキュメント検証、Tcl構文チェック、ツール実行、ステージ承認、エンドツーエンドのサインオフ証拠は分離して保持する。生成されたストリームは検証済み実装ではない。必要な証拠の境界については、実行契約および検証スコープを参照。