浅谈芯片的bringup 一，浅谈芯片研发谈到芯片，中美贸易战的中兴事件引发了社会对芯片行业的大量关注，本文不做累述芯片行业现状、痛点，只给大家展现芯片行业纯技术的某一面。先以芯片研发流程开篇，下图为个人理解的芯片研发流程图。图1 芯片研发流程图任何产品都有面向群体，芯片也不例外，面向手机、相机等消费类电子产品，面向机器人、行业自动化等工控类设备，目前主流芯片偏向消费类电子。芯片的面向最终都是转换成规格和需求，需求方或领导层先提要求，架构工程师、项目经理、项目管理、各技术组组长坐在一起讨论拍板出我们芯片所需要的规格list和需求list，这是第一步。接着，项目管理、经理负责资源组和人员的调配。技术方面，架构师是重点，对需求和规格list进行细化到具体，搭建架构，架构的分析与建模，仿真出可行性，比如整个集成芯片划分为几个模块、CPU选型、主频、总线划分等。如果涉及到高层次算法，需要完成芯片中数字部分的高层次算法，为硬件提供一个正确的软件功能模型，通过大量的高层次仿真和调试，为RTL实现提供总体性的设计指导。芯片从功能上来看，是由各个IP综合集成出来的。国内多数集成芯片都是采购IP，自研IP多数为小IP，一般ARM、DSP、普罗米修斯等CPU类IP多为采购，当然也不乏大公司自研DSP、超级CPU等，DDR PHY、SD PHY等高速接口IP也多为采购，国内算法能力很强，目前ISP、GPU、CNN、CODEC等都有大公司在自研。集成和实现都是RTL阶段，CRG（Clock Reset Gate）就是在这个阶段设计的，另外系统、总线、安全等相关控制也是RTL集成和实现的重点。集成将所有IP集合，安排和分配好脉搏、功能信号。实现靠近实际，RTL实现之后就是软件人员所看到的寄存器手册。集成阶段非常重要的是时序，尤其是异步时序，所以需要验证。验证由根据平台划分为EDA验证、FPGA验证、ZEBU验证等。嵌入式接触比较多的是FPGA和ZEBU验证。EDA验证是模拟的环境上验证的，但其最接近最后的AISC，但仿真毕竟是仿真，离实际差异还是很大；FPGA只能做前端验证，它最真实，也是验证速度最快的，但其频率的限制、模拟器件无法模拟，导致很多功能并不能验证的很完整，CRG 、power control、pinmux根本无法验证，，各类高速接口的PHY无法真实测试，FPGA的CRG一般尽量按比例集成；ZEBU平台也是基于FPGA上集成的，但其可完全模拟出时序关系，不过也存在FPGA的其它通病，而且其验证速度比EDA更慢，跑一个复杂点的验证用例可能需要一天。各大仿真或验证平台各有优缺点，但实际的芯片并没有验证环境那么理想，有corner、生产工艺、功耗散热、DDR稳定性等各种因素，导致最后的芯片问题百出。需要注意，验证并不是固定顺序的，任何一个阶段都需要。前面陈述的都属于前端，国内后端不甚重视，总体上按顺序有数据整理提供、布图、布局、preCTS（setup优化）、CTS（clock tree setup）、postCTS（进一步优化）、布线、post布线、ECO（进入此过程再无法修改数据）、finish、signoff（检查和验证）、tapeout（设计数据传递给制造方）。最后就是流片生产，多数在台积电、台联电，嵌入式在此过程需要准备回片bring up的代码，重点在CRG、power、高速IP等仿真无法覆盖完整的代码。然后等芯片回来，芯片一旦回来，就是嵌入式的大头戏，回片bring up阶段，所有人都在关注着这最后一炮的成功与否，芯片就是一锤子买卖，题外话的说，芯片的回片现场非常类似robocon比赛现场。以下以常用的ARM cortex-A为主的SOC系列芯片bring up为例。本文纯手敲，如有出入，自行参考。二，整体bring up流程回片bring up工作非常关键，但芯片是否如意并不是嵌入式能决定的，虽然前期有负责FPGA、ZEBU验证起到验证作用，但芯片行业的核心不在嵌入式，我们只是检验大家成果的一面镜子。但换个方向思考，嵌入式是处于最底层的软件，对芯片负责，如果过了嵌入式把问题释放出去，那就会收到无数的投诉、黑评等。回片工作流程如图2。图2 芯片回片bring up流程回片工作基本上所有IP的冒烟都需要两个前提，coresight(debug/trace)和DDR。图2中还少了SOC的基本功能冒烟实现这个前提，比如CRG、power manager、安全等，由于其牵涉到每一模块，故不加入图中。DDR冒烟非常关键，通常三大巨头公司海力士、镁光和三星都需要测试，开始时有bypass training方案，高频方案等，与产品实际性能需求有关，后面为了稳定性还得进行不同corner芯片、高低温下的压力测试。DDR之后就可以并行工作了，此时需要根据芯片应用场景进行对应IP功能冒烟，图2提供了多种场景的bring up实现，最基础的kernel的启动、sensor-显示通路、图像识别和处理、编解码等。本文重心在系统的bring up介绍，不展开场景介绍。三，系统的bring up系统的启动流程是bootrom->bootloader->kernel->filesystem，具体可参考图3。图3 某芯片启动流程详解图1，bootrombootrom是系统之始，也就是第一份代码，例如BIOS就是windows的bootrom。大部分嵌入式开发者或者谷歌BSP（Board Support Package）一般最多深究到bootloader，忽略bootrom也是因为它是随着生产固化的，与芯片本身息息相关，硬件工程师关注比较多，软件不可更改，也没必要修改。但如果想对芯片真正了解，必须对bootrom的代码甚为了解。bootrom里面做了以下几个事：(1)主CPU boot，一般bootrom只启动单核，并配置处于次低频态；(2)切入slow或normal模式；(3)efuse相关位检测；(4)如果涉及到，调整芯片的安全相关属性；(5)如果涉及到，将必须的电压打开；(6)配置debug串口，提供开发者调试；(7)检测是否非默认引导方式，并引导，有flash/emmc、USB fastboot、ETH等引导；(8)根据所选方式引导，跳转到RAM起始地址。值得注意的是既然有多种引导方式，那就可以用以太网、USB甚至串口传输boot程序给芯片，让其运行自己想要的非主线分支程序，比如fastboot功能的实现、安全属性强行修改等。当然，芯片安全问题不用担心，efuse里会有加密信息，bootrom会去校验你的FW，俗称签名。2，bootloaderbootloader非常关键，是底层软件大展身手的地方。bootloader最终目的是启动内核，至于内核是linux、rtos或者其它OS都可以。bootloader也并不止uboot，还有little kernel、redboot、armboot等，甚至可以自己手写，个人接触比较多的是uboot和little kernel。uboot适应性高，对成熟芯片可以做到是快速上板，对新开发芯片能做到参考作用，但其内容繁琐，全新芯片开发难度比little kernel更大。此处以更为通用的uboot展开，讲述bootloader具体干了什么事情。Uboot，即universal-bootloader，分为两个阶段，SPL阶段和uboot第二阶段，划分两个阶段是因为片内RAM的价格高昂，且大小一般都只有几十上百K。uboot为了适应各种平台适应各种OS，越到后面版本越来越庞大，为此设计者将uboot一分为二，将初始化flash/emmc并把存储的程序搬运到片外RAM的小uboot称为SPL，将启动内核的大uboot放入片外RAM（一般是DDR，即SDRAM），采取图4流程启动OS。Uboot也支持单阶段启动或者直接flash启动，但都非常少用，个人曾强行简化uboot到100K，但把uboot很多模块给去除了，比如交互界面、哈希表，导致代码完全像重写，后面弃用不了了之。图4 uboot启动流程图4是常见的一种uboot流程，由于是两片内存空间，两个阶段都需要做系统的初始化工作，异常向量表、堆栈、BSS、data、heap、代码段，值得重视的是SPL在底层初始化阶段是无BSS、data、heap段的。SPL阶段的流程很简单：(1)ARM的boot，SP、exception设置，关闭MMU、Icache、Dcache；(2)初始化CRG，电压、频点和工作模式初始化；(3)初始化debug串口，初始化FLASH，初始化片外RAM；(4)如果有需要，release其它核或其他CPU，如DSP、cortex-M系列ARM等；(5)如果有安全需要，boot TrustZone OS；(6)Relocate堆栈、GB等到第二阶段uboot；(7)直接跳转到片外RAM执行第二阶段。第二阶段就是uboot真正起作用的阶段了，其主要流程见图5。uboot的核心在于boot起各类kernel，但它本身不止于此，它还有改写flash内容，对内存映射区域改写，修改启动环境参数等功能，实现都在图5的最后console界面里，俨然是一个小型的裸机交互系统。图5 第二阶段uboot流程这里只浅谈下核心部分，也就是起kernel功能。uboot启动的内核为uImage或者zImage，也可以是压缩包，内核格式一般是由两部分组成：真正的内核和内核头部组成，头部中包括内核中的一些信息，比如内核的种类，加载地址，入口地址。以linux为例：uboot在接收到启动命令后，要做的主要是，读取内核头部信息，移动内核到合适的加载地址，启动内核，执行do_bootm_linux。do_bootm_linux主要做的为，设置启动参数，在特定的地址，保存启动参数arg，传递设备树dtb，以及根文件系统rootfs信息，解压kernel并放置到指定片外RAM位置，跳到入口地址，启动内核。3，Kernel大部分嵌入式都是在kernel之上做着辛勤的工作，调用各种标准的写驱动接口，基于各种驱动做开发，标准的代码接口，比如linux的io control、debugfs、sysfs、用户态程序，再如rtos的任务创建挂起、信号量、邮箱等等。本节非常浅面的谈谈kernel的bring up过程。以linux为例，主要流程如图6。图6 linux启动流程首先，从bootloader接管控制权后，首先读入根目录下的内核文件，该过程对设备树进行了扫描注册。内核文件加载以后，就开始运行第一个程序linuxrc或init，它的作用是初始化系统环境，这个进程的PID为1，后面称之为init进程。这时候，许多程序需要开机启动，这些在Windows叫做“服务”（service），在Linux就叫做"守护进程"（daemon），init进程的一大任务，就是去运行这些开机启动的程序。但是，不同的场合需要启动不同的程序，linux允许为不同的场合，分配不同的开机启动程序，这就叫做“运行级别”（runlevel）。接着，每个运行级别的运行程序在/etc目录下面，都有一个对应的子目录rc*.d，选择后通过init.d链接启动。这时，开机启动程序加载完毕，然后要让用户登录，有三种登陆方式：命令行登录、ssh登录和图形界面登录，为了方便一般用ssh登录或者直接默认登录某user用户来方便开发者调试。至此，Linux的启动过程就算结束了。4，filesystem文件系统的格式极其多，每种格式都有独立的生成标准，最常用的格式，ext4、fat32，一个是linux常用，一个是windows常用，占了大片江山。所有格式文件系统说白了都是对操作系统用于在存储介质上组织文件的方法。存储设备不管是易失的RAM，还是不丢失的ROM，只要可以提供标准的initialization、read、write，都可以对某个区域或者整个区域进行格式化。比较常见的文件系统格式化设备有SD卡、硬盘、EMMC等ROM设备，一般不用于RAM中。rtos一般是等系统起来后通过进程去管理文件系统，不会用到RAM文件系统。但linux不同，在boot loader 配置了某些参数的情况下（这也是常规做法），它的启动不会一来就加载ROM的文件系统，这就涉及到一个中间系统，称为initrd、ramdisk或者initramfs，后面简称initrd。而最后我们敲shell命令的界面所在文件系统称作rootfs，也即根文件系统。以下浅要介绍linux启动所用的到文件系统。在linux内核启动前，boot loader 会将存储介质中的initrd文件加载到片外RAM，内核启动时会在访问真正的根文件系统前先访问该内存中的initrd 文件系统。内核启动被分成了两个阶段，第一阶段先执行initrd 文件系统中的某个初始化文件，完成加载驱动模块等任务，第二阶段才会执行真正的根文件系统（rootfs）中的init 进程。linux是基于unix的系统，unix的设计之初有一哲学核心思想，即“一切皆文件”，在linux上的体现就是rootfs。简单的说，rootfs是一个带有linux整套内核体系结构和硬件设备注册的文件系统，可以看到设备节点，用户进程，debug信息等。相信linux驱动工程师了如指掌。不管是rootfs还是initrd，其实都是一样的文件形式，可以做成同源。rootfs的生成比较有名的工具叫做busybox，busybox自带有许多设备操作和shell的库。在这介绍两个开源代码，一个叫做buildroot，一个叫做yocto，都是基于busybox工具上的rootfs生成项目，都具备可视化可裁剪定制界面，库自选，busybox还带有许多boot kernel相关开源代码，同样initrd也可通过它们获得。至此，芯片的系统bring up结束。接下来就是各模块的驱动开发，和各种业务场景的实现了。版权声明：本文来源网络，免费传达知识，版权归原作者所有。如涉及作品版权问题，请联系我进行删除。https://www.eet-china.com/mp/a350381.html

AMD/XILINX vivado 问题汇总 问题 一：1.WARNING: [Xicom 50-38] xicom: No CseXsdb register file specified for CseXsdb slave type: 0, cse driver version: 0. Slave initialization skipped.2.INFO: [Labtools 27-1434] Device xc7k410t (JTAG device index = 0) is programmed with a design that has no supported debug core(s) in it.3.WARNING: [Labtools 27-3123] The debug hub core was not detected at User Scan Chain 1 or 3. You must manually launch hw_server4.with -e "set xsdb-user-bscan <C_USER_SCAN_CHAIN scan_chain_number>" to detect the debug hub at User Scan Chain of 2 or 4.5.To determine the user scan chain setting, open the implemented design and use: get_property C_USER_SCAN_CHAIN [get_debug_cores dbg_hub].6.WARNING: [Labtools 27-1974] Mismatch between the design programmed into the device xc7k410t_0 and the probes file D:/Vivado/xc7k410t-2ffg900/ddr_slave_410t_20150527_1/ddr_slave_410t_20150527_1.runs/impl_1/debug_nets.ltx.7.The device design has 0 ILA core(s) and 0 VIO core(s). The probes file has 1 ILA core(s) and 0 VIO core(s).8.Resolution:9.1. Reprogram device with the correct programming file and associated probes file OR10.2. Goto device properties and associate the correct probes file with the programming file already programmed in the device.复制代码大概是说设计里没有ILA core，但是debug文件里有ILA core，而且debug probes窗口下什么也没有。但是，我综合后明明插入了debug core呀，而且在约束文件里也自动生成了相关信息，查看schematic，也添加了debug相关的两个元件，为毛program时就是看不到呢？不知道有没有人遇到过类似的情况，求指点，万分感谢！解决：1： VIO 和 ILA 的CLK 有问题。2： 我查的Xilinx的论坛，貌似也这么说，说是要用free running clock，但我也没弄明白什么样的叫free running clock。我用的就是那些寄存器本来的时钟，如果换个时钟的话，怎么能保证采样不会出问题呢？还是不太明白，能否详细指教？谢谢啦！       所谓的free running clock就是上电就跑的时钟，而不是依赖某些条件才有的。补充一点，FREE CLOCK的确是要求上电无条件运行的时钟。有一次我碰到一种情况。用MMCM或者PLL输出的时钟作为采样时钟，但是如果MMCM或者PLL这个输入并不是上电就来的话，而是等FPGA程序运行了之后时钟输入才来，那么下载程序之后还是在ILA调试界面看不到任何信号。把MMCM或者PLL的输入时钟改为晶振的时钟，那么就可以正常使用ILA了。这是我的个人感觉，没有经过大量验证，所以希望大家多多指教。补充一点，FREE CLOCK的确是要求上电无条件运行的时钟。        其实不用FREE CLOCK也没问题。比方用ZYNQ PS产生的CLK也可以。上电后做PS初始化，再把需要的寄存器设定一下，然后更新一下DEVICE，就可以找到ILA了。3 ： 这个问题我遇到过，其实第一种情况是你的时钟信号可能没加入成功（比如外部输出时钟信号没进来或者幅度太小，内部时钟可能没有lock）；第二种情况是，你输入到ila核的时钟频率不合适。其实，ila就是个采样你需要的查看的信号的始终，因此最好是直接用外部始终的mmcm生成大于你需要采集信号的最高频率来采样（具体多大频率，看你采样点数的需求和你信号的频率了）。4： 这个问题是时钟引起的。当bit file program完成之后，fpga/vivado会自动检测ila的clock是否存在，如果不存在(在本例中是pll/mmcm没有lock)，它就会report 这个warning。这个时候我们只要让时钟工作起来，refresh一下device，ila就会启动--ila的窗口就会出来了。5 ： 你试试直接用外部输入的时钟（可经过时钟buf）作为ila的clk，不要用其它模块产生的时钟。问题 二：我在vivado下进行调试，调用了ILA IP Core。如果ila采用晶振输入作为clk时（也即全局时钟），在顶层RTL级，可以看到ila的数据和时钟都连上了。Debug时也能在Hardware下看到XADC和ILA。但如果ila的clk，采用逻辑计数办法分频后的时钟信号、或者采用clock wizard倍频后的时钟信号。在顶层RTL下看ILA的clk并没有和上述时钟源连接上。此时将bit流下载后Debug，也只能看到XADC而看不到ILA核。  想知道使用ILA时，ila的clk的输入源是不是有什么特殊限制？解决：1 ： 难道是：（Xilinx PG172）The clk input port is the clock used by the ILA core to register the probe values. For best results, it should be the same clock signal that is synchronous to the design logic that is attached to the probe ports of the ILA core.    2 ： 首先确保你的分频结果是有效的。然后，如果你非要用分频结果的话，过一个bufg试试。// BUFG: 全局时钟缓存（Global Clock Buffer），只能以内部信号驱动  // Xilinx HDL库向导版本，ISE 9.1  BUFG BUFG_inst (  .O(O), //时钟缓存输出信号  .I(I) // /时钟缓存输入信号  );  // 结束BUFG_ins模块的例化过程 

国产EDA工具厂商汇总与世界三大巨头对比 从国内EDA市场来看，美国三大EDA厂商也占据了主导地位。根据赛迪智库数据显示，2020年Synopsys、Cadence和Seimens EDA三巨头合计占领国内约80%的市场份额，国产EDA厂商的份额仅11.5%，其中华大九天占据了国内EDA市场约6%的市场份额，居本土EDA企业首位。近年来，全球 EDA 市场呈现出稳步增长的态势。根据市场研究机构的数据，2020-2025 年期间，全球 EDA 市场规模持续攀升（见下图 ）。2020 年，全球 EDA 市场规模约为 115 亿美元，到 2025 年，预计将达到 157 亿美元，年均复合增长率为 6.4%。这一增长主要得益于 5G、AI、物联网等新兴技术的快速发展，以及全球范围内对高性能、低功耗芯片的需求不断增加。