　　前期接口设计用的是Vivado18.3+Modelsim10.6，逻辑综合及版图生成的环境是Ubuntu16，逻辑综合用的工具Design Compiler，生成版图用的工具是Encounter。

　　下面是关于我做的CameraLink接口的ASIC逻辑综合和版图设计流程，重点介绍了逻辑综合过程：

（1）CameraLink接口实现

（2）功能仿真

（3）逻辑综合

（4）布局布线及版图生成

（5）后仿真

1、CameraLink接口实现

1.1、接口设计

　　Camera Link接口标准是数字相机和图像采集卡的规范说明，让两者之间能够以High-Speed的速率进行多bit图像数据及使能信号、四对LVDS通用相机控制信号及两对LVDS异步串行通信信号等信号的传输。其技术在低压差分信号LVDS传输的基础上加载了串并转换器，能够实现数据传输的可靠性。

　　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接口配置对应相应数值

Camera Link 接口配置	端口	数据位宽(Max)	芯片	连接器
Base	A~C	28	1	1
Medium	A~F	56	2	2
Full	A~H	84	3	2

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配置下的视频图像数据信号

视频图像数据信号	位数	描述
Date	24	图像数据
FVAL	1	帧有效信号
LVAL	1	行有效信号
DVAL	1	数据输出有效信号
SPARE	1	备用信号

　　在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所示：

图 2 Camera Link 接口像素数据传输

　　在设计目标中，需要实现 640×512 的图像分辨率及帧频 F 帧频=100Hz 的数据输出，而产生 640×512 的图像分辨率及帧频 F 帧频等于 100Hz 具体实现方案，即帧有效信号、行有效信号及数据有效信号满足图 1 Camera Link 视频数据信号时序图及 F 帧频计算，一行包含 640 个像素点，一帧图像包含 512 行有效的像素数据。在帧有效信号为高电平时，行有效信号与数据有效信号规律性变化，实现图像行像素的输出，而在整个帧有效信号为高电平时，实现帧像素输出，仿真结果如图 3 所示：

图 3 Camera Link 接口图像像素及 F 帧频的实现

3、逻辑综合

　　逻辑综合分为三个阶段：

　　（1）、转译（Translation）：把电路转换为 EDA 内部数据库，这个数据库跟工艺

库是独立无关的；

　　（2）、优化（Optimozation）：根据工作频率、面积、功耗来对电路优化，来推断

出满足设计指标要求的门级网表；

　　（3）、映射（Mapping）：将门级网表映射到晶圆厂给定的工艺库上，最终形成

该工艺库对应的门级网表。

　　综合是完成从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的实例化。自下而上综合策略通过分块综合的方法，可以综合非常大的设计，对综合的设计规模几乎没有限制。但这种方法需要编写多个约束文件，而且各个块之间的关系必须由工程师考虑，增加了人工。另外若各个子块满足各自的约束，而顶层模块无论怎样都不能满足约束条件时，需要再返回到子块的综合，重新规划子块的约束。