開放核協(xié)議—IP核在SoC設(shè)計中的接口技術(shù)

摘    要：本文介紹了IP核的概念及其在SoC設(shè)計中的應(yīng)用，討論了為提高IP核的復(fù)用能力而采用的IP核與系統(tǒng)的接口技術(shù)。
關(guān)鍵詞：SoC；IP核；OCP

引言
隨著半導(dǎo)體技術(shù)的發(fā)展,深亞微米工藝加工技術(shù)允許開發(fā)上百萬門級的單芯片，已能夠?qū)⑾到y(tǒng)級設(shè)計集成到單個芯片中即實現(xiàn)片上系統(tǒng)SoC。IP核的復(fù)用是SoC設(shè)計的關(guān)鍵，但困難在于缺乏IP核與系統(tǒng)的接口標準，因此，開發(fā)統(tǒng)一的IP核接口標準對提高IP核的復(fù)用意義重大。本文簡單介紹IP核概念，然后從接口標準的角度討論在SoC設(shè)計中提高IP核的復(fù)用度，從而簡化系統(tǒng)設(shè)計和驗證的方法，主要討論OCP(開放核協(xié)議)。

圖1 OCP工作原理示意圖

圖2  讀/寫操作的時序

圖3  讀/寫狀態(tài)機

OCP簡介
基于IP核復(fù)用技術(shù)的SoC 設(shè)計使芯片的設(shè)計從以硬件為中心轉(zhuǎn)向以軟件為中心，芯片設(shè)計不再是門級的設(shè)計，而是IP核和接口及其復(fù)用設(shè)計。IP核集成到系統(tǒng)所要考慮的問題包括：同步，例如全局執(zhí)行、數(shù)據(jù)交換和協(xié)議方面的同步操作；協(xié)議轉(zhuǎn)換，不同模塊間不兼容的協(xié)議的轉(zhuǎn)換，封裝可用來解決這個問題，但需要考慮時序約束；I/O緩存，為滿足系統(tǒng)行為和時序約束可能需要緩存數(shù)據(jù)。另外，出于對核設(shè)計的保護會故意隱藏一些信息，而這些信息在集成時可能需要。為解決這些問題需要一個好的接口標準，一些大公司現(xiàn)在已有自己的IP核接口標準，比如Altera的Avalon，Atlantic、IBM的CoreConnect、ARM的AMBA等。因為核的多樣性，使用完全相同的接口是不現(xiàn)實的，OCP將軟件中的分層概念應(yīng)用到IP核接口，提供一種具有通用結(jié)構(gòu)定義、可擴展的接口協(xié)議，方便了IP核與系統(tǒng)的集成。
OCP協(xié)議使IP核與系統(tǒng)的接口與IP核的功能無關(guān)，設(shè)計人員不需要了解核內(nèi)部也能利用它進行系統(tǒng)設(shè)計。OCP接口允許設(shè)計者根據(jù)不同的目的配置接口，包括接口的數(shù)據(jù)寬度、交換的握手協(xié)議等，在SoC設(shè)計中可以裁剪核的功能，降低設(shè)計復(fù)雜性，減小面積，同時滿足SoC的要求；OCP接口還保持核在集成到系統(tǒng)的過程中自身完全不被改變，就是說在總線寬度、總線頻率或電氣負載有變化時核保持不變。使用OCP接口的設(shè)計可以交付即插即用的模塊，同時支持核的開發(fā)與系統(tǒng)設(shè)計并行，節(jié)省設(shè)計時間。

OCP接口運行機制
OCP定義兩個通信實體間點到點的接口。其中一個實體作為通信的主體(Master)，另一個作為從體(Slave)。只有Master可以發(fā)命令，Slave響應(yīng)Master的命令，接收或發(fā)送數(shù)據(jù)。封裝接口模塊必須擔當每個連接實體的對應(yīng)端，當連接實體是Master時，封裝接口模塊就作為對應(yīng)的Slave；當連接實體是Slave時，封裝接口模塊作Master。
OCP的工作原理如圖1所示。圖中有三個IP核，其中左邊標有Initiator的IP核是通信的發(fā)起方，作Master；右邊標有Target的是通信的目標方，作Slave；中間的既可作Master又可作Slave；下面的框圖代表封裝接口模塊；從Master出來并進入Slave的箭頭表示請求命令，從Slave出來并進入Master的箭頭表示響應(yīng)；加黑的線段代表片上互連總線。兩個IP核通過接口通信的過程是：作為Master的 IP核發(fā)出請求命令給對應(yīng)的Slave端(總線封裝接口模塊)；封裝接口模塊通過片上總線將請求命令(OCP并不指定片上互連總線的工作機制，而是把OCP命令轉(zhuǎn)換成總線上的傳送)傳送給接收方的總線封裝模塊；接收方的總線封裝模塊再作為Master把這種內(nèi)部總線傳輸轉(zhuǎn)換成合法的OCP命令傳送給目標IP核；其作為Slave方接收命令并執(zhí)行所要求的操作。
每一個OCP接口都是可根據(jù)連接實體的要求進行配置的(通過選擇需要的信號或某一信號的位寬)，也是互相獨立的，例如系統(tǒng)中通信發(fā)起者總是會需要比目標方更多的地址位數(shù)用來選擇發(fā)起者所要求的目標。
OCP接口信號
OCP通過命令完成實體間的通信操作，在接口為選擇的命令配置相應(yīng)信號，所有的信號都是在時鐘上升沿采樣，是完全的同步設(shè)計。OCP接口信號包括數(shù)據(jù)信號、邊帶信號和測試信號。數(shù)據(jù)信號又分為基本信號、簡單擴展信號、猝發(fā)信號和多線程擴展信號。所有IP核都需要基本數(shù)據(jù)信號中的一組信號，其他可選信號用于支持通信需要，實現(xiàn)可配置和可擴展性。
基本數(shù)據(jù)信號包括：Clk、MAddr、MCmd、MData、MDataValid、MRespAccept、SCmdAccept、SData、SDataAccept、SResp。其中只有CLK和MCmd是必須的，其他可選。Mcmd是傳輸命令，指出主方OCP傳輸類型，包括讀、寫和廣播類型的八種命令。簡單擴展信號增加了OCP接口地址空間、字節(jié)使能和核在不同階段的特征信息。猝發(fā)式擴展信號允許猝發(fā)傳輸，可設(shè)置不同猝發(fā)傳輸模式的參數(shù)。多線程擴展信號支持OCP接口的多線程處理。邊帶信號傳送諸如復(fù)位、中斷、錯誤和核特性標志等控制信息，也是IP核與系統(tǒng)間交換控制和狀態(tài)信息的手段，可以同請求／響應(yīng)信號異步，但與時鐘上升沿同步。測試信號支持掃描、時鐘控制和JTAG。

OCP接口時序及接口狀態(tài)機
以簡單讀寫操作的時序為例說明OCP接口時序要求，如圖2所示。
在上升沿1處OCP Master方通過將MCmd由Idle變?yōu)閃r開始進入請求狀態(tài)，在此周期內(nèi)把地址A1和數(shù)據(jù)D1分別送到MAddr和MData信號線上，Slave必須在同一個周期內(nèi)發(fā)出SCmdAccept有效信號；Slave在上升沿2處開始接收地址和數(shù)據(jù)并進行內(nèi)部寫操作；在上升沿4處MCmd賦值為Rd，OCP進入讀請求狀態(tài)，在這個周期內(nèi)Master方將地址放在MAddr信號線上，在同周期Slave發(fā)出SCmdAccept有效信號；在上升沿5處Slave方置SResp為DVA從而開始響應(yīng)階段，請求階段結(jié)束，根據(jù)從MAddr獲得的地址讀取數(shù)據(jù)并放到SData信號線上；在上升沿6處開始Master方收到Slave的響應(yīng)信號并開始讀數(shù)據(jù)，響應(yīng)階段完成。
圖3是在讀、寫操作中請求階段和響應(yīng)階段主、從兩方的狀態(tài)機。
Master和Slave都是從IDLE狀態(tài)開始，當檢測到MCmd變?yōu)樽x或?qū)憰rMaster轉(zhuǎn)為請求階段，Slave轉(zhuǎn)到讀或?qū)憼顟B(tài)。如果是讀操作，Master的請求狀態(tài)持續(xù)到SCmdAccept有效，Slave在完成讀操作后發(fā)出SCmdAccept有效信號并置SResp為DVA，Slave變?yōu)轫憫?yīng)狀態(tài)，Master進入IDLE狀態(tài)；SResp是NULL時，Slave沒有進入響應(yīng)狀態(tài)Master進入Wait Resp狀態(tài)，等待Slave進入響應(yīng)狀態(tài)。如果是寫操作，沒有響應(yīng)信號，當SCmdAccept有效時Master的請求階段結(jié)束進入IDLE狀態(tài),Slave處理寫操作，完成后進入IDLE狀態(tài)。
結(jié)語
OCP是基于核的免費開放的接口協(xié)議，可以根據(jù)不同IP核的通信要求進行配置和擴展，能夠?qū)崿F(xiàn)硬件集成真正的即插即用，允許系統(tǒng)集成根據(jù)應(yīng)用需要選擇最好的IP核和互聯(lián)機制。OCP為IP核設(shè)計提供了解決可配置性和接口的較好辦法，實現(xiàn)了IP核與系統(tǒng)集成的Socket接口，能夠做到核的模塊化和即插即用特性?！?/p>

參考文獻
1 The Importance of SoCkets in SOC Design. http://www.ocpip.org
2 Steven J.E. Wilton and Resve Saleh .Programmable Logic IP Core s in SoC Design : Opportunities and Challenges. Proceedings of the Custom Integrated Circuits Conference, 2001, p 63-66