前期介面設計用的是Vivado18.3+Modelsim10.6，邏輯綜合及版圖生成的環境是Ubuntu16，邏輯綜合用的工具Design Compiler，生成版圖用的工具是Encounter，

　　下面是關于我做的CameraLink介面的ASIC邏輯綜合和版圖設計流程，重點介紹了邏輯綜合程序：

（1）CameraLink介面實作

（2）功能仿真

（3）邏輯綜合

（4）布局布線及版圖生成

（5）后仿真

1、CameraLink介面實作

1.1、介面設計

　　Camera Link標準技術是在National Semiconductor公司下的Channel Link標準技術下發展而來的，CameraLink標準在ChannelLink標準下的視頻信號的基礎上又多加了6對LVDS，在Camera Link Base/Medium/Full模式下，4對用于相機輸入與影像采集卡輸出的資料傳輸信號，另外2對用于拍攝相機設備和影像采集卡之間的異步串行通信，在標準的CameraLink介面中，數字影像相機信號分為:基于ChannelLink標準的視頻影像資料(PortA-PortH)及使能信號(Fval、Lval、Dval及Spare)、相機控制LVDS信號對(CC1-CC4)、異步串行通信LVDS信號對(SerTFG、SerTC)，標準Camera Link協議一總定義10個埠，每一個埠都是8位，其中bit0被定義為最低位，bit7定義為最高位，而其中的視頻影像資料信號埠又與相機的配置模式相關，相機的配置不同，Camera Link所用到的芯片數量就會不同，而且所用的Cameralink介面物理連接器的數量也會不同，具體如表1所示：

表1介面配置對應相應數值

1.2、CameraLink資料輸出具體實作

　　Camera Link介面配置選擇為Base，而在Base模式下，可以使用1~3×8-bit、1~2×10-bit、1~2×12-bit、14-bit、16-bit及24-bitRGB的Bit assignments，而對于整個系統而言，將使用Base配置下28位總位寬的16-bit，以滿足16位像素資料的輸入要求，

　　在Base配置下，Camera Link的視頻影像資料信號如表2所示：

表2 Base配置下的視頻影像資料信號

　　在Camera Link介面實作中，依據視頻資料信號時序圖來進行資料的傳輸，主時鐘CLK_camera信號的上升沿采集資料，通過對FVAL、LVAL及DVAL的進行時序的操作，設計中選擇了640×512的影像解析度及幀頻F_幀頻=100Hz的資料輸出，為了實作100Hz幀頻需要確定行有效像素時鐘周期個數A=640和行無效時鐘周期個數Q及幀無效時鐘周期個數C，具體的的實作如下計算：F_幀頻= CLK_camera (MHz)/{512×(A+Q)+C},最后主控FPGA將12位并行資料信號和依據F_幀頻產生的FVAL、LVAL及DVAL送入Camera Link介面Camera Link視頻資料信號時序如圖1所示：

圖1 Camera Link視頻資料信號時序圖 

2、功能仿真 

　　在Camera Link模塊的仿真中，加載了CMLink_ctrl和CMLink模塊，通過16 bit像素值dat信號輸入至CMLink模塊，結合camera_pause、empty、read_en使能等信號按照《Camera Link Specifications v2.0》手冊將16 bit像素值信號轉換至28 bit并行tx資料進行像素輸出，如16’h01c2轉換至28’hf0000a2，介面需要在視頻幀有效信號fvalReg、行有效信號lvalReg及資料有效信號dvalReg處于高電平時進行像素資料的傳輸，其中fvalReg、dvalReg、lvalReg、dat、tx信號仿真如圖2所示：

 3、邏輯綜合

　　綜合是完成從RTL代碼到門級電路的轉換，如果在綜合時，鏈接了廠家的庫檔案，則門級電路使用的器件是廠家庫檔案中提供的器件，綜合在整個IC設計中，起到的作用如圖4所示，

圖 4 綜合在IC設計中的作用

3.1 綜合的特性

3.1.1 綜合是由約束驅動的

　　對于一個設計來說，在進行綜合前，需要給這個設計加上約束，約束也就是綜合的目標，綜合工具會竭力滿足約束，以實作綜合的目標，約束可分為多方面，如時序方面的約束、面積方面的約束、環境屬性方面的約束、驅動和負載方面的約束等，其中最重要的約束是對時鐘等與時序相關的屬性進行約束，在綜合時，約束的各個方面可能存在一定的矛盾，如對速度和面積的約束，見圖2所示，綜合的程序就是找到一個最好的平衡點，滿足各個方面的約束，

3.1.2 綜合是基于path分析的

　　在整個綜合的程序中，完成是基于path進行時序分析的，因此path的概念非常重要，何謂path？如下圖5所示，

圖 5 Timing Path的概念

　　Path是綜合工具進行時序分析的基本單位，對于一條path而言，它的起點只能是輸入埠，或者觸發器/暫存器的時鐘端；終點只能是輸出埠，或者觸發器/暫存器的資料輸入端（對D觸發器而言，就是D端），

結合圖3而言，其中共有4條path，分別為：

1） 輸入埠A －> FF2的D端；

2） FF2的CK端－> FF3的D端；

3） FF3的CK端－> 輸出埠Z；

4） 輸入埠A －> 輸出埠Z，

　　同一個時鐘域多條path，組成一個組，稱為path group，與任何時鐘都沒有關系的path也組成一個組，成為default path group，結合圖3而言，有2個path group，其中path 2和path 3 屬于時鐘CK的path group，path 1和path 4屬于default path group，

　　在計算一條path的延時資訊時，是將這條path上所有線延時加上所有的器件單元延時，

3.2  綜合的步驟

　　對于Design Compiler而言，綜合的步驟如下：

1） 將需要進行綜合的設計讀入Design Compiler的記憶體中；

2） 對設計添加合適的約束；

3） 對設計進行綜合優化；

4） 分析綜合的結果是否滿足要求；

5） 如果滿足要求的話，保存綜合的結果，

綜合的主要程序也可以用圖6進行表示，

圖6 綜合的主要程序

3.3 Design Compiler簡介

3.3.1 Design Compiler介面模式

Design Compiler是Synopsys公司推出的綜合工具，在業界有較廣泛的應用，

Design Compiler有三種介面方式：圖形化介面、dc shell介面和dc shell tcl介面，

圖7 Design Compiler的介面方式

　　對于初學者來說，建議使用圖形化方式，便于使用，同時建議打開命令視窗，以便可以盡快熟悉Design Compiler的命令，圖形化方式需要占用較多的記憶體資源，運行速度相對命令列方式來說較慢，

3.3.2 Design Compiler啟動腳本檔案

　　Design Compiler啟動時需要執行一個啟動腳本檔案，該檔案名為.synopsys_dc.setup，執行該腳本檔案幫助DC鏈接指定的庫檔案，也就是綜合需要使用的廠家庫檔案，庫檔案是由廠家提供的，而不是由Synopsys公司提供，

.synopsys_dc.setup檔案可以放在下面三個目錄下：

1）$SYSNOPSYS/admin/setup

2）用戶的home目錄

3）用戶的當前作業目錄

　　DC啟動時搜索.synopsys_dc.setup檔案的順序為先查找用戶的當前作業目錄，然后查找用戶的home目錄，最后再查找$SYSNOPSYS/admin/setup目錄，

　　若在用戶的當前作業目錄下存在.synopsys_dc.setup檔案，則直接使用該檔案啟動DC，建議將.synopsys_dc.setup檔案放在用戶的當前作業目錄下，方便使用和修改，.synopsys_dc.setup檔案中需要為DC指定鏈接的庫檔案，這是通過設定target_library，link_library，symbol_library等保留字變數實作的，

　　target_library指定的庫檔案是DC在搭建電路時使用的庫，在DC映射的程序中，會根據電路功能選擇庫中的器件，并在時序分析時，使用庫中各器件的timing資料，link_library指定的庫中包含HDL源代碼所有單元的示例，綜合使用的線載模型和作業環境模型，symbol_library指定的庫用來將庫中的器件用圖形表示出來，下面是一個.synopsys_dc.setup檔案的例子（節選其中部分內容），

　　另外，為了能使用戶當前作業目錄的條理清晰，建議在DC的當前作業目錄下，劃分source、scripts、mapped和reports等子目錄，在source子目錄下存放RTL源代碼，scripts目錄下存放綜合的各種約束檔案，mapped目錄下存放綜合后的網表檔案，reports目錄下可以用來存放各種報告檔案，

3.3.3 Partition的意義

　　Partition是把復雜的、規模較大的設計劃分為多個規模適中的部分，以便綜合時間不要過長，比較容易得到滿足要求的綜合結果，Partition應該在撰寫RTL代碼前進行，在方案設計時就充分考慮模塊的大小、模塊間的連接等要素，只有這樣才能夠得到比較好的partition結果，綜合中，能夠對partition進行一定的調整，但效果有限，所以這里要強調，partition應該在撰寫RTL代碼前進行，綜合中進行partition的主要原則有：

1） 不要有組合邏輯穿過層次邊界；

2） 每個層次邊界，最好以暫存器做輸出；

3） 不要有膠合邏輯（glue logic）穿過層次邊界；

4） 限制每個塊（block）的大小；

5） 把輸入輸出pad、時鐘產生模塊、JTAG模塊和核心邏輯分開，

下面結合多個例子，說明partition的原則，

例1：

圖8 Partition的原則（例1）-a

　　這個例子中，模塊B是一個純組合邏輯的電路，跨接在模塊A和模塊C之間，違背了原則1，另外模塊A以組合邏輯輸出做為層次的邊界，違背了原則2，

　　對于例1來說，較好的partition方式如下圖所示，

圖9 Partition的原則（例1）-b

　　例2：每個模塊都是以暫存器輸出，滿足原則2，所以是一個比較好的partition結果，

圖10 Partition的原則（例2）

　　例3：在這個例子中，模塊A、B、C間有一個兩輸入與非門，這個兩輸入與非門屬于膠合邏輯，穿過了模塊A、B、C的邊界，違背了原則3，

圖11 Partition的原則（例3）-a

　　對例3的修改方法如下圖所示，

圖12 Partition的原則（例3）-b

　　例4：這個例子中，時鐘產生模塊、異步邏輯模塊、輸入輸出PAD、JTAG模塊與核心邏輯模塊CORE是劃分開的，滿足原則5，是個很好的partition，

圖13 Partition的原則（例4）

3.3.4 約束檔案

　　學習使用DC的命令，設定約束，是本教材的核心內容，

對一個需要進行綜合的設計，如果不加任何約束就進行綜合是沒有任何意義的，只有加上了合理的約束后，綜合演算法才有目標，才能綜合出滿足需求的電路，對設計需要加上的所有約束、命令可以寫入腳本（script）檔案中，就成為約束檔案，一般情況下，約束檔案中應該包括以下內容，如下圖14所示：

圖14 約束檔案的基本內容 

　　其中主要有對時鐘的定義，并定義時序方面的其他約束，如設定input delay，output delay等，對于輸入信號、輸出信號，還要考慮其驅動、負載問題，這是通過設定輸入信號的driving cell，設定輸出信號的load來實作的，作業條件對芯片性能的影響也是必須考慮的因素，需要設定operating condition，隨著制造工藝的不斷提升，線延時成為延時資訊中越來越重要的部分，因此也要考慮設定線載模型，這些是主要的約束條件，在實際作業中，約束檔案中還需要其他一些約束條件，詳細情況見下面的章節，

3.3.5 綜合策略和方法

3.3.5.1 自上而下的綜合策略

自上而下綜合的步驟一般包括：

1） 把整個設計讀入DC的存盤區中；

2） 解決多次實體的問題；

3） 對最高層模塊加上合適的約束；

4） 綜合

5） 評估綜合的結果

6） 保存綜合結果

這里需要注意多次實體化的問題，

 圖15  設計中出現多次實體化

　　圖15中，在D_design中子模塊Ades被實體化了兩次，在自上而下綜合策略中，要解決其多次實體話問題，必須通過uniquify命令，執行該命令后，子模塊Ades的每次實體化將對應唯一的一個design名，如圖16所示，U1對應的design名為Ades_0，U3對應的design名為Ades_1，這樣Ades_0和Ades_1綜合出的結果有可能存在差異，

 圖16 uniquify解決多次實體化問題

　　下面是一個自上而下綜合策略的例子（dc shell script模式），其中D_constraints.scr是約束檔案，其中包括各種約束命令，

　　current_design D_design

　　include D_constraints.scr

　　uniquify

　　compile

　　自上而下策略對規模不大的設計是非常適用的，而且使用起來簡單方便，不需要考慮模塊之間的關系，因此花費的人工很少，但是另一方面，由于該策略需要把整個設計讀入DC的memory，并進行綜合，對于規模比較大的設計，會占用大量的系統資源，如CPU、memory等，綜合時間也會非常長，

3.3.5.2 自下而上的綜合策略

自下而上綜合的步驟一般包括：

1） 把整個設計分成若干子塊，對每個子塊分別加約束，并進行綜合；

2） 每個子塊的綜合結果必須滿足其約束條件；

3） 對最頂層模塊加約束條件；

4） 為綜合過的每個子塊設定dont touch屬性

5） 綜合；

6） 評估綜合的結果

7） 保存綜合結果

　　采用自下而上策略，非常容易解決多次實體化的問題，以圖32為例，首先對Ades子模塊加約束，并進行綜合，檢查Ades子模塊的相關報告，當其滿足所有約束條件時，為其設定dont touch屬性，再對D_design模塊加約束，進行綜合即可，

　　下面是自下而上方式綜合圖32所示設計的script檔案（dc shell tcl模式）

　　read_db unmapped/A_des.db

　　set current_design Ades

　　source Aconstraints.tcl

　　compile

　　read_db unmapped/D_design.db

　　link

　　set current_design D_design

　　set_dont_touch [get_design Ades]

　　source Dconstraints.tcl

　　compile

　　用compile+dont_touch這種方式也可以解決多次實體化問題，采用這種方式，子模塊Ades只被綜合了一次，U1和U3是對同一個Ades的實體化，自下而上綜合策略通過分塊綜合的方法，可以綜合非常大的設計，對綜合的設計規模幾乎沒有限制，但這種方法需要撰寫多個約束檔案，而且各個塊之間的關系必須由工程師考慮，增加了人工，另外若各個子塊滿足各自的約束，而頂層模塊無論怎樣都不能滿足約束條件時，需要再回傳到子塊的綜合，重新規劃子塊的約束，

3.3.6 優化的引數選擇

　　compile程序分為三個層次：結構層、邏輯層和門級層，

　　結構層是最高層次的綜合、優化，主要完成選擇合適的DesignWare，運算式的公共部分共享，資源共享和運算子的重新排序，這部分同coding style關系緊密，

邏輯層完成從GTECH單元到邏輯單元的優化，門級層最終完成組合邏輯和時序邏輯的映射，

3.3.6.1 Compile –map_effort

　　優化的努力程度是可選的（low、medium、high），默認情況是medium，建議對一個設計進行第一次綜合時，采用默認值，選擇high時會占用較多的CPU時間，而且不能保證解決所有問題，

3.3.6.2 Compile –incremental_mapping

　　-incremental_mapping選項只能對已經是門級電路的設計進行，這時不會再回傳到GTECH，也就不再進行邏輯層的優化，使用這個選項時，優化的執行速度非常塊，當timing分析時，出現的violation非常少，并且slack值較小時，建議使用這個選項，

3.4 邏輯綜合整個檔案程序

　　DC綜合報告（功耗 面積 時許報告）

圖17 DC綜合報告

3.6 綜合后重要檔案

4、布局布線及版圖生成

4.1 布局布線準備程序及實作

圖18 版圖設計后的功耗及時序報告

圖19 CameraLink版圖 

5、后仿真

　　在后仿程序中，觸發器需要滿足工藝庫中的Hold和Setup時間,并在實際電路有延遲情況等等，可以通過對波形的對照來判斷后仿真的仿真情況，但是最終是沒有影響功能，

 圖 22 后仿圖示

標籤：Verilog

上一篇：通用的Django注冊功能模塊實作

下一篇：多型