Prototyping of Large Scale SoC using Synopsys’ HAPS Solution

Abstract

The accomplishment of PKUnity-3(SK) SoC prototyping using Synopsys’ HAPS solution is introduced. Difficulties emerge in the process of prototyping using in-house FPGA platform of PKUnity-3(SK) while HAPS handles all the issues with its off-the-shelf, extendable, flexible and reliable features. HAPS brings efficiency and success to PKUnity-3(SK) SoC prototyping with its state-of-the-art techniques.

Key words: HAPS, SoC, prototyping

摘要

本文介绍了北大众志PKUnity-3(SK)系统芯片基于Synopsys HAPS解决方案的原型验证的成功案例。HAPS平台以其即时可用、可扩展、配置灵活以及高可靠性等特点克服了PKUnity-3(SK)项目In-house平台在原型验证工作中的问题，有力的促进了PKUnity-3(SK)系统芯片原型验证高效与成功的完成。

关键词：HAPS，SoC，原型验证

1. 引言

系统芯片(System-on-chip，SoC)庞大的设计规模和复杂度使其验证工作的完备性显得尤为重要，而FPGA原型验证以其真实的软硬件行为和测试环境成为系统芯片验证的重要环节。系统芯片同系列不同产品间在外围接口上存在较大区别，需要FPGA平台提供较好的可扩展性和灵活性。基于此，在北大众志PKUnity-3(SK)项目中，我们将FPGA原型验证工作从自制(In-house)FPGA验证平台转向Synopsys公司的HAPS(High-performance ASIC Prototyping System)平台，以提升验证效率。

2. PKUnity-3(SK) SoC简介

PKUnity-3(SK)是一款针对超便携个人计算机(Ultra Mobile Personal Computer，UMPC)与消费类电子产品应用领域的系统芯片。其在处理器和视频编解码等多方面具有自主知识产权。为提高软硬件架构的开放性和扩展能力，全部采用工业标准接口。PKUnity-3(SK) SoC以高集成度、高性能、低功耗为设计目标，为3C融合等新型应用领域提供了低成本、高可扩展能力的基础架构。

图2-1: PKUnity-3(SK)系统芯片架构

PKUnity-3(SK) SoC的主体架构如图2-1所示。其在单芯片上集成了传统计算机中的功能部件，包括CPU、多媒体和显示子系统、多层次存储控制子系统、外部总线控制部件和其它主流的输入输出控制器等。PKUnity-3(SK) SoC采用了北大众志UniCore系列中的UniCore-2 CPU，支持32位定点处理、64位浮点处理和2D/3D增强指令处理。多媒体和显示子系统UniGFX集成了传统显卡的基本功能并具有视频编解码硬件加速能力，以满足迅速增长的多媒体处理需求。在存储方面，PKUnity-3(SK) SoC集成了个人计算机中主流的存储控制设备，构成了芯片内部的多层次存储控制子系统。

此外，该芯片中还集成了PCI 2.2主控制器、100M/1000M以太网控制器、USB 2.0控制器、IDE SATA硬盘控制器、静态存储控制器、AC’97控制器、串口控制器和PS/2键盘鼠标控制器等南北桥芯片组中提供的功能部件，以提供日常应用所需的设备接口。

PKUnity-3(SK) SoC采用TSMC 0.13μm生产工艺，设计规模达到2700万晶体管，芯片尺寸为9.2mm×7.3mm。

3. 传统方案：基于In-house平台

PKUnity-3(SK)项目所使用的In-house FPGA平台由北大众志深圳基地的板卡团队设计，针对PKUnity-3(SK) SoC的需求量身定制。PKUnity-3(SK) SoC的原型验证工作首先在该平台上进行。

3.1 In-house FPGA平台介绍

图3-1: PKUnity-3(SK) In-house FPGA验证平台

PKUnity-3(SK) In-house FPGA板以两片Xilinx Virtex4 LX200芯片为核心，芯片间拥有60对差分信号和50根单端信号的固定互联。其中一块芯片与DDR2 DIMM插槽连接，另一块芯片与DDR DIMM插槽连接。板上I/O端口及相应物理层控制芯片满足PKUnity-3(SK) SoC所集成的众多I/O控制器的验证需要，包括VGA、PCI 2.2、USB 2.0、100M/1000M以太网、PS/2、SATA、Nand Flash、MMC/SD、AC’97、串口等，如图3-1所示。

3.2 FPGA验证流程

图3-2: PKUnity-3(SK) FPGA原型验证流程

FPGA原型验证流程如图 3 2所示。ASIC RTL代码在尽量不改动原设计逻辑的前提下针对FPGA特性进行必要的修改，通过仿真验证其正确性。而后制定综合约束，执行综合流程，并在静态时序分析(Static Timing Analysis，STA)与后仿真的辅助下修改约束并迭代综合过程，保证综合结果的时序正确。最后上板调试并完成验证。

3.2.1 针对FPGA的设计修改

在使用FPGA做原型验证之前，ASIC代码需要针对FPGA的特性作出相应修改，原因主要有以下三个方面：

1)某些部件不可综合；

2)某些可综合的部件面向FPGA综合后无法保证功能正确性；

3)为保证实现的高效性，需要使用FPGA专有资源。

而对应于这三点，表3-1概括出了PKUnity-3(SK)在设计上针对FPGA原型验证的修改方案。

表3-1: PKUnity-3(SK) FPGA原型验证修改方案

在SoC代码综合与上板验证之前，对代码修改的功能正确性首先需要得到验证，而FPGA仿真环境为此提供了一个方便有效的调试平台。我们的FPGA仿真环境基于Synopsys公司的VCS软件搭建而成，与ASIC RTL仿真环境基本相同，只是设计代码替换为面向FPGA验证的版本。在FPGA仿真环境上，针对各功能模块的汇编测试程序得以运行并测试通过，证明了SoC代码面向FPGA修改后其功能的正确性。

3.2.3 约束制定及综合

为保证综合工具综合得到的结果正确反映原设计的功能，必要的约束制定必不可少。包括时钟源的周期约束、路径长度约束、输入输出延迟约束、管脚位置约束等。

Synopsys公司的Synplify工具为实现RTL代码向门级网表的综合提供了强大而便捷的途径，而Xilinx公司的ISE软件则进一步完成网表的转换、映射、布局布线等功能，最终生成可编程bit文件，用其通过JTAG口对FPGA进行编程并调试。当然在布局布线完成后需要利用静态时序分析、后仿真等手段保证设计时序的正确性，若存在问题可修改综合约束甚至设计代码并迭代综合过程。

3.2.4 软硬件协同验证

PKUnity-3(SK) SoC的FPGA原型验证为全系统真实工作场景与载荷的软硬件协同验证。系统上电后通过JTAG接口将编译后的二进制软件代码或操作系统内核载入内存空间，CPU在BIOS完成系统配置后直接取指进行各功能模块或全系统的功能验证。

具体验证内容涉及每个功能模块的可验证功能点，在此不详述，仅列举几个验证场景。

如图3-3，左上为分辨率720×480@25fps的H.264视频解码，左下为分辨率352×288@30fps的MPEG-2视频解码，右上为USB摄像头实时视频监控，右下为Linux远程桌面。

软硬件协同的FPGA原型验证以其真实的硬件行为，接近实际的运行速度，真实的软件行为及负载量为PKUnity-3(SK)的功能正确性提供了关键而不可或缺的验证手段。

3.3 In-house FPGA平台验证难点

基于In-house FPGA平台的原型验证过程在有效检验PKUnity-3(SK)功能正确性的同时也暴露出一些问题，主要有五方面：

1.缺乏可扩展性

FPGA芯片容量有限，而In-house FPGA板的不可扩展性在设计规模较大的时候显得捉襟见肘。PKUnity-3(SK)项目采用最小集(在系统芯片上启动Linux内核所必要的部件)加各主要功能模块形成数个版本分别验证的策略。

2.缺乏灵活性与可复用性

PKUnity-3(SK) SoC早期使用DDR SDRAM控制器，而后期换成了DDR2 SDRAM控制器。由于板级内存模组插槽不可变更，在FPGA验证的时候，仍然有数个版本使用了DDR SDRAM控制器。

另外该FPGA平台仅可供PKUnity-3(SK)项目使用，下一项目由于I/O控制器的升级与替换，板级物理层芯片和I/O端口亦要随之更换，其验证所需FPGA板的设计开发工作必须重新进行。

3.FPGA板开发周期长

由于PKUnity-3(SK) SoC的I/O控制器较多，FPGA板制板前的管脚分配和I/O配套接口等需求的制定需要花费1-2周，而FPGA板从设计制造到质量检验完成的整个生产周期需要花费8-12周。FPGA板的开发周期过长导致原型验证工作无法及时进行，影响了项目进度。

4.可靠性有待验证

In-house FPGA板电气特性很难保证完全可靠，有些隐患会在验证过程中暴露出来并难以定位，如供电电路不稳定、I/O接口连通性缺陷、板级信号短路断路等。带来更大问题的是FPGA板制板错误，如线路连接错误等。为不影响验证进度，排除了重新制板的可能性，往往需要手动修改板级电路并改变验证方式。

5.维护成本高

FPGA板使用过程中的损耗需要专门的板级技术人员修理与维护，时间与人力成本消耗较大。并且高损耗的I/O接口部件若无法替换则会造成整块FPGA板的报废，增加了开销。

4. 升级方案：基于HAPS平台

为解决In-house FPGA平台对原型验证造成的困难，有力推进项目验证工作进度，PKUnity-3(SK)项目引入了经无数成功案例验证的拥有成熟先进技术的Synopsys HAPS平台作为SoC原型验证的升级方案。

4.1 HAPS平台介绍

HAPS(High-performance ASIC Prototyping System)是Synopsys公司推出的基于FPGA的ASIC原型验证平台。它提供了单芯片至多芯片的FPGA主板选择，如最新的HAPS-51T、HAPS-52、HAPS-54等，并且可根据待验证设计的规模将多块主板级联或堆叠，使得FPGA芯片容量不再成为原型验证的瓶颈。

HAPS提供了一系列HapsTrak标准接口的扩展子板以支持图像、DRAM、SATA、PCI-E、USB、以太网等功能或I/O接口，为IC原型验证对I/O接口与物理层硬件的需求提供了丰富的可选择性，便利的可配置性和灵活的可替换性。

HAPS自带板级故障检测模块，板上HapsTrak接口的短路、断路等故障可通过LED信号灯及检测子板直观的检测出来。对于扩展子板的功能正确性，Synopsys也提供了对应的自测程序和配套检测子板，保证HAPS平台在原型验证过程中的稳定可靠。

另外，HAPS平台即时可用，省去了FPGA板的设计开发周期，在验证需求变化时可直接更换主板或扩展子板来解决，为项目的原型验证工作顺利推进赢得了宝贵的时间。

图4-1: HAPS-51T主板

PKUnity-3(SK)项目原型验证所用HAPS平台由HAPS-51T主板(如图 4 1)以及DVI_1×1A子板、GEPHY_1×1子板和LCD1_1×1子板组成。HAPS-51T主板拥有单颗Xilinx Virtex5 LX330T芯片，板载5个HapsTrak II标准扩展接口以及3个支持RocketIO高速通道的HapsTrak MGB接口。DDR2 SDRAM内存模组插槽集成于板上，无需扩展子板即可支持DDR2 SDRAM。

DVI_1×1A子板用于DVI显示信号输出，GEPHY_1×1子板作为以太网物理层及接口，而LCD1_1×1子板被手动改造成额外的JTAG接口，供SoC加载软件(如汇编、操作系统内核等)调试所用。

4.2 HAPS与In-house FPGA平台对比

HAPS相对于In-house FPGA平台的优势主要表现在FPGA芯片的升级以及可扩展性、I/O支持灵活性、可维护性、可靠性的增强，使In-house平台验证中遭遇的困难得以解决。表4-1对比了PKUnity-3(SK)项目采用的以HAPS-51T为核心的HAPS平台与In-house FPGA平台的功能与特性。

表4-1: HAPS与In-house FPGA平台特性对比

4.3 HAPS平台验证流程

HAPS平台的FPGA验证流程与In-house平台类似，如图3-2，同样经过了代码修改、仿真验证、约束制定、Synplify与ISE综合、STA与后仿真等步骤，最后是上板调试并完成软硬件协同验证。

4.3.1 面向HAPS的设计修改

HAPS-51T板载DDR2 SDRAM模组插槽，对DDR2 SDRAM控制器的验证提供了便利，因此PKUnity-3(SK) FPGA验证代码中的DDR SDRAM控制器可替换为与ASIC版本相同的DDR2 SDRAM控制器。当然，控制器中DQS信号的延时单元等效替换工作依然是必要的，具体方式参见表3-1。

DDR2 SDRAM数据端口单双向转换的资源替换以及系统时钟产生与分频电路的修改方式同表3-1所列。

另外，在原PKUnity-3(SK)设计中有一挂载在32位AHB总线上的静态存储控制器，其控制板级Flash芯片的数据读取实现SoC系统的Firmware功能。而在HAPS平台上没有替代资源可用，因此在使用HAPS-51T的原型验证时将静态存储控制器以及板级的Flash芯片替换为在代码中内嵌Firmware软件指令的固化ROM模块，CPU向其发出读数据交易时可模拟原静态存储控制器的行为，按照地址反馈相应的Firmware指令，实现SoC系统上电的配置流程。

4.3.2 仿真验证

面向HAPS修改后的PKUnity-3(SK)代码在FPGA仿真环境上进行了一系列必要的汇编程序测试。由于设计中的内存控制器部分作了从DDR SDRAM到DDR2 SDRAM的升级，其修改与集成后的功能正确性是需要重点验证的，因此汇编测试主要针对DDR2 SDRAM读写正确性进行。其次，时钟的正确产生、总线的正确交易、CPU对在设计中固化的Firmware取指的正确性、CPU对内存中汇编指令取指并执行的正确性也需要一一验证。

4.3.3 约束制定及综合

约束制定及综合工作在仿真验证通过后进行。时序约束的制定与In-house平台相似，修改幅度不大。管脚约束的制定在HAPS平台上可使用Synopsys提供的HapsMap工具方便的完成，仅需要为其输入主板与子板型号、连接状况，设计顶层端口与主板或子板信号对应关系等信息即可生成含有管脚约束的ucf文件。

综合过程同样使用Synplify或Certify完成网表综合，ISE完成物理实现。Certify工具的优势在于其为大规模设计的分割并使用若干FPGA芯片联合完成验证的策略提供了强大的支持，满足利用HAPS-52、HAPS-54等多FPGA芯片平台进行原型验证的需求。

ISE布局布线完成后的STA重点检查了时序约束是否有效，设计中各关键路径是否满足设计运行的要求。而后仿真通过对网表的时序反标并仿真验证进一步确认了综合后的时序正确性。对时序要求较为严格的DDR2 SDRAM控制器部分，后仿真对DQS信号相对DQ的相位调整起着至关重要的作用。

表4-2对综合后的硬件资源占用情况与In-house平台的V4LX200芯片作了简单的对比。表中数据仅表示PKUnity-3(SK) SoC最小集(其规模只达到PKUnity-3(SK) SoC全集的一半左右)的资源占用率。可以看出Virtex4 LX200芯片资源对PKUnity-3(SK) SoC全集的原型验证来说是不够的，而Virtex5 LX330T芯片的容量加上HAPS的可扩展性则表现出更大的富余度。

表4-2: PKUnity-3(SK)系统芯片最小集FPGA资源占用率

4.3.4 软硬件协同验证

图4-2: PKUnity-3(SK)在HAPS平台上启动Linux内核

综合流程完成后即可进入板级调试阶段。平台配置需注意子板位置、扩展口电压设置及全局时钟连接方式与管脚分配设置相对应。

软硬件协同的调试与验证，是将汇编测试程序通过LCD1_1×1子板改造的JTAG接口加载到内存中，由CPU取指执行来完成的。SoC中的DDR2 SDRAM控制器对内存模组的读写正确性首先得到了验证；其次各I/O控制器与子板上物理层芯片及端口的协同工作状况也经调试后验证通过，包括以太网控制器自回环测试、图像显示模块显示器点亮与图形显示测试等。以上过程也同时验证了DCM时钟的正确产生、总线的正确交易及CPU对Firmware和内存取指执行的正确性。最后的真实软件负载测试使用了第3章中所提到的MPEG-2视频解码、H.264视频编解码、Linux操作系统内核启动、远程桌面登录等应用场景。图 4-2展示了PKUnity-3(SK) SoC在HAPS平台上成功启动Linux内核的画面。

以上验证过程中SoC运行频率为33MHz，图像显示模块运行频率25MHz，对应屏幕分辨率为640×480@60Hz。

4.4 HAPS平台使用经验

1. 即时可用的HAPS平台省去了FPGA板开发周期，使FPGA原型验证工作可与RTL仿真验证同时展开，为项目进度顺利推进赢得了宝贵的时间。

2. HAPS成熟且经过检验的技术保证了使用的可靠性，在出现问题时可将调试目标集中在设计本身而不必花费过多的精力检查FPGA板是否处于正常状态。

3. FPGA芯片使用最新的Virtex5 LX330T芯片加上HAPS的可扩展性使得FPGA芯片规模不再成为SoC原型验证的瓶颈。

4. HapsTrak通用接口以及子板的引入极大的提高了灵活性，设计中的IP更换导致I/O接口需求变化的情况仅更换子板即可完全解决。

5. FPGA板上I/O接口损坏的概率比FPGA芯片大得多。In-house FPGA板一旦某个关键接口损坏且无法修复，将导致整块板报废。HAPS平台的灵活性使得以上情况通过更换子卡即可应对，将损失减少到了最低。

6. HapsTrak扩展接口的通用与可配置的特点使得设计的管脚约束不受FPGA板硬连线的限制，拥有更大的自由度。在某个扩展口损坏时可将子板替换到另一扩展口，不会影响验证工作的进度。

7. HapsMap工具对管脚约束的制定提供了极大的方便。输入信息仅包括主板、子板型号及其连接信息，设计顶层端口与主板、子板信号对应关系。其避免了手动处理大量FPGA管脚编号的情况，在提高效率的同时也减少了错误发生的可能。

8. HAPS虽然提供了相当数量的全局时钟输入接口，但板载晶振数量显得不够，另外板上可用的GPIO、LED等调试所用资源也偏少。用于调试的扩展子板的增加可解决该问题。

5. 总结

本文介绍了北大众志PKUnity-3(SK)项目中FPGA原型验证工作的详细情况。In-house FPGA平台开发周期长、不可扩展及I/O不可替换等问题对验证工作造成了一定的局限，而HAPS平台的引入对以上问题提供了很好的解决方案。HAPS以其即时可用、可靠、灵活的特点确保了PKUnity-3(SK)系统芯片在HAPS平台上的验证顺利完成，为PKUnity-3(SK)的成功流片奠定了基础。

6. 参考文献：

[1] Synopsys Inc. HAPS Mother Board HAPS-51T datasheet, 2008.

[2] Synopsys Inc. HAPS Daughter Board GEPHY_1×1 datasheet, 2007.

[3] Synopsys Inc. HAPS Daughter Board DVI_1×1A datasheet, 2007.

[4] Synopsys Inc. HAPS Daughter Board LCD1_1×1 datasheet, 2006.

[5] CHENG Xu, LU Junlin, YI Jiangfang, LIU Shu, Architecture of PKUnity-3(SK) SoC for UMPC, Chinese Journal of Computers, No. 11, Vol. 31, 2008: 1877 – 1887.