參考 IEEE 1685-2022 IP-XACT standard 第 11 章。
閱讀本篇介紹之前，請先確保已經理解 Design 文件描述 內容。
簡介與核心目的
Design Configuration 在 EDA 流程中扮演了組裝藍圖的「設定檔」角色，為 design 文件或 generator chain 文件提供額外的配置資訊，其中也包含了非必要的附屬資訊。
該文件價值包括：
- 支援層次配置：儲存用於支援層次化設計配置的資訊。
- 工具流程自動化：通過儲存設計者原本必須重新輸入的資訊，有助於在不同的設計環境之間傳輸設計，並自動化 generator chain 的執行。
- 單一設計，多重配置：一個設計（Design）文件可以被多個設計配置描述文件所引用，實現不同的配置方案。
關鍵屬性
Design configuration 文件主要包含三種類型的配置資訊：
！！請注意以上僅列出常用屬性，不包含所有欄位，詳細資訊請參閱官方標準文件！！
| XML 元素 | 說明與作用 |
|---|---|
| designRef | 指定此配置所針對的設計描述文件（Design Document）。如果組件的 View 中包含 designConfigurationInstantiationRef，且未同時包含 designInstantiationRef，則該配置中必須包含 designRef。 |
| generatorChainConfiguration | 包含用於配置生成器鏈中參數的配置值。這允許使用者為特定的自動化任務（generator chain）提供所需的參數設定。 |
| viewConfiguration | 定義設計中特定元件實例（component instance）應採用的活動視圖（active view）。它允許使用者指定實例是使用 RTL 視圖、TLM 視圖，或是其他抽象層次的視圖。 |
| interconnectionConfiguration | 包含與介面互連相關的資訊，特別是用於處理抽象層次不匹配（例如連接 RTL 介面和 TLM 介面）的連線。此處指定了連接所需的抽象器（abstractor）。 |
InterconnectionConfiguration 機制
其中 interconnectionConfiguration 是設計配置中獨特的部分，它專門處理設計中無法直接連接的匯流排介面。
- 互連參照（interconnectionRef）：這是強制性元素，必須參照在 design 文件中定義的一個特定的互連（
interconnection/name或monitorInterconnection/name）。 - 抽象器實例（abstractorInstance）：如果被參照的互連連接了使用不同抽象定義的匯流排介面，則必須在這裡指定所需的抽象器實例（abstractor instance）。
- 有序列表：
abstractorInstance是一個有序列表，用於將多個抽象器串聯起來，以橋接不同的抽象層次。 - 實例化：抽象器實例必須賦予一個唯一的名稱（
instanceName），且此名稱不得與所引用設計中的任何元件實例名稱重疊。 - 視圖選擇： 必須透過 viewName 元素定義為抽象器實例選擇的視圖。
- 有序列表：
ViewConfiguration 機制
viewConfiguration 允許設計者在設計階層的底部（實例層）強制選擇一個特定的視圖：
- 實例名稱（instanceName）： 強制性元素，必須匹配所引用設計中存在的元件實例名稱。
- 視圖參照（viewRef）： 強制性元素，指定元件實例應該使用的視圖名稱（例如
RTLview或TLMview）。 - 配置參數（configurableElementValues）： 允許為該實例選擇的視圖內，所引用的元件實例（
componentInstantiation或designConfigurationInstantiation）中的參數提供配置值。
如果 design 文件是一張樂高的連接圖，指定哪些積木（component）在哪裡，以及它們如何接觸，那麼 design configuration 文件就是一張告訴工廠具體設計和組裝流程的指令卡。
- 針對每個積木 instance，應該使用他的「RTL 藍圖」還是「TLM 藍圖」？
（由viewConfiguration決定） - 運行哪些自動化流程（generator chain），以及這些流程應該使用什麼參數？
（由generatorChainConfiguration決定） - 如果兩個不同類型的積木需要連接在一起，應該在哪裡加入一個轉接頭（abstractor）？
（由interconnectionConfiguration決定）
後記
如我在 IP-XACT 物件介紹：Design（設計）所提及，初期為了要釐清和 Design 文件的差異花了一點時間，一旦理解所謂設計配置文件的目的，似乎就沒有那麼難懂了。
白話理解 Design Configuration
當我們在設計文件中描述完連線和結構後，在不同的使用情境、環境下，有可能會影響設計產生不同面向，這些資訊就會被寫在設計配置文件中。
例如說這個 design 裡每個 instance 要用哪個 view、假設 abstraction 不同，要插哪個 abstractor、generator chain 或參數配置要怎麼套用等等。
同一份 design，在這次產生或驗證時，要選哪套實作與轉接設定？這些切換資訊就會被寫在 design configuration 內。
假設同一個 uart_0、cpu_0 可能有：RTL view、gate-level view、TLM view、simulation view、synthesis view，那在 design configuration 內就會有這樣的資訊：
uart_0 使用 RTL view
cpu_0 使用 TLM view
某條 interconnection 需要 abstractor 做 RTL/TLM 轉換那應該可以猜到：一個 design 可以關聯多個 design configurations。這樣就可以更明白它不是描述另一個 design，而是同一個 design 的使用情境配置。
與其他 IP-XACT 文件的關係層級
所以如果有按照建議的順序理解 IP-XACT 的話，大致上應可粗略建立以下結構：
busDefinition.xml
↓ 定義這是什麼 bus / interface family
abstractionDefinition.xml
↓ 定義這個 bus 在某個抽象層級下有哪些 logical ports
component.xml
↓ 定義一顆 IP：
- physical ports
- busInterfaces
- logical port -> physical port mapping
- parameters
- memory maps
- fileSets / views
design.xml
↓ 實例化多顆 components，描述它們怎麼接
designConfiguration.xml
↓ 指定這份 design 要用哪些 views、abstractors、generator settings
generatorChain.xml
↓ 描述工具流程、產生流程
catalog.xml
↓ 像索引，列出 package 裡有哪些 IP-XACT 文件
