UVM基礎-TLM通信機制（一）
目錄
????????基本概念
????????TLM通信分類
????????單向通信
????????????????單向通信舉例
????????????????單向通信代碼?
? ? ????雙向通信
????????多向通信
????????????????多向通信總結
????????通信管道
????????????????TLM FIFO
????????????????Analysis Port
????????????????Analysis TLM FIFO
? ? ? ? 芯片驗證是在RTL模型初步建立后，通過驗證語言和方法學例如SV/UVM來構建驗證平臺。該平臺的特點是驗證環(huán)境整體基于面向對象開發(fā)，組件之間的通信基于TLM，而在driver與硬件接口之間需要將TLM抽象事務降解到基于時鐘的信號級別。? ??
基本概念
? ? ? ? TLM是Transaction Level Modeling（事務級建模）的縮寫，它起源于SystemC的一種通信標準。所謂transaction level是相對DUT中各個模塊之間信號線級別的通信來說的。簡單來說，一個transaction就是把具有某一特定功能的一組信息封裝在一起而稱為的一個類。仿真速度是TLM對項目進度的最大貢獻，同時TLM傳輸中的 transaction 又可以保證足夠大的信息量和準確性。
? ? ? ? 如果要提升系統(tǒng)模型的仿真性能，可以從兩個方面出發(fā)：一個是建模本身的優(yōu)化，另一個是模型之間的通信優(yōu)化。通信優(yōu)化可以通過降低通信頻率，內容體積增大的方式來減少由于不同進程之間同步帶來的資源損耗。TLM就是從通信優(yōu)化角度提出的一種抽象通信方式。
? ? ? ? TLM通信需要兩個通信的對象，這兩個對象分別稱為 initiator 和 target 。區(qū)分它們的方法在于，誰先發(fā)起通信請求，誰就屬于initiator；誰作為發(fā)起通信的響應方，誰就屬于target ，但這個分類并不代表transaction一定是initiator發(fā)起的，transaction也可能是從target流向initiator。
? ? ? ? 按照transaction 的流向，我們可以將兩個對象分為 producer 和 consumer 。數(shù)據(jù)從哪里產生，它就屬于producer，數(shù)據(jù)流向了哪里，它就屬于consumer。
? ? ? ? 譬如transaction從發(fā)起端到接收端，是發(fā)起端向接收端調用get函數(shù)，此時發(fā)起端是producer ，接收端是 consumer；transaction也可以從接收端到發(fā)起端，是發(fā)起端向接收端調用put函數(shù)，此時發(fā)起端是consumer，接收端是producer。?
initiator 和 target 的關系同 producer 和 consumer的關系不是固定的
? ? ? ? 有兩個參與通信的對象之后，用戶需要將TLM通信方法在 target 一端中實現(xiàn)，以便于 initiator 將來作為發(fā)起方可以調用 target 的通信方法，實現(xiàn)數(shù)據(jù)傳輸；在 target 中實現(xiàn)了必要的通信方法后，需要對兩個對象進行連接，在兩個對象中創(chuàng)建TLM端口，繼而在更高層次中將這兩個對象進行連接。
TLM通信分類
TLM通信步驟可以分為：
? ? ? ? ① 分辨出component是屬于initiator還是target，是producer還是consumer。
? ? ? ? ② 在target中實現(xiàn)TLM通信方法。（此為UVM的規(guī)定模式）
? ? ? ? ③ 在兩個對象中創(chuàng)建TLM端口。（TLM端口不需要預設，只需要實例化即可）
? ? ? ? ④ 在更高層次中將兩個對象的端口進行連接。
從數(shù)據(jù)流向來看，傳輸方向可以分為單向（unidirection）和雙向（bidirection）
? ? ? ? 單向傳輸：由initiator發(fā)起request transaction。
? ? ? ? 雙向傳輸：由initiator發(fā)起request transaction，傳送至target；而target在接受了request transaction后，會發(fā)起response transaction，繼而返回給initiator。
端口按照類型可以劃分為三種：
? ? ? ? ※ port：經常作為initiator的發(fā)起端，initiator憑借port才可以訪問target的TLM通信方法。
? ? ? ? ※ export：作為initiator和target中間層次的端口。
? ? ? ? ※ imp：只能作為target接收request的末端，它無法作為中間層次的端口，所以imp的連接無法再次延伸。
? ? ? ? initiator需要有port，是起點，但是當initiator和target之間隔了很多層次的時候，那么中間這些層次的過渡就使用export，target上的就是imp，是終點。
? ? ? ? 如果將傳輸方向（單、雙向）和端口類型（port、export、imp）加以組合，可以幫助理解TLM端口的繼承樹。TLM端口一共可以分為六類：
? ? ? ? 要注意的是，端口是繼承于uvm_void，端口既不是繼承與object類型也不是繼承與component類型，所以端口是不能使用type_id::create的。
單向通信
? ? ? ??單向通信（undirectional communication）指的是從initiator到target之間的數(shù)據(jù)流向是單一方向的，或者說initiator和target只能扮演producer和consumer中的一個角色。
? ? ? ? ?按照UVM端口名的命名規(guī)則，它們指出了通信的兩大要素：① 是否為阻塞的方式（是否可以等待延時）；② 采用何種通信方法（put、get、peek）。其中單一端口函數(shù)的PORT可以為port、export和imp。
? ? ? ? 阻塞傳輸方式將blocking前綴作為函數(shù)名的一部分，而非阻塞方式則名為nonblocking。阻塞端口的方法類型為task，這保證可以實現(xiàn)事件等待和延時；非阻塞端口的方式類型為function，這保證方法調用可以立即返回。
? ? ? ? blocking阻塞傳輸?shù)姆椒ò?/strong>：Put()：initiator 先生成數(shù)據(jù)T t，同時將該數(shù)據(jù)傳送至target。Get()：initiator從target獲取數(shù)據(jù)T t，而target中的該數(shù)據(jù)T t則應消耗。Peek()：initiator從target獲取數(shù)據(jù)T t，而target中的該數(shù)據(jù)T t還應保留。
? ? ? ? nonblocking非阻塞方法分別是：try_put(); can_put(); try_get(); can_get(); try_peek(); can_peek()。非阻塞函數(shù)對應阻塞任務的區(qū)別在于它們必須立即返回值，執(zhí)行成功返回1，執(zhí)行失敗返回0。
單向通信舉例
單向通信代碼
? ? ? ? 除了在component1和component2中定義任務和方法外，還要在env環(huán)境中對component1和component2做例化創(chuàng)建。以及接口的連接，這里要注意連接方向是initiator的port連接到target上面。
首先comp1例化了兩個port端口：
?comp2作為target例化了兩個對應的imp端口：?
連接的方法是使用connect，其中connect的左側是initiator，connect的右側是target。
?總結起來還是三步驟: ① 定義端口；② 實現(xiàn)對應方法；③ 在上層將端口進行連接。
雙向通信
? ? ? ? 與單向通信相同的是，雙向通信（bidirectional communication）的兩端也分為initiator和target，但數(shù)據(jù)流向在端對端之間是雙向的。絕大多數(shù)的環(huán)境都是采用單向通信，雙向通信應用的比較少。
? ? ? ? 雙向通信中的兩端同時扮演著producer和consumer的角色，而initiator作為request發(fā)起方，在發(fā)起request之后，還會等待response返回。
UVM雙向端口不再采用get、put和peek，而是采用新的方式（transport、master和slave）：
? ? ? ? 作為master的一端，在方法聲明中，既有put()也有get()。?
? ? ? ? 雙向端口按照通信握手方式可以分為：① transport雙向通信方式；② master和slave雙向通信方式。transport端口通過transport()方法，可以在同一方法調用過程中完成REQ和RSP的發(fā)出和返回。master和slave的通信方式必須通過put、get和peek的調用，使用兩個方法才可以完成一次握手通信。
多向通信
? ? ? ? 多向通信（multi-directional communication）不是多個組件多個方向的通信，而是指initiator與target之間的相同TLM端口（同名，又相同類型）數(shù)目大于1時的處理辦法。
產生問題的原因：
? ? ? ? comp1有兩個uvm_blocking_put_port，而comp2有兩個uvm_blocking_put_imp端口，我們對于端口例化可以給不同的名字，連接也可以通過不同名字進行索引，但問題在于comp2中需要實現(xiàn)兩個task put(itrans t)，又因為不同端口之間要求在imp端口一側實現(xiàn)專屬方法，這就造成了方法命名沖突，即無法在comp2中定義兩個同名的put任務。
解決方法：
? ? ? ? UVM通過端口宏聲明方式來解決這一問題，它解決問題的核心在于讓不同端口對應不同名的任務，這樣便不會造成方法名的沖突。
這里涉及到很多知識點，在最開始的兩行宏定義，就是解決多向通信問題的辦法：
? ? ? ? 使用了如上的宏定義后，那么原來的uvm_blocking_put_imp包括里面的函數(shù)，都應該定義成加后綴“_p1”和后綴"_p2"的形式，所以在從comp2中定義target以及put函數(shù)后面都加了對應的后綴。而對于port端口而言，它只需要把itrans發(fā)出去就行了，而不必管itrans被發(fā)送到哪里，所以不需要對initiator組件內部的port進行宏定義。
? ? ? ? 不僅如此，為了防止互斥訪問，還使用了旗語semaphore。通過key.get()和key_put()的方式來實現(xiàn)互斥訪問，解決訪問共同資源的數(shù)據(jù)沖突問題。
? ? ? ? 另外再提一點細節(jié)，因為我們調用的TLM端口時blocking類型的，所以可以有延時，因此我們使用的put函數(shù)是一個task類型，如果我們定義的TLM端口時non-blocking類型的，那么就要定義function try_get和can_put等，同樣的后面也要加上對應的宏定義后綴。不僅如此，使用旗語semaphore也不能使用key.get，而是使用key.try_get()，如果get不到key要立即返回0。
根據(jù)三步驟，定義完端口和方法，最后一步就是在頂層進行連接，給出外部env1代碼：
? ? ? ? 如果有多個相同類型的import，那么必須通過宏定義的方式，定義不同名稱的import， 從而解決任務名沖突的問題。
? ? ? ? 對于組件1來講，不需要對port進行區(qū)分，并且對于從comp1中調用的函數(shù)還是put函數(shù)，而不是put_p1或者put_p2，這就是宏定義方法的好處。對于initiator中的port來說，他不需要管連接的import是哪個，所定義的put函數(shù)被宏定義成什么名稱，只要我們在import中進行了宏定義后，連接到port時，它會自動調用與put相對應的put_p1或者put_p2函數(shù)。
多向通信總結
????① 用戶只需要在例化多個imp端口的組件中實現(xiàn)不同名稱的方法，使其對應imp類型名保持一致。
????② 而對于port端口一側的組件，則不需要關心調用的方法名稱，因為該方法名并不會發(fā)生改變。
????③ 所以通過這種方式可以防止通信方法名的沖突，從而解決多向通信的問題。
通信管道
? ? ? ? 經過上面的介紹，我們需要在target端定義get()和put()函數(shù)，每次定義target都要進行函數(shù)的聲明，是否有方法不自己實現(xiàn)這些數(shù)據(jù)傳輸方法，同時可以使用TLM？以及數(shù)據(jù)傳輸過程中，如果出現(xiàn)一端到多端的情況，怎么處理？
? ? ? ? 幾個TLM組件和端口可以幫助我們解決上面的問題：
TLM FIFO
? ? ? ? 在一般TLM傳輸過程中，無論是initiator給target發(fā)起一個transaction，還是initiator從target獲取一個transaction，transaction最終都會流向consumer中。consumer在沒有分析transaction時，我們希望先將對象存儲到本地FIFO中供稍后使用。
? ? ? ? UVM庫中內置了一個uvm_tlm_fifo類，這個類是一個組件，它繼承與uvm_component類，而且已經預先內置了多個端口以及實現(xiàn)了多個對應方法供用戶使用。
? ? ? ? 對于uvm_tlm_fifo來講，存放的數(shù)據(jù)類型是固定的，因為作為一個fifo里面存放的數(shù)據(jù)肯定類型是一致的。uvm_tlm_fifo還提供put、get以及peek對應的端口。??
? ? ? ? 上面端口都是imp端口，雖然后面有get_export，但不是export端口，里面是有定義方法的。雖然看起來端口名是export，但真正的類型是imp。
Analysis Port
? ? ? ? 除了端對端的傳輸，在一些情況下還有多個組件會對同一個數(shù)據(jù)進行運算處理，如果這個數(shù)據(jù)是從同一個源的TLM端口發(fā)出到達不同組件，這就要求該種端口可以滿足從一端到多端的需求。
? ? ? ? 如果數(shù)據(jù)源端發(fā)生變化需要通知跟它關聯(lián)的多個組件時，我們可以利用軟件的設計模式之一觀察者模式（observer pattern）來實現(xiàn)。
? ? ? ? observer pattern的核心在于：① 這是從一個initiator端到多個target端的方式。② analysis port采取的是“push”模式，從initiator端調用多個target端的write()函數(shù)來實現(xiàn)數(shù)據(jù)傳輸。
? ? ? ? 按照傳輸方法和端口方向組合，可以將 analysis port 分為：uvm_analysis_port 、uvm_analysis_export 以及uvm_analysis_imp。target 一側例化了 uvm_analysis_imp 后還需要實現(xiàn)write()函數(shù)。從initiator端調用write()函數(shù)時，它是通過輪詢的方式將所有連接的target端內置的write()函數(shù)進行了調用。也因為是函數(shù)，所以無論一個initiator連接了多少target，initiator端調用的write()函數(shù)都是可以立即返回的。并且，特殊的是，采用analysis port，即使initiator沒有和任何target相連都不會報錯，這是和前面端對端的(port和imp成對出現(xiàn))port有區(qū)別的地方。
Analysis TLM FIFO
? ? ? ? ?uvm_tlm_analysis_fifo類繼承于uvm_tlm_fifo，它具有單一TLM端口的數(shù)據(jù)特性，同時該類又有一個uvm_analysis_imp端口analysis_export并且實現(xiàn)了write()函數(shù)。
? ? ? ? 整個數(shù)據(jù)流是initiator把數(shù)據(jù)push到fifo中，target需要的時候把數(shù)據(jù)從fifo中get出來，注意target定義的都是port端口，fifo的端口都是imp，這樣的好處是uvm_tlm_analysis_fifo既可以實現(xiàn)一端到多端的目的端（已經內置各種數(shù)據(jù)處理函數(shù)）又可以實現(xiàn)數(shù)據(jù)緩存。并且由于initiator和target的端口類型都是port類型，所以不需要內置函數(shù)，只需要調用uvm_tlm_analysis_fifo中已經寫好的函數(shù)即可，降低了整個系統(tǒng)的維護成本。
