參考 IEEE 1685-2022 IP-XACT standard 第 8.1 節。
閱讀本篇介紹之前，請先確保已經理解 Bus Definition 文件描述 以及 Abstraction Definition 文件描述。
簡介與核心目的
Abstractor 的核心目的是解決在設計中整合使用不同建模風格的元件時所產生的連接問題。抽象器是 IP-XACT 標準中處理異質性（heterogeneity）的關鍵，它允許設計者在單一設計中結合不同抽象層次的 IP 模型，並依靠標準化的元數據來自動化處理複雜的介面轉換。
- 用於在兩個具有相同匯流排類型但抽象類型不同的匯流排介面之間進行轉換或轉接。
- 抽象器的典型應用範例是連接 TLM 建模風格（Transaction-Level Modeling）的介面與 RTL 建模風格（Register Transfer Level）的介面，例如連接 APB_RTL 和 APB_TLM 介面。
- 一個抽象器必須只包含兩個介面，且這兩個介面必須基於相同的匯流排定義（Bus Definition），但使用不同的抽象定義（Abstraction Definitions）。
與一般元件不同，抽象器在設計中扮演特殊的「橋接」角色：
- 抽象器不會被設計描述（design）文件直接引用。相反地，抽象器是透過 design configuration 文件來引用的。
- 在設計配置中，當偵測到兩個元件介面需要連接，但它們之間存在抽象層次差異時，abstractor instance 會被指定並插入到互連（interconnection）中。
核心結構
Abstractor 文件包含以下關鍵區塊：
！！請注意以下僅列出常用屬性，不包含所有欄位，詳細資訊請參閱官方標準文件！！
類型以及模式
- 匯流排類型（busType）： abstractor 必須指定它所參考的匯流排定義（Bus Definition），這決定了該 abstractor 能夠轉接的匯流排類型。
- 抽象器模式（abstractorMode）：這是一個強制性元素，它定義了抽象器內含的兩個介面的模式，並決定了它可以被插入哪種類型的連線中。常見模式包括：
- initiator：用於 initiator 到 mirrored-Initiator 的連接，或用於連接到 exported initiator connection。
- target：用於 target 到 mirrored-target 的連接。
- direct：用於 initiator-to-target 的直接連接。
- system：用於 system-to-mirroredSystem 的連接。
抽象器介面（abstractorInterfaces）
- 該元素強制包含兩個
<abstractorInterface>元素。 - 這兩個介面必須具有相同的
busType，但抽象類型必須不同。 - 每個介面都必須通過
abstractionTypes元素來指定其參照的抽象定義。例如，一個介面可能引用 SampleAbstractionDefinition_TLM，另一個則引用 ampleAbstractionDefinition_RTL。
模型與生成器（model & abstractorGenerators）
- 模型（model）：abstractor 可以包含一個 model 元素，用於指定其不同的 views 和 ports。抽象器 port 的定義與元件 port 幾乎相同，但通常不需要包含實現約束（例如 constraintSet 或 powerConstraints 元素）。
- 抽象器生成器（abstractorGenerators）：abstractor 可以附加生成器程序，結構與元件生成器（componentGenerator）相同。
Abstractor 在 design configuration 文件的使用
當 EDA 工具確定需要一個抽象器時，它會在 designConfiguration 文件中執行以下操作：
- 實例化抽象器：在
interconnectionConfiguration元素下，使用abstractorInstance元素來實例化一個抽象器。 - 鏈接抽象器：abstractorInstance 是一個有序列表，用於將多個抽象器串聯起來，從而從一個抽象層次橋接到另一個抽象層次。
- 配置檢查：抽象器鏈的起點和終點必須滿足嚴格的兼容性規則：
- 起點檢查：第一個抽象器實例的第一個
abstractionType元素必須與互連的起始端點（initiator、system 或 mirrored-target）的abstractionType兼容。 - 終點檢查： 最後一個抽象器實例的第二個
abstractionType元素必須與互連的結束端點（mirrored-initiator、mirrored-system 或 target）的abstractionType兼容。 - 中間檢查： 抽象器鏈中，除第一個外的所有抽象器，其第一個
abstractionType必須與前一個抽象器的第二個abstractionType兼容，以確保鏈路是連續且無迴圈的。
- 起點檢查：第一個抽象器實例的第一個
後記
因為 Abstractor 比 Generator Chain 更難在初期碰到，分享一下初期困擾我一陣子的兩個問題：
為什麼是寫在 Design Configuration？
因為在 IP-XACT 中，元件之間的實體連線（topology）是固定的，但 User 可以透過 Design Configuration 為每個元件實例自由切換不同的 view，例如把 A 設為 RTL view、B 設為 TLM view。只有在確定了各元件要用哪個 view 之後，系統才會知道這條連線上是不是發生了抽象層級不匹配的狀況。
如果發現不匹配，系統才會在 Design Configuration 中宣告啟用對應的 Abstractor 來解決衝突。
也就是說當 User 在連線時，把一個 TLM 介面與一個 RTL 介面連在一起時，應該允許這條連線（只要 logical port 規則符合），但在背景生成檔案時，必須要在 Design Configuration 內自動串上一筆 abstractorInstance 的紀錄。
實際上接近什麼概念？
當時看到 Abstractor 文件覺得應該可以跟軟體常用的 adaptor 作類比。Adapter 用途就是讓介面不相容的類別能夠一起運作，它會把一個類別的介面轉換成 client 所預期的另外一種介面。它不干涉核心業務邏輯或是系統的實體架構，而是用來解決溝通翻譯問題。
