一、概述

   SOC（System On Chip）,即所谓的片上系统。它将原来分立的各个功能模块全部组织到一块单芯片上，实现系统的高集成度。SOC设计包含的内容非常广泛，本文只讨论基于Synospsy公司的ARC HS处理的SOC前端设计相关内容，后端综合及版图相关的没有涉及。

二、环境和工具

每一次总结文章，都是对之前经历的一种梳理，让大脑能够将繁杂的知识和经验整理得有序，以利于后续得使用。本系列文章依旧先对环境和工具的进行介绍。在前面的系列文章中已经对IC设计常用的软件及系统环境做过简单的介绍，主要介绍在IC设计的每一步流程中该用什么工具，但没有从项目的角度解释，一个完整的项目，可能需要用到哪些工具来管理整个项目流程。而本部分内容所介绍的工具主要是有关于IC设计项目管理方面所用到的软件工具以及它们是如何发挥作用的。另外，之前介绍过的各类脚本语言在本部分内容中将做一次集中的用途介绍。

2.1 Wiki & Jira & SVN & Jekins

Wiki (多人协作写作系统)是一种超文本系统，也就是一套网页组成的系统，它并不是一个软件，而是一种概念集合，许多软件都可以实现Wiki的功能，比如Confluence是一种常用的Wiki。互联网上的维基百科，百度百科等wiki是一种开放性的wiki，可以供网上的所有人来维护和管理。它的功能就是实现多人协作写作。公司项目管理可以利用它来组织项目的各类参考资料、设计文档、项目进度安排等内容。对于SOC设计而言，最重要的是组织各类模块的设计文档、IP相关资料、项目进度记录等内容。

Jira 是一个缺陷跟踪管理系统，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。在SOC设计中，主要用于记录开发过程中遇到的问题、BUG，安排其他人的任务记录、会议记录等等。

有关于Wiki 和 Jira 的安装和使用请参考其他人的博客。https://www.cnblogs.com/baiyuer/p/10396937.html

SVN （Subversion）是一个开放源代码的版本控制系统。主要应用于源代码的管理（C, C++ , Java等等），对于SOC设计而言，它把项目有关的模块RTL代码，IP验证环境等进行版本控制与管理，使得设计人员与验证人员能方便的进行协同工作，项目经理能知道目前项目进度等等。有关SVN的使用请参考https://www.runoob.com/svn/svn-intro.html https://blog.csdn.net/gsg8709/article/details/79435741

Jekins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。从Jekins的定义来看很难理解它的SOC设计中所起到的作用，这里简单的解释一下。在SOC设计中，RTL代码和UVM验证环境会不停的迭代更新，更新完了之后又需要再重新跑一遍验证的流程。由于这个流程是程序化的，所以，可以将这样的任务交给Jekins来完成。每一次提交（commit）RTL代码或者模块的验证环境到SVN版本控制系统中之后，就可以触发Jekins来对芯片TOP层进行回归验证（当然这需要配置Jekins），以验证更新的文件是否影响到已经Pass了的验证case。当Jekins跑完回归验证之后，会将验证结果发布到网页（公司内部部署好的内网）上，供设计相关人员参考。有关Jenkins的详细介绍，https://www.cnblogs.com/jimmy-xuli/p/9020825.html

Wiki & Jira 用于项目文档管理以及问题Bug跟踪，SVN负责管理设计验证的源代码及IP, Jekins 负责实现自动化的验证以节省重复劳动的时间。这样一套软件的组合就实现了整个项目的宏观管控。当然，由于各个公司的不同，使用的软件会有差异，但是基本的思路是差不多的，都涉及到资料文档管理、问题跟踪、源代码管控、自动化验证等内容。

2.2 Makefile & perl & python & shell & tcl

在前面的文章中提到了IC设计中会用到脚本语言，也简单的聊到其功能作用，但并没有集中而详细说明各类脚本在应用于IC设计流程中的哪一个部分，这里按照设计流程集中的介绍一下。

Shell脚本，是LINUX系统自带的与LINUX内核交互的脚本语言。在SOC设计中其主要应用于配置DC, VCS, FM等软件的使用环境，比如说配置当前使用的DC版本是2016版还是2018版，配置使用的license文件等。

Makefile, 是用于组织源代码编译的一个工具，在windows环境下并不常用，因为各类开发软件都已经给我们做好了源代码组织的工作。而在Linux环境下，Makefile是必须要知道的一个组织源代码编译的工具。在SOC设计中，子模块数量很多，需要使用的软件也非常多。在应用软件对模块进处理的时候会面对软件接口的不一致而导致的繁琐问题。项目管理人员为了便于设计验证人员能方便的使用各种软件，需要将不同的软件使用接口做成一组通用接口，通过改变几个输入字符就实现调用不同的软件。 一般而言，会使用Makefile将nlint spyglass vcs dc fm pt等软件的使用命令重新组织一下，成为一个标准的调用接口，譬如make module_name vcs/dc/fm 这样的接口。某些公司可能采用其他脚本实现这样的功能，原理也是一样的。组织源代码，统一软件的调用接口，这是makefile的最大作用。另外Makefile也用于固件开发中，管理所有的汇编和C语言源代码。

Python, 爬虫脚本可能大家都很熟悉，就是用Python写的。在SOC设计中，会用到很多的memory，为了提供一个统一的memory使用接口给设计人员使用，需要将底层的各种不同深度，宽度的memory做一个wrapper给包起来（比如，有些memory没有生成，但设计人员需要用，可以使用拼接的方式来暂时得到一个可用的memory以用于综合）。这样工作，可以交给Python来做，当然也可以用其他工具达到同样的效果。

Tcl, 前文已经介绍过了，主要用于给综合写SDC约束文件使用的，SDC文件的源码本身就是TCL脚本的扩展应用，所以能取代tcl在综合时的作用基本很难。

Perl, 综合的report有很多，为了快速处理这些report，提取其中相关的VIOLATION，路径什么的，需要使用Perl脚本来处理这些文本问题。文本处理是Perl脚本语言的强项，用起来会很方便。

每一种脚本都有自己擅长的地方，有时也可以互换，并不是说某一类脚本语言就只能干这样一类事情，比如，综合的report也可以用Python来做，memory的Wrapper也可以用Perl来实现。但不同的脚本做它擅长的事情才能起到事半功倍的效果。另外，脚本语言往往并不会单独使用，而是多脚本结合使用，让效率最大化。

三、模块类别

SOC设计中，说到到模块设计，就不得不给各种模块分一下种类。模块类别主要是有这么几类：自设计模块、IP核（硬核、软核）、Memory模块，总线模块（AHB、AXI）、总线桥、VIP（verify IP）、寄存器配置、Debug模块。

自设计模块、基本通用模块设计，是指从原理开始，从无到有的设计出所需要的模块。在这一部分模块里面有些模块是可以作为整个项目组间通用的模块，比如说sfifo, afifo, mux, arbiter, ecc, syn_cell(同步模块), clock_gated（时钟门控），reset(复位模块)等等，这些模块因为复用性高，所以可以称之为内建IP，以便于与从IP供应商买来的IP做区分。

IP核（硬核、软核），从IP供应商处买来的IP，主要分为硬核IP，软核IP。硬核IP基本没有可配置或修改的余地，在版图布局时可直接使用的IP, 比如说PVT sensor、 PLL等。软核IP是可以进行二次开发的IP，比如说CPU处理器，在SSD中，所用到的软IP还有PCIE、NVME，当然PCIE应该包含有硬核IP和软核IP两个部分。

总线模块、总线桥，SOC采用的总线结构基本上以AMBA为代表，当然也有采用其他总线,比如CoreConnect, Wishbone等等，在这部分主要会涉及到总线主机及从机的设计，当然主机与从机都不是独立而是和其他功能相结合，总线只是作为数据的通路而已。另外，在采用了多级总线的情况下，会涉及总线桥的设计。所谓总线桥（bridge），就是不同总线的数据传输转换，比如说从AXI转换到AHB。

VIP，verify IP, 也称为验证IP，是为了简化验证而设计的IP，以AXI、AHB总线主机从机为例，在设计AXI、AHB主机或从机的时候，需要有相应的从机或主机IP与之配合，才能完成RTL的设计与验证，如果没有，验证起来会相当的麻烦。VIP可以购买，也可以自己设计，并归类到内建IP里面去，具体情况看项目经理如何决定。有了VIP就可以简化了大部分验证人员的验证工作，提高了效率。

寄存器配置，子模块有许多不同的功能，有不同的运行模式，这些功能和工作模块都是由寄存器来控制的。通过配置这些寄存器来启用子模块的不同功能，一般而言，是通过CPU来对这些子模块中的寄存器进行配置，实现统一管理的。为了达到这样的目的，市面上就出现了各种对寄存器进行描述的工具。笔者用到的寄存器配置工具叫做System Register Description Language,简称RDL。使用RDL工具，可以生成分配了一定的地址空间(比如说从0x0000_0000到0x0001_0000)的register file，这些registefile有着统一的接口，可以轻松的实现对这些配置寄存器的统一控制。有关RDL的内容可以参考System Register Description Language。

Debug模块，SOC是一个集成系统，涉及到模块种类和数量非常多，复杂度非常高。高复杂度的系统很容易出现各种问题，为了方便对于复杂系统的调试，需要在SOC中加Debug相关的模块。SOC中的Debug模块，与其说是个模块，不如说是个Debug系统。因为它的信号线会分布在每一个子模块中。这样的Debug系统一般而言会按照时钟域进行划分，每一个时钟域配置一对trig_bus和prob_bus线，位宽自定。Trig_bus是触发条件，prob_bus是想要观察的信号线。子模块内部会有不同的时钟域，会有需要需要观察的信号，而对外输出的Debug线却是每一个时钟域一对，这显然是不够用的。那么就需要在多对Debug线做选择，也就是需要select信号线。这个select信号线实现起来是很简单的，就是利用上面提到的配置寄存器。在寄存器文件中声明几个select线，直接拿来使用即可，因为select线是声明在配置寄存器中，所以可以通过CPU对其进行配置，实现完全掌控。子模块留出的Debug线会不断汇合起来，最终达到顶层，由顶层的Debug模块对这些信号做统一的处理。以上就是SOC Debug模块的功能。

四、利用统一接口实现验证

SOC设计基本采用UVM验证方法学来验证各类模块。一个项目中，提供一套全面、稳定的验证环境是验证资深人员需要做的工作，只有他们才对项目中的验证环境有着充分的了解，普通验证人员可能还没有这方面的能力。这里的验证环境不是指单个模块的验证环境，而是在考虑项目的各个方面的需求之后搭建的一套基于脚本（makefile）的流程化验证环境框架。普通验证人员只需要写好某个模块的UVM相关的验证平台文件，然后利用脚本就可以运行搭建好的验证环境。另外，UVM验证中，在回归测试中，需要消耗大量的计算资源。这时候，还需要IT人员的支持专门开辟几个服务器做分布式的验证。

举一个利用搭建好的验证系统跑仿真的例子。在搭建好了模块的UVM验证环境之后，在终端运行make module_name/case_name  vcs -fsdb 就可以运行仿真。在命令行后面加入其他的选项还可以实现其他的效果，比如说-debug，可以直接调用VCS的debug仿真功能。有这样统一的仿真运行接口，可以统一其他验证人员的验证行为，出了问题也容易分析。

五、利用统一接口实现模块综合

与验证一样，综合也是利用makefile脚本，统一综合的使用接口，运行make module_name syn这样的命令即可实现综合过程。设计人员需要做的是写好SDC约束文件，综合出report，分析时序&面积是否符合要求，如果没有，可以通过修改逻辑，或者约束条件来重新综合。至于其他的工艺库文件设置，memory 文件设置，由资深综合人员来完成整个综合环境架构的搭建。

前面系列文章提到的验证、综合等内容都只是适合于规模一般的芯片设计流程。对于SOC这种超大规模的多人协作设计的芯片，统一性的要求非常重要，这样在共同开发的过程中才能节省时间，提高效率。对于个人而言，能够设计出这样一套统一了仿真、综合等功能的接口，算是个人能力极大的体现，而要达到这一步还需要很多的努力。