CN102411535B

CN102411535B - 导航SoC芯片仿真、验证和调试平台

Info

Publication number: CN102411535B
Application number: CN201110219613.0A
Authority: CN
Inventors: 陈默扬; 应忍冬; 刘佩林
Original assignee: Shanghai Jiaotong University
Current assignee: MediaSoC Technologies Co., Ltd.
Priority date: 2011-08-02
Filing date: 2011-08-02
Publication date: 2014-04-16
Anticipated expiration: 2031-08-02
Also published as: CN102411535A

Abstract

本发明公开一种导航SoC芯片仿真、验证和调试平台，它包括集成了RISC处理器和FPGA的导航SoC验证板，以及协助设计人员调试和分析的PC主机环境。在FPGA上实现导航IP，并加入对挂起/运行模式的支持。根据硬件挂起/运行状态，导航中断程序分为硬件挂起和运行两个时期，在挂起时期PC主机通过UDP/USB协议完成中频数据向SoC验证板的导入，紧接着SoC验证板将调试信息传送回PC主机。本发明还利用SoC验证板上的定时器资源来精确分析代码在RISC处理器上的运行时间，可以对软硬件的实时性进行分析。PC主机端包含GUI界面、UDP/USB通信线程和后台数据库，为设计人员提供完善的验证环境。

Description

导航SoC芯片仿真、验证和调试平台

技术领域

本发明涉及SoC（System On Chi，片上***）验证调试领域，特别是一种能够用来进行导航SoC芯片仿真、验证和调试的装置平台。

背景技术

全球导航卫星定位***（GNSS）在过去几十年间在各个领域已经得到了广泛的应用。目前GNSS包括了美国的GPS、俄罗斯的GLONASS、中国的Compass（北斗）以及欧盟的Galileo***。在民用领域，大部分的移动设备都具备导航功能，为人们的出行提供了极大的方便。许多交通工具配备了GPS导航设备，大大简化了交通业的管理。在军事领域，导航***更是现代化战争的重中之重，而这些设备的核心就是导航芯片。在导航芯片设计领域，国内和国外的先进水平有一定的差距，Sirf、u-blox等芯片和相应的解决方案无论在功耗、成熟度、可靠性和成本都达到了极高的水平。

随着北斗二代卫星导航***的逐步完善，导航芯片的设计和研发又成为了学术界和业界的焦点，为了不受制于国外芯片供应商，我国急需发展出有自主知识产权的含有导航IP（Intellectual Property，知识产权模块）和RSIC处理器（Reduced Instruction Set Computer，精简指令集计算机）的SoC解决方案。

所谓的导航硬件加速单元，简称导航IP，指的是以网表提供的固核或者以HDL（Hardware Description Language，硬件描述语言）代码提供的软核。导航算法涉及到大量的数学运算和矩阵运算，完全采用硬件实现难度过大，难以进行修改，扩展性会受到限制，同时，导航算法还处在不断演进的过程中，硬件的灵活性无法满足要求。另一方面，纯软件实现虽然是学术界一直关注的热点，但以目前RISC的处理能力、功耗要求权衡来看，无法满足要求。因此，RISC处理器核配合硬件加速器（即导航IP）成为主流的方案，这样的导航芯片解决方案简称导航SoC（System-on-a-Chip，即片上***）。构建这样一个SoC***的一大难点就在于验证和调试部分，这也是耗时最长的一个部分，直接影响到上市时间。

导航SoC芯片的运行和验证具有如下特点：

1. 导航IP需要处理器的配合，在处理器上运行软件可以提高设计的灵活性。因此，我们所要仿真验证的对象是一个软硬件协同的***。不同的调试方案中，算法软件既可以运行在PC主机上，也可以运行在目标板的RISC处理器上，后者和实际芯片的行为更为相符。

2. 导航SoC芯片必须关注于实时性，导航算法对导航中频数据流进行处理，这些算法都是有实时性要求。如何给设计人员提供准确的实时性信息以及完备的调试信息成为导航SoC验证的基本问题。

3. 导航IP及SoC***的验证对仿真速度有很高的要求。导航中频数据的采样率范围4MHz~17MHz，导航IP运行在30MHz~100MHz，处理器处理1s的数据需要上千万个时钟周期，而导航算法往往要一分钟的数据才能解算出结果，如果要模拟一些特殊的场景，需要几十分钟的数据，完全采用HDL仿真器去仿真耗时将会非常的长。

4. 导航中频数据的存储量很大，以5.714MHz的采样率2bit精度为例，1分钟的数据就需要85.71MB的数据；如果需要对不同场景下的捕获、跟踪和解算等流程进行仿真，往往需要5分钟甚至更长时间，数据量将达到400多MB，因此高效的数据存储、导入和回放机制也是调试平台必须解决的问题。数据的导入还要保证时间上的准确性，错开一个采样点都会影响整个***运行的准确性。

5. 图1是典型的导航SoC程序运行流程，定时器每隔一段时间触发处理器一次中断，典型间隔为520us。而导航IP以采样的间隔时间输入中频数据，典型采样率为40/7MHz或者16.368MHz。中断函数返回后，根据标志位的结果，会定期地调用主函数。中断服务程序主要和硬件加速单元（导航IP）进行交互。如图所示的程序执行流程是导航芯片的主流工作模式。

图1是导航SoC软件运行的典型流程图，在导航算法及硬件加速模块***的仿真领域，目前主要有三种方案：

方案一，用硬件描述语言（HDL）描述整个***，包括处理器核和导航IP全部采用HDL描述，处理器核运行的是编译完成的二进制可执行代码；

方案二，采用指令集仿真器进行导航算法软件的仿真，而导航硬件加速单元通过HDL仿真器仿真，二者通过DPI机制（Direct Programming Interface，SystemVerilog与C/C++语言交互的机制）或者操作***进程间通信机制进行交互；

方案三，采用软硬件协同的方案，在目标板上的FPGA（现场可编程门阵列）实现导航IP，在X86主机上运行导航运算程序，PC主机和FPGA通过PCI接口进行通信；

方案一可以得到最精确的仿真结果，并且通过HDL仿真器进行调试，缺点是非常的慢，HDL仿真器得到的结果也不直观，仅能在很低层次的管脚信号级别进行调试。处理器核（可综合的）的逻辑非常复杂，以及导航IP本身的复杂性，往往需要几天时间才能仿真几秒钟的数据。同时，处理器核授权的费用很高，成本过高，一般公司和学校科研单位负担不起。

方案二加快了处理器部分的仿真速度，但整体速度仍然受限于导航硬件加速单元RTL的仿真性能。由于软件模块是通过指令集仿真器运行的，Cache（缓存）的行为以及总线的时序没有办法精确模拟，无法真实反映SoC芯片的行为，严重干扰设计人员对实时性的评估。

方案三不需要运行HDL仿真器，瓶颈转移到PC主机和FPGA的通信效率上。但应当认识到，软件代码运行在X86主机上所得到的结果往往和RISC处理器得到的运行结果不同，X86处理器和RISC处理器在架构上（比如指令集、Cache、内存管理单元MMU和浮点协处理器）差异很大，导致运行效率上和运行结果精度的不同，也无法对软件实时性进行评估。PCI接口协议非常复杂，往往需要专门的一台主机来运行整个***。

在中频数据的回放方案上，传统的方法有两种：

方法一：进行真正意义上的实时仿真，实现在FPGA上的导航IP直接和采样芯片的中频数据输出端口进行连接；

方法二：通过PCI-E接口或者USB接口来支持数据的回放，按照一定时序将中频数据导入到FPGA中；

方法一不支持数据的回放。可重现特性一直是SoC验证领域的基本要求。外界的场景往往处在不断地变化当中，问题的出现时间往往是随机的，这就给调试带来很大的困难。因此支持数据的回放是导航调试功能的前提，它使得设计人员可以反复对同一批数据和同一个问题进行全方位的剖析，从而找到***中的缺陷。排除天气、地点等外界因素带来的干扰，把数据的采集和SoC***的调试验证这两个步骤分开。

虽然方法二所用的协议比较复杂，并且都是用PC主机上的x86处理器来运行导航算法的软件部分，尽管能对硬件的实时性进行分析，却无法对软件的实时性进行精确定量的分析，而软件的实时性才是导航算法设计中的难点。

经过对现有技术文献的检索发现，申请号为“200610012061.5”，名称为“导航卫星信号处理***”，该专利提供一种导航卫星处理***，能够实时、连续、长时间的采集导航卫星信号，传送到计算机，并且通过USB等高速接口将采样数据回放。该平台仅仅关注于回放功能，并没有为调试提供解决方案。

检索中还发现，授权公告号为CN 100526910C，名称为“用于卫星导航接收机研发的平台***”，该专利中的平台***将导航接收机分为硬件部分和软件部分，软件部分运行于计算机上，硬件部分通过计算机接口通过计算机接口连接于所述计算机。由于软件运行于x86计算机上，软件实时性的分析就无法进行，因为x86处理器核嵌入式处理器存在着很大的差异。因此，该平台的运行和导航SoC真实芯片的运行情况存在很大差异的，很多嵌入式***独有的问题都无法暴露出来。

目前已有的方案都只是关注于导航算法本身的软硬件划分，仅仅用FPGA对硬件加速模块进行验证，不关注与RISC处理器和导航硬件单元之间交互的时序，没有为SoC和芯片设计提供调试和验证机制。这些已有的方案无法评估导航算法在真实RISC处理器的实时性，尤其是中断的实时性。众所周知，中断处理是影响***稳定性和运行效率很关键的因素。这些已有的方案所给出的软件代码在后期下载到RISC处理器时，会出现很难调试的漏洞，严重影响设计进度。

发明内容

针对现有技术中存在的技术问题，本发明提供一种高效率的、可对软硬件实时性定量分析的、信号体制无关的基于UDP/USB协议的导航SoC芯片仿真、验证和调试平台。

为实现上述的目的，本发明采用的技术方案如下：本发明是为导航芯片设计开发服务的，关注的是片上***的验证和调试。首先定制一块SoC***验证板，板上带有RISC处理器和FPGA，配备有以太网接口或USB接口。与已有的大多数PC/FPGA协同仿真机制不同的是，本平台中导航程序运行在RISC处理器上。为硬件加入挂起模式，在中断程序中的某个阶段将导航加速器硬件和中断定时器挂起。在硬件挂起阶段PC主机将中频数据通过UDP协议或者USB协议导入到FPGA中的FIFO（先入先出队列），并完成调试信息的收集，之后导航IP恢复运行。为了支持实时性的精确评估，所有这些网络通信代码、调试信息收集代码都放在Non-Cacheable（不可缓存）的区域，降低对原有***的干扰。主机建立完善的调试GUI程序和后台数据库，让设计人员可以利用这些调试信息对导航SoC芯片进行分析，进一步完善已有的算法架构和硬件设计。

本发明提供一种导航SoC芯片仿真、验证和调试平台，该平台具体包括PC主机和SoC***验证板，它们之间的通信通过UDP（用户数据包协议）或USB（通用串行总线）协议进行，所述PC主机通过UDP或者USB协议和握手机制完成中频数据向SoC***验证板的导入，SoC***验证板采集调试信息并返回给PC主机。

所述SoC***验证板上包括RISC处理器和FPGA芯片，其中FPGA与RISC处理器以总线方式或者短延时的接口进行通信。导航IP以RTL形式提供，综合实现在FPGA上。FPGA硬件上实现带有挂起模式的导航IP，RISC处理器上运行导航算法，在导航IP的辅助下完成定位解算功能。

所述RISC处理器通过内存管理单元MMU实现内存映射和Cache管理；RISC处理器所能控制的外设资源至少要有以太网控制器或者USB控制器，并与PC主机连接；导航所有C/C++程序都运行在RISC处理器上，主体上分为主程序和中断服务程序；中断服务程序负责与导航IP进行交互，典型中断间隔为520~800us；主程序利用中断服务程序返回的信息解算出坐标，这两条程序流互相配合完成卫星定位。

为了对实时性进行评估，RISC处理器应当能够访问到三个定时器资源，其中一个定时器完成固定时间的延时，另一个定时器完成中断触发，第三个定时器完成多个程序段运行时间的测量。这些定时器资源既可以分布在FPGA上，也可以处于RISC芯片内部。

所述RISC处理器能够对导航硬件加速单元进行访问和读写，FPGA中必须根据开发板的情况配置好管脚连接。最自然的形式是FPGA与RISC处理器通过片上总线（以ARM为例，就是AMBA总线）或者PCI-E总线进行连接。

所述导航硬件加速单元（简称导航IP）的RTL代码中必须加入对挂起模式的支持(以clk_enable时钟使能的方式实现)，外部处理器可以通过寄存器读写的方式改变导航IP的运行/挂起状态，使其暂停，然后继续执行。

所述RISC处理器上运行的中断函数分为硬件运行阶段和硬件挂起阶段。硬件挂起阶段PC主机通过以太网/USB接口向FPGA批量传入导航数据；FPGA上有相应的FIFO以存储这些数据；调试信息的收集和返回也是在此阶段完成。

所述PC端存储导航中频数据，PC主机与SoC验证板通过UDP或者USB协议进行握手和通信。PC主机应当带有网口或者USB接口。

所述PC主机分为四个线程，分别是GUI图形界面线程、调试***主控线程、数据库线程和UDP/USB通信线程。主控线程负责其它三个线程之间资源的分配、通信的冲裁。UDP/USB通信线程负责和SoC验证板进行通信。数据库线程对通信传输过来的调试信息进行分类存储，并支持用户对这些信息进行检索，数据库线程还负责中频数据数据源的调入。图形界面让设计人员可以以直观的方式查看调试信息和实时性信息、绘制波形以及控制接收机的运行。

本发明中，在中断服务程序的硬件挂起阶段，以可控的模式将导航中频数据传送到FPGA中的FIFO（先入先出队列）。FIFO被封装为处理器所在总线的外设，映射到内存中的一段区域，处理器以内存读写的方式向FIFO批量写入数据，在将来一段时期为硬件IP模块提供数据。

RISC/FPGA验证板检查中频数据FIFO的剩余，在每个中断函数中向PC端发起数据请求，PC端遵循握手机制将导航中频数据返回给SoC***验证板。RISC处理器端的调试信息收集程序将接收机状态、调试信息、解算结果以及实时性分析等相关信息通传送到PC端进一步分析。这些调试信息将以小包的形式填充整个以太网数据包，然后再PC主机端完成这些数据包的拆分和解析，随后填入后台的数据库，GUI界面将根据设计人员的操作，完成对数据库的检索，取出这些信息以波形或者表格的形式展现这些信息，进行时间精度为中断级别的调试。

这些UDP/USB通信的附加代码通过链接脚本和MMU（内存管理单元）的设定，放置于Non-Cacheable的区域，RISC处理器的Cache（高速缓冲存储器）将受到最小的干扰，这样就可以对原始的导航算法软件的实时性进行准确的估计。并且，通过时序逻辑使能的方式，使得FPGA上运行的导航IP支持挂起模式，在RISC处理器的控制下，在网络通信阶段（即运行附加代码的阶段）导航IP和定时器将处于挂起模式，此时导航算法本身的软硬件逻辑都没有运行，设计人员可以充分加入调试信息代码，调试信息可以充分的被收集，而不会受限于RISC处理器的性能，也不会影响到实时性的测量。

这些附加代码是在Non-Cacheable的形式让RISC处理器运行的，所以处理器的性能越高、总线通信带宽越高，整个平台的仿真性能就越高。该方案是协议无关的，兼容主流的USB2.0和UDP通信协议。

本发明的技术效果如下：

本发明的导航SoC芯片仿真、验证和调试平台，在X86主机和ARM RealView Emulation Board平台（RISC处理器选择了业界最通用的ARM处理器）相互配合下能够以1:7的速度比对导航接收机进行仿真，并完成调试信息的收集，设计人员可以以中断为基本单位控制整个接收机的运行。整个平台可以高效可靠地工作，远远超过HDL仿真器RTL仿真的速度，并且支持对嵌入式***实时性进行分析。设计人员可以通过GUI界面控制导航SoC验证板软硬件部分的运行，从数据库中检索调试信息和实时性信息，调试信息和实时性数据更好地分析整体***的瓶颈，完善导航SoC芯片架构，调整算法和优化代码，为后期芯片实现做好充足的准备。

附图说明

图1是导航SoC软件运行的典型流程图；

图2是导航SoC芯片的***结构图；

图3是本发明实施例中加入中频数据回放机制的导航SoC验证板的典型配置图；

图4是本发明在图3的基础上加入硬件挂起模式的SoC***验证板的结构框图；

图5是本发明实施例中添加中频数据回放和调试信息传输的中断函数处理流程图；

图6是本发明实施例中链接脚本所对应的MMU配置和内存映射框图；

图7是本发明实施例中PC主机程序总体框架和导航SoC***验证板的信息通路示意图。

具体实施方式

以下对本发明的技术方案作进一步的说明，以下的说明仅为理解本发明技术方案之用，不用于限定本发明的范围，本发明的保护范围以权利要求书为准。

下面结合附图对本发明的导航SoC芯片仿真、验证和调试平台进一步详细描述，以下描述均以ARM处理器和AHB总线为例，如果是其它RISC处理器或其它总线形式，请适当修改。

步骤一，定制导航SoC芯片验证板。如图2是导航SoC芯片的***结构图，它直接从射频前端得到中频数据，这些数据进入硬件加速IP进行处理，RISC处理器或者DSP在硬件加速器的协助下完成坐标的定位，本实施例中不需要射频前端的支持。所定制的SoC验证板上带有ARM处理器和FPGA，跟主机通过UDP或者USB协议进行通信。

步骤二，加入数据回放的支持。如途3所示，是本发明实施例中加入中频数据回放机制的导航SoC验证板的典型配置图。FPGA中例化FIFO模块，由于我们不会同时对FIFO进行读写操作，所以同步型或异步型的FIFO均满足要求。FIFO对应于总线的两个地址，分别是：

l 地址0 数据写入寄存器，以目前主流的32bit数据宽度写入；

l 地址1 FIFO有效单元寄存器，返回当前FIFO中剩余字的数量，导航中断程序需要该寄存器来获得FIFO的信息，以确定下一次向PC端应该请求多少数据；

FIFO模块和导航IP核都在FPGA中实现，ARM通过总线对其可以进行控制。

步骤三，为导航IP加入硬件挂起模式的支持。导航IP以RTL的形式提供，根据处理器与FPGA连接形式的不同，该导航IP外层将具备不同的总线接口。以ARM RealView Emulation Board为例，ARM处理器对外为AHB接口，因此该导航相关器IP必须搭载AHB接口。假如是以其它方式连接的，导航IP必须搭载不同的接口逻辑。例如，如果是or1200微处理器，则可搭配wishbone接口。

图4是本发明在图3的基础上加入硬件挂起模式的SoC***验证板的结构框图。给RTL（寄存器传输级）代码加入对挂起模式的支持方法说明如下，一般来说硬件IP核的代码都是基于全同步的风格描述，以Verilog为例，每个module一般包含如下风格的描述的同步时序逻辑语句（见左栏）：

修改后的代码如右栏所示，在顶层预编译文件加入`define SUSPEND_SUPPORT，并且在所有包含同步时序逻辑的模块端口中加入pd_n端口（见图3）。只要是全同步描述的可综合的硬件模块都可以按照这样的方式被改造成支持挂起模式的模块。

对应于挂起模式和运行模式，需要添加两个寄存器，处理器对这两个寄存器的写入就可以切换硬件IP的工作模式。这两个寄存器控制IP核的pd_n端口，对寄存器suspend_reg写入，pd_n置为低电平，使得导航IP进入挂起模式；对寄存器wakeup_reg写入，pd_n置为高电平，导航IP继续运行。

步骤四，为验证本配置定时器资源。板上需要有三个定时器资源A、B、C，这三个资源都要能被ARM处理器利用，叙述如下：

l 定时器A: 支持固定时间的延时，比如delayus()和delayms()的函数分布完成微妙级和毫秒级的延时；

l 定时器B: 支持实时性的测量，以下是程序运行时间间隔测量代码例子，用以对一段代码的运行时间进行测量（定时器向下计数）：

t_start = timerB_cnt(); // 起始

codeA to_measure…

codeA_duration = timerB_cnt() – t_start; // 结束

codeA_duration就是codeA代码所运行的时间，其精度与定时器B的最小分辨率有关，典型值为1us。

l 定时器C：中断信号定时器，如图1的软件运行流程中，需要中断信号来触发处理器进入中断服务例程；

步骤五，RISC处理器上软件流程的规划，特别注重实时性评估的支持。ARM处理器上的程序分为导航算法软件和网络通信软件两个部分。其中导航算法软件中包含中断处理函数，我们的网络通信软件就运行在中断处理函数的硬件挂起阶段。如图5是本发明实施例中添加中频数据回放和调试信息传输的中断函数处理流程图。网络通信软件完成中频数据的回放和调试信息的统计，这些代码相对于导航算法软件而言属于附加代码。如果不特殊处理，这些代码会干扰Cache的内容，在最差情况下，处理器Cache会随着附加代码的运行而完全替换成附加代码的内容。下一次重新执行导航算法软件的时候，处理器不得不重新从外部RAM中读入代码和数据，这和芯片实际运行的情况不符合，会干扰实时性的评估。

为了对实时性进行正确评估，排除附加代码所引入Cache的不确定性。在本套方案中，需要借助于MMU页管理机制来配置不同内存区域的Cache支持。根据***板互连方式的不同，MMU也有多种配置模式。但基本思路如下（在链接文件体现）：

l 内存空间在MMU中划分为可Cache和不可Cache两个区域；

l 附加代码的堆栈空间用得越少越好，或者堆栈也指向不可Cache的区域；

l 附加代码映射到Non-Cacheable区域，对应于图5，即networkProcess.cpp和dataCollect.cpp编译单元放置到Non-Cacheable的区域。

其工作流程如图5，下面给予说明：

定时器每隔一段时间触发一次导航中断服务程序，中断服务程序第一步就是暂停相关器和中断定时器。需要注意的是此时延迟定时器和实时性测量定时器依然在运行，即延时函数Delayus()和代码运行时间测量的机制依然被支持。本实施例中，可以在中断函数以及主程序的各个部分***时间间隔测量代码。

步骤六，调试信息收集的支持，不干扰对原导航SoC芯片***实时性的评估。增加统一的调试信息数据池，集中在同一个编译单元dataCollect。它通过extern的方式引用其它单元的数据，不需要修改其它编译单元的代码，收集到的数据将传递给主机。

为了更好的在链接脚本中对内存空间进行划分，使得整个平台方案具有通用性。RISC这一端的编程应该做如下约定。如图5：networdProcess处理网络通信（仅在SoC验证板的中断服务发生）的内容包含有：

l 导航SoC验证板向PC请求数据；

l PC向导航SoC芯片板传送导航中频数据，以支持数据回放；

l 导航SoC验证板向PC机发送调试信息；

调试信息内容的收集在dataCollect.cpp模块中进行，在数据池中填充好内容之后，networkProcess.cpp模块会把数据池中的内容进一步处理发送给主机。图6是本发明实施例中链接脚本所对应的MMU配置和内存映射框图，其中networkProcess.cpp模块以及dataCollect.cpp模块的内容都是放在Non-Cahceable的内存区域，而导航算法中断函数（网络通信部分除外）和算法主程序都是Cacheable。

通过MMU单元管理内存页面的Cache开关。UDP/USB通信附加代码对原始***的干扰降到最低，不会去占用Cache空间，整个***的运行将非常接近于实际芯片内部SoC***的运行情况。

步骤六，PC主机建立完善的调试环境，与导航SoC芯片验证板配合。图7是本发明实施例中PC主机程序总体框架和导航SoC***验证板的信息通路示意图。、仿真验证调试平台必须提供丰富的信息供设计人员查看，因此GUI界面必不可少。PC端调试平台分为四个线程：

线程一：UDP/USB线程，负责向SoC***板传送导航中频数据及接收调试信息；

线程二：数据库线程，将导航SoC芯片验证板传送过来的调试信息存储在数据库内，以方便调试人员对数据进行检索操作和存取操作；

线程三：图形界面线程，设计人员可以观看到卫星的分布、接收机的状态以及实时性信息，调试人员可以有选择的查看、筛选信息并绘制出波形；

线程四：调试***主控线程，用来分配其它三个线程资源的分配，以及它们之间通信的仲裁；

至此，导航SoC芯片仿真、验证和调试平台搭建完成。

整个平台是为导航接收机芯片的设计服务的，无论是算法的验证还是硬件的调试，设计人员都可以从中得到丰富的信息以修正改善原有的设计。本平台的一大亮点在于加入了对实时性的调试，从定时器的配置到MMU的设置，以及链接脚本的编写，都是为准确得到实时性而努力的，力求减少调试***本身对原有***（即导航SoC本身）的干扰，可以真实反映出导航芯片中SoC***的运行结果和实时性信息，为下一步后仿真乃至流片验证做好准备。

利用本发明平台能够将存储在PC主机上的导航中频数据通过以太网或者USB接口有序地输入到导航IP中，而调试人员可以以中断为最小单位以single-step（单步执行）或者free-running（自由运行）的方式控制整个***的运行，并且可以从该***的反馈结果中得到关于软硬件实时性、导航接收机各个通道的状态和导航解算各个方面的信息，所有这些信息通过UDP或者USB协议从SoC小***验证板传送到PC机上，随后存储在后台数据库，以便设计人员通过GUI界面（图形用户界面）从数据库中检索、读取、显示这些信息。导航算法软件运行在RISC处理器上，导航IP实现在FPGA上，整个平台运行结果尽可能接近于实际导航芯片中SoC***的运行结果。同时，通过一种机制让导航硬件加速IP支持挂起/执行机制，该调试平台所添加的附加代码对原***的Cache、中断实时性均无影响，在这些措施下，可以更加准确地评估软硬件的实时性。

综上，本发明平台的硬件模型兼容由ARM、MIPS等主流的RISC处理器和Xilinx、Altera等FPGA构建的SoC***验证板，与PC的通信基于UDP协议或者USB协议，设计和调试人员可以通过PC主机对导航SoC***的运行进行中断级别的控制和调试信息的收集，精确评估软硬件的实时性，兼容多种导航***，包括GPS、伽利略、北斗和GLONASS***，是导航芯片设计验证领域强有力的工具。

以上所述仅为本发明的较佳实施例而已，并非对本发明的技术范围做任何限制，凡在本发明的精神和原则之内做的任何修改，等同替换和改进等，均应包含在本发明的保护范围之内。

Claims

1.一种导航SoC芯片仿真、验证和调试平台，其特征在于包括：PC主机和SoC***验证板，它们之间的通信通过UDP或USB协议进行；所述PC主机通过UDP或者USB协议和握手机制完成中频数据向SoC***验证板的导入，SoC***验证板采集调试信息并返回给PC主机；其中：

所述SoC***验证板上包括RISC处理器和FPGA芯片，所述FPGA芯片与RISC处理器以总线方式或者短延时的接口进行通信，导航IP以RTL形式提供，综合实现在FPGA上；FPGA硬件上实现带有挂起模式的导航IP，RISC处理器上运行导航算法，在导航IP的辅助下完成定位解算功能；

所述RISC处理器通过MMU内存管理单元实现内存映射和Cache管理；所述RISC处理器所能控制的外设资源至少要有以太网控制器或者USB控制器，并与PC主机连接；导航所有C/C++程序都运行在RISC处理器上，主体上分为主程序和中断服务程序；中断服务程序负责与导航IP进行交互，主程序利用中断服务程序返回的信息解算出坐标，这两条程序流互相配合完成卫星定位。

2.根据权利要求1所述的导航SoC芯片仿真、验证和调试平台，其特征在于：所述RISC处理器支持中断机制，并且有三个以上的定时器资源，其中一个定时器完成固定时间的延时，另一个定时器完成中断出发，第三个定时器完成多个程序段运行时间的测量，这些定时器资源分布在FPGA上，或处于RISC芯片内部。

3.根据权利要求1所述的导航SoC芯片仿真、验证和调试平台，其特征在于：所述RISC处理器能够对导航硬件加速单元进行访问和读写，FPGA与RISC处理器通过片外总线或者PCI-E总线进行连接。

4.根据权利要求1所述的导航SoC芯片仿真、验证和调试平台，其特征在于：所述PC主机存放导航中频数据，PC主机与SoC验证***通过UDP或者USB协议进行握手和通信，PC主机带有网口或者USB接口。

5.根据权利要求1所述的导航SoC芯片仿真、验证和调试平台，其特征在于：所述导航IP的RTL代码中加入对挂起模式的支持，以clk_enable时钟使能的方式实现，外部处理器能通过寄存器读写的方式改变导航IP的运行/挂起状态，使其暂停，然后继续执行。

6.根据权利要求1所述的导航SoC芯片仿真、验证和调试平台，其特征在于：所述RISC处理器上运行的中断服务程序分为硬件运行阶段和硬件挂起阶段，硬件挂起阶段PC主机通过以太网/USB接口向FPGA批量传入导航数据；FPGA上有相应的FIFO以存储这些数据；调试信息的收集和返回也是在此阶段完成。

7.根据权利要求6所述的导航SoC芯片仿真、验证和调试平台，其特征在于：在中断服务程序的硬件挂起阶段，以可控的模式将导航中频数据传送到FPGA中的FIFO，FIFO被封装为处理器所在总线的外设，映射到内存中的一段区域，处理器以内存读写的方式向FIFO批量写入数据，为硬件IP模块提供数据；***检查中频数据FIFO的剩余，在每个中断函数中向PC端发起数据请求，PC端遵循握手机制将导航中频数据返回给SoC***验证板；RISC处理器端的调试信息收集程序将接收机状态、调试信息、解算结果以及实时性分析信息传送到PC端进一步分析，这些信息将以小包的形式填充整个以太网数据包，然后PC主机端再完成这些数据包的拆分和解析，随后填入后台的数据库，GUI界面根据设计人员的操作完成对数据库的检索，取出这些信息以波形或表格的形式展现这些信息，进行时间精度为中断级别的调试，这些UDP/USB通信的附加代码通过链接脚本和内存管理单元MMU的设定，放置于Non-Cacheable的区域。

8.根据权利要求1所述的导航SoC芯片仿真、验证和调试平台，其特征在于：所述RISC处理器通过定时器对软硬件的运行实时性定量化，精确测量软件代码的运行时间，该平台所引入的调试信息采集和中频数据回放附加代码，通过内存映射和Cache管理机制，对导航原程序基本无干扰，实时性分析结果准确。

9.根据权利要求1所述的导航SoC芯片仿真、验证和调试平台，其特征在于：所述PC主机分为四个线程，分别是GUI图形界面线程、调试***主控线程、数据库线程和UDP/USB通信线程，其中：主控线程负责其它三个线程之间资源的分配、通信的仲裁；UDP/USB通信线程负责和SoC验证板进行通信；数据库线程对通信传输过来的调试信息进行分类存储，并支持用户对这些信息进行检索，数据库线程还负责中频数据数据源的调入；图形界面让设计人员以直观的方式查看调试信息和实时性信息、绘制波形以及控制接收机的运行。