IC设计实现流程的自动化

点赞:10150 浏览:43167 近期更新时间:2024-01-30 作者:网友分享原创网站原创

摘 要 :IC设计从代码设计到最终的投片(tapout),中间会经过多步实现流程,一般来说,包括前端的代码风格检查、cdc(clock domain Cros sing)检查、综合、功能一致性检查、静态时序分析以及整个后端的PR.本文提供一种流程自动化的平台设计,以提高设计实现的效率以及准确性,该平台主要针对于前端的实现流程,不包括后端的PR流程.

1 概述

一般来说,IC产品从一开始的spec写作到最终tapout,都要经过一些特定的步骤.特别是其实现过程,即从代码设计完成,到tapout,其中要经过包括前端的代码风格检查(如leda)、跨时钟域路径(cdccheck)检查、综合(synthesis)、功能一致性检查(如form~)、静态时序分析(STA).有的时候,因设计的需要,可能还会包括power的分析、可测试性设计(DFT)、边界扫描设计(DSD)等等.在这之后会有一版正式的网表(neflist)和约束文件(sdcfile)提供给后端以做布局布线,并最终得到tapout所需的GDSII文件.在整个后端PR的同时或者tapout之前,还必须不停地做功能一致性检查和静态时序分析,以保证PR的改动不会影响到我们设计所期望的功能和性能.

在上述这些步骤中所用到的工具均不一样,并且每一步可选用的工具也很多.目前市场上有synopsys、cadence、mentor、spyglass等多家公司提供相应的工具,这使得负责设计实现的工程师不仅要熟悉每一个步骤的技术上的原理,同时要对各种工具的用法有一定了解.但是工具的更新不可避免,而项目负责人的变更也比较正常,这两个原因使得设计实现流程上存在着不少弊端,因而也很大程度上影响了项目的进度和可靠性.这些弊端一般有以下几点:


1.每个步骤的运行的品质极大地依赖于运行的人(下面简称owner);

2.owner的变更有可能导致项目进度的延缓;

3.工具的变换或者更新,会影响运行结果,使得早期未记录工具版本的结果无法顺利重现;

4.每个项目重新开始,有许多重复性操作,效率不高;

5.当不熟悉这些步骤的owner以外的工程师想得知该步骤的运行结果时,必须要从owner那里获得.

基于以上的弊端,本文提出一种自动化的实现流程方法,该方法在一个成熟的流程样板的基础之上,利用perl语言脚本和csh简单程序以及一个简单的项目配置文件,自动生成实现流程中所需要的所有tcl脚本和运行文件.这样,当一个项目开始时,可以仅仅通过修改项目配置文件,用简单的命令来得到所有的所需的文件和脚本,降低了人为错误,提高了效率.由于本方法的基础是一个成熟的流程,这个流程是经过同组或相关负责人认可的,所以也在一定程度上降低了每个步骤运行质量对owner的依赖程度.最后,在owner将整个flow环境调试好了并将其checkin到版本管理系统(如SVYI)中以后,其他同组人员可以快速地从版本管理系统中得到这个环境,井决速地运行以得到结果.

2.实现流程自动化平台的搭建

实现流程自动化平台的搭建包含三个部分:成熟的流程模板、文件版本管理系统和规范化的统一运行环境.

成熟的流程模板

在实现流程的各个步骤中,每一个步骤都是一个子流程,如synthesis子流程,sta子流程等.为这些子流程建立一个成熟的流程模板是实现流程自动化的基础.这些子流程的模版必须经过严格的讨论,须保证在大部分情况下其设置都是适用的.

流程模板实际上就是运行工具时所需的脚本文件,其内容包括设置的项目变量、流程控制变量、运行流程所用工具特有的变量、环境变量以及运行的命令(mand)等.当工具全面运行完脚本里面的所有mand后,该子流程应该全部结束,并提供所需的报告文件和下一步所需的输入文件.

项目变量是根据项目的变化而设置的变量,这样该脚本在改变了项目名以后还可以被继承使用;流程控制变量是用以控制流程的变量,如在本流程中要做哪些事情,要得到哪些报告,是否备份等;运行所用工具特有的变量则是与该子流程直接相关的变量,这些变量都是工具本身定义的变量,用以控制实际执行命令的行为,例如,如何优化、如何对待常数寄存器等;环境变量主要定义一些读取文件的地址以及名称、报告存放的地址及文件名称等;运行的mand则是流程的主要部分,因工具的不同而不同.

一个完整的流程模版可以是一个完整的tcl脚本文件,也可以是多个子文件,被一个顶层的tcl文件调用,这些子文件放在规范化的目录机构中.以synthesis为例,若当前项目名为projectl,使用synopsys的design pile工具,那么其流程模版脚本如下:

项目变量部分:

set projectName projectl

set mnType DC

流程控制变量部分:

set exitdc false ,# true/false.To be true,the processwill exit DC after finishing the synthesis

IC设计实现流程的自动化参考属性评定
有关论文范文主题研究: 关于流程的论文范例 大学生适用: 学术论文、学校学生论文
相关参考文献下载数量: 19 写作解决问题: 学术论文怎么写
毕业论文开题报告: 论文提纲、论文题目 职称论文适用: 刊物发表、高级职称
所属大学生专业类别: 学术论文怎么写 论文题目推荐度: 优质选题

set backup true ,

set rptDesignInfo true

工具特有的变量部分:

set hdlin_auto_se_templates trueset pile_no_new_cells_at_top_level trueset verilogout_no_tri true等

环境变量部分:

set hdlFileList  "../../../hall/list/project 1.lst"

set workPath ../-./syn/work

set rptDir ../../syn/rpts

mand 部分 :

source -echo -verbose ../../..

/scripts/syn/designReadln_syn.tcl

link

check_design

source -echo -verbose ../../../scripts/synstDsg.

tcl

pile

当tcl脚本被正确、完整地执行完毕后,该子流程就完成了,所有的report和下一步子流程所需的输入文件都会正确地产生出来,并存放在规范化的统一的目录结构当中.

文件版本管理系统:

文件版本管理系统是自动化平台不可缺少的一环,只有项目进入版本管理系统,其文件才能被同组人或其他有权限的相关工程师所共享,在统一的运行环境平台下,非流程owner的工程师才能自主运行某些流程以快速得到结果. 目前市场上有多种版本管理工具,如Perforce、Clearcase、evs、svn等等.可以根据实际情况任选一种.

规范化的统一运行环境:

任何一个自动化平台的搭建都必须有一个规范化的统一运行环境,并且项目组中所有人员都遵从这个环境.只有满足这一点,我们运行的环境和脚本才能高效地、自动地由工具产生出来,工程师就可以将大部分精力集中放在项目具体技术问题的分析和调试上面.

统一的运行环境并不是呆板的统一化,而是指宏观上大部分架构的统一,对于细节的部分也应该保有一定的灵活性,如提供一些与平台的交接接口等,以便我们的工程师可以在其自己所负责的局部环境里自由发挥.

一般来说,IC设计在代码稳定之前,都要做coding style的检查和cdc检查,以保证代码的可实现性和稳定性,减少后面实现时因这方面的无谓反复;之后会进入synthesis环节,以产生网表(list)和标准的约束文件(sdc),当面积/时序/初步功耗都在可接受范围里面,并且功能一致性检查通过之后,就可以将neflist和sdc提供给后端作初步的floorplan和pr了.然后便进入时序收敛的过程,在这个过程中每一次前后端交互都需要做功能一致性检查和sta分析.当时序收敛后,就可以抽取sdf文件提供给验证的工程师进行门级仿真了,后端工程师也会进行下一步的lvs和drc清理操作,最后到tapout.

因此,我们可以将这个运行环境结构规范如下图1所示,因本文的重点在于实现流程的自动化,所以layout和verifICation目录结构仅有一个粗略的结构.

3 自动化实现

当自动化平台搭建的三个要素都满足了后,我们就可以实现这个自动化流程了.

整个实现方法如图2所示.

在这个自动化过程当中会产生两大类型的文件:一个是项目运行环境的目录结构,这个就是规范化的统一运行环境;另一个就是各个子流程中所用到的运行文件和脚本.

要想针对不同的项目自动产生上述文件,需要两个条件:一个是项目配置文件,这个是针对不同项目而有所不同的文件,自动生成流程中所要用到的项目信息都必须在这种文件中找到,它可以是一个文件,当项目信息量特别大的时候,为了提高文件处理速度也可以由多个配置文件组成;另外一个内容就实现自动化的程序库,perl和csh均可以实现.

由上可见,自动化实现的过程就是定义项目配置文件和开发perl/csh脚本库的过程.

项目配置文件一般是定义一些具体项目的信息,如项目名称、所使用的工艺、clock信息、reset信息以及工具版本信息等等,能够方便开发perl程序的所有信息都可以定义其中,定义的时候要注意其唯一性,方便perl的提取.

而perl/csh脚本的开发则是一个比较长期的完善过程.这些脚本的目的就是将我们规范化的运行环境目录结构和成熟的子流程模板通过从项目配置文件中所提取的信息具体的细化到实际项目当中去,由于是程序自动生成这些目录和文件,所以效率非常高,且不会发生人为的错误,即使在项目进行的中期进行大的信息调整(如项目名、clcok名等),也可以快速地更新所有的文件.

当项目平台生成后,各个流程的owner会对自己所负责的部分进行初始流程调试,稳定后checkin到版本管理系统中去.当项目人员发生变动时,只要将这个环境从版本管理系统的server上checkout出来,就可以快速地进入项目.

另外当项目进行到时序收敛的这个阶段时,前后端的交互比较频繁,有的时候后端工程师出了一版网表和寄生参数文件(spef)后,想要快速地知道这一版的STA和功能一致性检查(formal)结果,而前端的时序工程师因故无法短时间进行STA和folmal检查,那么,后端工程师可以将sta/formal的环境从sever上check out下来,这个时候sta/formal一般都已经稳定了,后端工程师只要运行某个特定maketarget即可.

4 结论

传统的实现流程采用百家争鸣的人为方式进行,在很大的程度上过于依赖于流程owner,因此在人员变动或者工具变更的情况下会出现项目进度缓慢、无法重现以前的问题、可靠性不高及效率低下等缺点.规范化统一的设计及实现平台,采用成熟的各子流程模板,并引入文件版本管理系统,最终实现流程的自动化可以极大地改善这些弊端,提高了产品的性能及其可靠性,并加强了前后端交互,缩短了时序收敛周期,因此也就加快了产品开发周期,提高了效率.