CN101504690B - 用于通信系统集成电路设计的实时仿真验证系统及其方法 - Google Patents
用于通信系统集成电路设计的实时仿真验证系统及其方法 Download PDFInfo
- Publication number
- CN101504690B CN101504690B CN2009100808690A CN200910080869A CN101504690B CN 101504690 B CN101504690 B CN 101504690B CN 2009100808690 A CN2009100808690 A CN 2009100808690A CN 200910080869 A CN200910080869 A CN 200910080869A CN 101504690 B CN101504690 B CN 101504690B
- Authority
- CN
- China
- Prior art keywords
- module
- response
- test
- command
- signal frame
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Test And Diagnosis Of Digital Computers (AREA)
Abstract
本发明提供了用于通信系统集成电路设计的实时仿真验证系统和方法,用于通信系统的集成电路设计的验证,该系统和方法可用于通信系统集成电路设计中的前端和后端实时验证。该发明所提供的系统和方法包括测试模块通过调用相关任务,产生被测系统所需帧格式的激励数据并收集被测系统产生的响应,并在验证模块中比较响应值与参考值,得到验证结论,两模块通过文本方式进行通信。该系统与方法针对有固定帧格式的通信系统,可根据需要移植在不同的系统验证中;同时,该系统改变了验证的基本步骤的执行顺序,并可实时操作,减少了仿真验证所需的时间。该系统既可应用标准串口的简单系统,也可应用于导航接收机的大规模复杂通信系统的仿真验证。
Description
技术领域
本发明属于集成电路设计领域,涉及数字集成电路领域,具体来说,涉及一种用于通信系统集成电路设计的实时仿真验证系统及其方法。
背景技术
通信与信息处理系统,通常是对固定帧结构数据进行处理工作。在验证工作中,信道和信源的不确定性难以利用硬件描述语言进行建模;同时由于仿真器对大量信号处理算法的仿真通常会浪费大量的计算资源,速度也不容乐观。因此在大多数情况下需要实际的现场验证才能保证系统的正确性,于是通信系统集成电路芯片的验证来说,多数用现场可编程逻辑门阵列(Field-ProgrammableGate Array,简称为FPGA)代替芯片仿真验证,进行现场功能测试。
然而,利用FPGA进行的验证存在以下两方面的问题:一方面,专用集成电路(Application Specific Integrated Circuit,简称为ASIC)技术正在向片上系统(system on chip,简称为SOC)和嵌入式方向发展,设计者并不能设计所有的内核和模块,而是从第三方购买已经技术成熟的内核,如果这些内核仅仅为硬核,即只包含最终的GDS2和行为级仿真模型,而非提供可以进行FPGA验证的软核,则FPGA验证工作无法进行,人为地将FPGA中的内核替换为ASIC设计中的某个模块,则由替换带来的失败风险将是十分巨大的;其中GDS2电路版图的一种文件格式是。另一方面,ASIC技术的设计周期已经从几年前的以年为单位,发展到现在以月为单位的高速发展期。众所周知,芯片验证工作在芯片设计当中占到70%左右的工作量,那么如果能找到一种方法代替FPGA验证,又可以实现FPGA的实时验证的仿真验证方法,则可大大缩短ASIC设计的周期。
对于目前的ASIC仿真验证,存在以下几种形式:
1)硬件语言(Hardware Description Language,简称为HDL)仿真测试。仅利用HDL仿真语言,在测试平台中产生大量的测试向量,对输出数据进行处理,然后与预存的测试结果相比较,分析错误。优点是,在封闭的运行环境中进行仿真,速度较快。缺点是,第一,不能实时设置断点,每次改变输入向量,需要重新编译;测试向量的产生受到限制,如果产生只是随机向量,则测试向量空间往往过大,仿真时间过长,如果用于特定向量又往往会影响测试的覆盖率;同时,对于复杂的测试结果的判断仅仅依靠HDL语言不能完成,需要辅助其他计算机语言来完成。
2)VMM测试仿真系统。验证方法学(Verification Methodology Manual,简称为VMM)是Synopsys公司提出的基于Systemverilog语言的验证平台,该平台提供各种类,场景和函数,可以对输入向量进行约束,对输出向量进行自动分析比对,同时给出统计结果。该仿真验证系统解决了HDL仿真测试中输入测试向量空间过大的问题和输出测试结果的分析,但是实时性仍显不足,同时需要验证工程师掌握大量的系统函数及一个相对复杂的测试建模过程,而该系统对于设计人员来说,无疑增加大量的工作量如何使用该VMM系统上。
基于以上分析,两种方法均适用于大量测试向量的验证工作,VMM又可以提供约束环境来减少随即向量的产生。但是两种方法在验证过程是一致的,均如图1所示:验证过程包含以下步骤:
Step1:编写被测设计;
Step2:编写测试向量,测试平台;
Step3:利用仿真工具进行编译;
Step4:仿真并验证;
Step5:判断响应是否正确,如果响应正确,则结束验证过程;
Step6:如果Step5判断不正确,如判断由设计本身造成的问题,则返回Step1;
Step7:如果Step5判断不正确,如由测试平台或测试向量造成的问题,由于测试向量的编写大多数情况下在测试平台中,则必须返回Step2。
其中,当响应不正确的时候,无论是被测设计本身、测试平台或者是测试向量出现问题需要从Step1或Step2重新执行,而Step1和Step2为并行执行。造成时间和资源上的重复和浪费。同时,在上述方法中,测试向量必须与测试平台一同进行编译和仿真,而不能根据设计人员的需要实时的向仿真进程中添加测试向量,缺乏实时性。
Perl和Tcl等脚本语言代表一种与c或JavaTM为代表的系统程序设计语言完全不同的编程形式。脚本语言为″胶着″应用程序而设计,它使用无类型方法来实现高级编程和比系统程序设计语言更快的发展应用。与系统程序设计语言相比,不同的脚本语言为不同的工作而设计,这导致了语言间的根本不同。系统程序设计语言起源于像内存字等最初期的计算机元素,它为建立数据结构和算法而创建。相反的,脚本语言为胶着而设计:他们假设已经存在一套强大的组件,而它主要是把组件连在一起。系统程序设计语言使用强类型定义来帮助处理复杂事务,而脚本语言使用无类型定义来简化组件间的联系,并提供快速应用开发。
脚本语言和系统程序设计语言互为补充,并且二十世纪六十年代以来的大多数主要的计算机平台都同时提供这两种类型的语言。这些语言在组件框架中有着典型的应用:组件由系统程序设计语言创建,并由脚本语言组合在一起。然而,速度更快的机器,更好的脚本语言,图形用户界面和组件构造重要性的不断提高,因特网的发展等发展趋势大大提高了脚本语言的应用。在今后的十年中,这种趋势将继续,而且越来越多的完全使用脚本语言和系统程序设计语言书写的应用程序将主要用来创建组件。
发明内容
基于现有技术的上述缺陷,本文提出一种适合于通信系统集成电路设计的实时仿真验证系统及方法,该系统及方法既可应用标准串口的简单系统,也可应用于导航接收机的大规模复杂通信系统的仿真验证。
本发明所提供的系统主要利用tcl语言的灵活性,建立基于linux系统的tsh编辑器,在tsh中调用verilog仿真编译器,C语言编辑器,以及perl语言编辑器,将所有编辑器集成于tcl搭建的系统内,并由利用tcl语言建立一个内嵌于tsh的操作界面,供设计人员使用。其中,tcl与perl语言均为一种计算机脚本语言,tsh为linux系统中提供的tcl语言编译器。
本发明针对激励和响应均为固定帧格式的通信系统的仿真验证。例如,本发明既可应用于标准串口及串行外设接口(Serial Peripheral interface,简称为SPI)主从设备的简单系统仿真,也可应用于数字电视调制器、导航接收机等大规模的通信系统的仿真验证。
按照本发明的一个方面,提供了用于通信系统集成电路设计的实时仿真验证系统。该系统包括:测试模块和验证模块,测试模块用于通过调用相关任务,产生被测设计(Design Under Test,简称为DUT)所需的特定帧格式的激励数据以及收集DUT产生的响应,验证模块用于产生测试向量和参考响应值,并与DUT的响应值进行比较,得到验证结果。
所述的测试模块,在仿真器中运行,包含测试模块中的命令处理模块,由各种任务组成,当测试模块收到来自验证平台的指令后,调用所指定的任务块,这些任务包含两个方面,一方面生成输入激励,或强制改变被测系统中寄存器的值,另一方面是收集被测系统的响应,或者查询被测系统中寄存器的值反馈给验证平台进行处理;还包含测试模块中的通信接口模块,完成测试模块与验证模块之间的通信;
所述的验证模块,在linux tcl编译器中运行,包含有验证系统中的通信接口,完成与测试模块的通信,及验证系统中的命令处理模块,生成由设计人员要求的输入转化为编码信号格式,传输给通信接口,并将由通信接口接收到的数据解码为有效数据,还包括断言判决模块,将响应数据与参考值比较,得到验证结果,和报告生成模块,用于生成由测试存档文件,以及人机交互界面和C语言接口;
在所述的验证模块与测试模块中,其中所述测试模块中的通信接口模块,验证系统中的通信接口,断言判决模块,报告生成模块,人机交互界面和C语言接口不因为被测通信系统的不同而改变。
其中,所述的命令处理模块,包含解码模块,分解数据帧中的命令字与参数,并进行循环冗余校验码(Cyclical Redundancy Check,简称为CRC)计算,与输入的CRC后缀比较,验证数据正确性,根据不同的命令字,将命令参数输入至不同的任务;编码模块,将收集到系统响应按照任务要求进行编码,并计算CRC,传输给通信模块;配置模块,按照命令字和参数值,配置为不同的激励模式,主要包括接收数据、发送数据、设置时钟、设置模式等系统任务;激励产生模块,按照配置模块提供的激励模式以及接收到的命令参数生成激励输入给DUT;激励收集模块,按照配置模块的指示,收集相关的响应值,输送给编码模块。
所述的验证模块与测试模块之间的通信信号分为命令信号帧和响应信号帧,其中:
命令信号帧由验证模块向测试模块发送,其格式为:命令长度,其后跟随命令代码,之后发送命令参数、以CRC校验码结尾;
响应信号帧由测试模块向验证模块输送,其格式为:由响应长度,之后发送响应数据,最后以CRC校验码结尾。
按照本发明的另一各方面,本发明提供用于通信系统实时仿真验证的方法,该方法包括以下步骤:
Step1:向系统中输入测试向量及响应参考值。该向量及参考值可由设计人员手动输入,或是由C程序或者tcl程序生成;
Step2:生成命令信号帧。将输入向量按照通信接口要求的命令信号帧格式进行编码生成命令信号帧;
Step3:将信号帧输送给通信接口,由通信接口输送给linux标准输出通道;同时,若需要利用调用C程序计算响应参考值,则需将信号帧送至C语言接口;
Step4:测试模块接收命令信号帧;
测试模块的通信接口通过扫描标准输入通道接收命令信号帧;
Step5:分解命令信号帧;
去掉帧头长度部分,将命令信号帧按照命令编码输送给配置模块和激励生成模块;
Step6:命令处理;
在配置模块中,根据命令编码,调用系统任务,处理命令信号帧中的内容,之后执行根据命令内容选择执行Step7,Step8或是Step9;
Step7:生成激励;
根据命令处理中得到的内容,生成符合被测系统要求的输入信号;
Step8:设定被测系统某寄存器的值;
根据命令处理中得到的内容,设定被测系统某寄存器的值;
Step9:收集响应;
根据命令处理中得到的内容,控制响应收集模块收集被测系统得响应,或者直接提取被测系统中某寄存器的值;
Step10:将收集的响应进行编码;
将收集到响应信号按照通信接口要求的响应信号帧的要求进行编码;
Step11:将响应信号发送至验证模块;
Step12:接收响应信号帧;
Step13:对响应信号进行分解,去掉帧结构,该帧格式包括被测系统输出信号的帧格式和响应信号帧格式,提取有效数据,并将数据送至断言判决模块;
Step14:断言判决;
将得到的响应与响应参考值进行比较;
Step15:可选操作,根据Step1的设置,对结果进行分类和统计,该步骤用于N测试向量的使用,其中,N为自然数,N≥2;
Step16:将结果输送至人机接口,完成本次验证过程。
本发明提供的上述方法中Step3,Step4是同时进行的,具体实施过程如下:
Step3.1:打开仿真器;
Step3.2:向标准输入通道中输入命令信号帧,并以“/n”结尾。
在Step3.1执行的同时,Step4同时执行:
Step4.1:在测试模块中打开标准输入输出通道;
Step4.2:扫描标准输入通道,当通道中不为空时,开始接收数据。
Step4.3:判断接收到第一个字是否为偶数。若为偶数,则命令信号帧帧头正确,继续执行Step4.4,否则,命令信号帧帧头不正确,完成此次接收过程,执行Step4.6。
Step4.4:判断接收到的数据是否为“/n”。若结果为“是”:则证明该条命令接收结束,执行Step4.6。若结果为“否”,则执行Step4.5。
Step4.5:继续接收数据,并将接收到的数据返回Step4.4进行判断。
Step4.6:接收结束,触发事件“command in”,启动解码模块和配置模块。
本发明提供的上述方法中Step11,Step12同时进行,其具体实施过程为:
Step11.1:当编码完成后,触发event“result out”,启动发送过程;
Step11.2:将响应帧输出至标准输出通道,并以“eof”结尾。
在11.2执行的同时,Step12同时在验证模块中执行
Step12.1:,扫描标准输出通道,当通道中不为空时,开始接收数据。
Step12.2:判断接收到的数据是否为“eof”。若结果为“是”:则证明该条命令接收结束,执行Step12.4。若结果为“否”,则执行Step12.3。
Step12.3:继续接收数据,并将接收到的数据返回Step4.4进行判断。
Step12.4:接收结束,将数据传至命令处理模块。
本发明所提供的验证系统和方法对的验证思想为:设计人员通过输入系统定义的命令对系统进行操作,当系统收到命令时,在验证模块中,系统对命令进行解析,根据命令的需要,组成一个16进制格式信号帧传输给测试模块。在测试模块中,在信号帧进行进一步解码,编码生成符合DUT要求的特定激励输入DUT,同时收集被测系统的响应值,返回到验证模块中,验证模块对返回内容进行解析判决,或引入断言对返回值进行分析。
采用本发明所述的系统与方法的优点在于:
(1)将仿真验证流程的各步骤彼此分开,可以选择只执行其中若干步骤,而放弃执行重复部分,从而避免由于重复执行仿真过程。
(2)该发明提供一种实时操作的界面和方式,不仅提供验证人员向量分析的功能,同时为设计人员提供实时操作的对仿真界面,便于发现问题,调试被测设计。
(3)该验证系统与方法使不同通信系统间具有可移植性。由于通信系统处理的信号均为某种固定的帧格式信号,因为建立该验证系统与方法后,设计人员在编写测试向量时,只需关注系统信号帧结构某个部分即可,利用通信系统对输入内容进行组帧,而不用进行信号整体进行编写,避免产生大量无关的测试向量和用于产生整体帧结构的时间。同时将该验证系统从一个通信系统的验证转移至另一通信系统得验证只需改变其测试系统的编码格式即可,增强了系统的可移植性。
附图说明
图1:为利用现有通信系统集成电路设计的仿真验证系统的验证过程流程图;
图2:为利用本发明所提供的用于通信系统集成电路设计的仿真验证系统的验证过程流程图;
图3:为本发明所提供的用于通信系统集成电路设计的仿真验证系统的结构示意图;
图4:为本发明所提供的用于通信系统集成电路设计的仿真验证系统中测试模块的结构示意图;
图5:为本发明所提供的用于通信系统集成电路设计的仿真验证系统中测试模块与验证模块的通信数据帧结构;
图6:为本发明所提供的用于通信系统集成电路设计的仿真验证方法的流程图;
图7:为本发明所提供的用于通信系统集成电路设计的仿真验证系统与方法中由验证模块到测试模块的通信方法示意图;
图8:为本发明所提供的用于通信系统集成电路设计的仿真验证系统与方法中由测试模块到验证模块的通信方法示意图。
图中: 1.测试模块 2.验证模块
3.测试模块中的命令处 4.测试模块中的通信接 5.验证模块中的命令处
理模块 口 理模块
6.验证模块中的命令处 7.断言判决模块 8.报告生成与分析模块
理模块
9.人机接口 10.C语言接口 11.解码模块
12.编码模块 13.配置模块 14.激励产生模块
15.响应收集模块 16.命令信号帧格式 17.命令长度
18.命令代码 19.命令参数 20.第一CRC校验码
21.响应信号帧格式 22.响应长度 23.响应数据
24.第二CRC校验码
具体实施方式
下面结合附图对本发明的具体实施方式进行说明。
如图2所示,为利用本发明所提供的用于通信系统集成电路设计的仿真验证系统的验证过程流程图。该流程图所示的验证过程可分为如下几个步骤:
Step1:编写被测设计;
Step2:编写测试平台;
Step3:利用仿真工具进行编译;
Step4:编写测试向量;
Step5:仿真并验证;
Step6:判断响应是否正确,如果响应正确,则结束验证过程;
Step7:如果Step6判断不正确,如判断由设计本身或者测试平台造成的问题,则返Step1;
Step8:如果Step6判断不正确,如测试向量造成的问题,提取错误的测试向量进行修改,返回Step5。
与图1比较,本发明所提供用于通信系统集成电路设计的仿真验证系统的验证过程首先分立测试平台的编写和测试向量的编写,并调整了验证过程中各步骤的执行过程,使得在测试向量的发生问题时,只须执行到修改相应仿真过程,而不需重复执行编译过程和已经运行正确的仿真过程,同时不需要改动测试平台。由图中可见,有测试向量引起问题的循环支路的路径缩短,有效减少了仿真验证的时间。
如图3所示:为本发明所提供的用于通信系统集成电路设计的仿真验证系统的结构示意图,包含测试模块1和验证模块2,其中,测试模块1,在仿真器中运行,用于通过调用相关任务,产生被测设计DUT所需的特定帧格式的激励数据以及收集DUT产生的响应,和验证模块,用于产生测试向量和参考响应值,并与DUT的响应值进行比较。测试模块1包含有测试模块中的命令处理模块3和测试模块中的通信接口4,其具体功能与结构在图5中说明。同时,验证模块2,在linux tcl编译器中运行,包含有验证模块中的通信接口5,完成与测试模块的通信,验证模块中的命令处理模块6,生成由设计人员要求的输入转化为编码信号格式,传输给通信接口,并将由通信接口接收到的数据解码为有效数据传输给设计人员,断言判决模块7,用于生成参考响应值,报告生成与分析模块8,用于生成由大量测试存档文件,人机交互界面9和C语言接口10。
在所述的验证模块与测试模块中,其中所述测试模块中的通信接口模块,验证系统中的通信接口,断言判决模块,报告生成模块,人机交互界面和C语言接口不因为被测通信系统的不同而改变。
其具体连接关系于数据处理过程描述如下:
设计人员或者验证人员将测试向量通过人机交互界面9输入计算机,测试向量进入验证模块2,在验证模块2中调用命令处理模块6,将数据编码为图5所示的帧格式,并输送到通信接口5,帧数据由通信接口传递给测试模块1,同时,数据帧可由设计人员选择通过C语言接口10传递给C程序仿真器用以生成响应参考值。测试模块1中的通信接口4扫描得到验证模块的帧数据后传送给测试模块中的命令处理模块3,生成符合被测通信系统的激励格式传输给被测系统进行仿真。同时,命令处理模块3收集来自被测通信系统的响应,编码后送入通信接口4发送给验证模块。验证模块的通信接口5接收数据在命令处理模块6中剥离帧格式,提取响应信息中的有效数据送至断言判断模块,断言模块7比较响应值与响应参考值,并将结果返回人机交互界面9。响应参考值可由设计人员事先设定或通过C语言接口10,得到的C语言仿真结果。在整个仿真过程中所产生的数据,均由报告生成与分析模块8所记录,记录文本文件并利用perl语言对文件进行分析汇总,得到生成报告。
该验证思想可具体描述为以下几个部分:首先,设计人员通过输入系统定义的命令对系统进行操作,输入相应的测试向量。当系统收到命令时,系统对命令进行解析,根据命令的需要,对信号帧进行编码生成符合被测系统要求的特定帧格式的激励输入被测系统,同时,收集被测系统的响应值,并对信号内容进行解析判决,于输入参考值进行比较判决,得到仿真验证的结果。
本发明针对激励和响应均为固定帧格式的通信系统的仿真验证。例如,本发明既可应用于标准串口及串行外设接口SPI主从设备的简单系统仿真,也可应用于数字电视调制器、导航接收机等大规模的通信系统的仿真验证。
如图4所示,为本发明所提供的用于通信系统集成电路设计的仿真验证系统中测试模块的结构示意图,测试模块1包含有命令处理模块3和通信接口4。其中,命令处理模块3,由各种任务模块组成,当测试模块收到来自验证品平台的指令后,调用所指定的任务块,这些任务包含两个方面,一方面生成输入激励,或强制改变DUT中寄存器的值,另一方面是收集DUT的响应,或者查询DUT中寄存器的值反馈给验证平台进行处理。与验证模块的通信接口4,完成与验证平台之间的通讯。
其中,所述的命令处理模块3,包含解码模块11,分解数据帧中的命令字与参数,并进行CRC计算,与输入的CRC后缀比较,验证数据正确性,根据不同的命令字,将命令参数输入至不同的任务;编码模块12,将收集到系统响应按照任务要求进行编码,并计算CRC,传输给通信模块;配置模块13,按照命令字和参数值,配置为不同的激励模式,其由verilog任务函数完成,函数主要包括接收数据、发送数据、设置时钟、设置模式;激励产生模块14,按照配置模块提供的激励模式以及接收到的命令参数生成激励输入给被测系统;激励收集模块15,按照配置模块的指示,收集相关的响应值,输送给编码模块。
测试模块的具体工作流程为:当通信接口4扫描系统标准输入通道有数据时,接收数据,将接收到数据送至解码单元11,解码单元11将数据进行解码,并进行CRC校验,得到的数据分为命令部分及参数部分,根据命令字的不同调用配置模块13中的不同任务,输入激励产生模块14,产生符合要求的激励,输入给被测系统。同时根据不同任务的指示,利用激励收集模块15采集被测系统的响应值,在编码模块12中按照通信接口的要求,进行编码,同时添加CRC校验码,输送至通信接口4。
如图5所示,为本发明所提供的用于通信系统集成电路设计的仿真验证系统中测试模块与验证模块的通信数据帧结构。本系统采用在仿真编译器和tcl编译器之间建立一个标准输入通道、一个标准输出通道,来达到实时传输的目的。该通道传输的数据传输格式为8比特数据。数据传输过程利用以数据的长度作为帧头,帧体为需要传输的数据,利用16位前向校验码作为结束。保证数据传输的正确性,因此在命令长度必定为偶数,当为奇数时,证明数据有误,数据无效。系统中所用到的CRC16校验码,为CRC-CCITT-16,其生成多项式为:
G(X)=x16+x12+x5+1
其具体的帧结构为:由验证模块向测试模块输送的命令信号帧16由命令长度17开始,其后跟随命令代码18、之后发送命令参数19、第一CRC校验码20结尾。由测试模块向验证模块输送响应信号帧21由响应长度22开始,之后发送响应数据23,最后以第二CRC校验码24结尾。
如图6所示,为本发明所提供的用于通信系统集成电路设计的仿真验证方法的流程图,该方法的具体步骤为:
Step1:向系统中输入测试向量及响应参考值。该向量及参考值可由设计人员手动输入,或是由C程序或者tc1程序生成;
Step2:生成命令信号帧。将输入向量按照图5要求的帧格式进行编码生成命令信号帧16;
Step3:发送命令信号帧。将信号帧16输送给通信接口5,由通信接口5输送给linux标准输出通道。同时,若需要利用调用C程序计算响应参考值,则需将信号帧送至C语言接口
Step4:测试模块1接收命令信号帧16。测试模块1的通信接口通过扫描标准输入通道接收命令信号帧。
Step5:分解命令信号帧。去掉帧头长度部分,将命令信号帧按照命令编码输送给配置模块13和激励生成模块14。
Step6:命令处理。在配置模块13中,根据命令编码,调用系统任务,处理命令信号帧中的内容,之后执行根据命令内容选择执行Step7,Step8或是Step9。
Step7:生成激励。根据命令处理中得到的内容,生成符合被测系统要求的输入信号。
Step8:设定被测系统某寄存器的值。根据命令处理中得到的内容,设定被测系统某寄存器的值。
Step9:收集响应。根据命令处理中得到的内容,控制响应收集模块15收集被测系统得响应,或者直接提取被测系统中某寄存器的值。
Step10:将收集的响应进行编码。将收集到响应信号根据图6中响应信号帧的要求进行编码。
Step11:将响应信号发送至验证模块2。
Step12:接收响应信号帧。
Step13:对响应信号进行分解,去掉帧结构,该帧格式包括被测系统输出信号的帧格式和响应信号帧格式,提取有效数据,并将数据送至断言判决模块。
Step14:断言判决;
将得到的响应与响应参考值进行比较;
Step15:可选操作,根据Step1的设置,对结果进行分类和统计,该步骤用于N测试向量的使用,其中,N为自然数,N≥2;
Step16:将结果输送至人机接口,完成本次验证过程。
如图7所示,为本发明所提供的用于通信系统集成电路设计的仿真验证系统与方法中由验证模块到测试模块的通信方法示意图,即图7中Step3,Step4是同时进行的,具体实施过程如下:
Step3.1:打开仿真器;
Step3.2:向标准输入通道中输入命令信号帧,并以“/n”结尾。
在Step3.1执行的同时,Step4同时执行:
Step4.1:在测试模块中打开标准输入输出通道;
Step4.2:扫描标准输入通道,当通道中不为空时,开始接收数据。
Step4.3:判断接收到第一个字是否为偶数。若为偶数,则命令信号帧头正确,继续执行Step4.4,否则,命令信号帧头不正确,完成此次接收过程,执行Step4.6。
Step4.4:判断接收到的数据是否为“/n”。若结果为“是”:则证明该条命令接收结束,执行Step4.6。若结果为“否”,则执行Step4.5。
Step4.5:继续接收数据,并将接收到的数据返回Step4.4进行判断。
Step4.6:接收结束,触发事件“command in”,启动解码模块和配置模块。
如图8所示,为本发明所提供的用于通信系统集成电路设计的仿真验证系统与方法中由测试模块到验证模块的通信方法示意图,即为图8中Step11,Step12同时进行,其具体实施过程为:
Step11.1:当编码完成后,触发event“result out”,启动发送过程;
Step11.2:将响应帧输出至标准输出通道,并以“eof”结尾。
在11.2执行的同时,Step12同时在验证模块中执行
Step12.1:,扫描标准输出通道,当通道中不为空时,开始接收数据。
Step12.2:判断接收到的数据是否为“eof”。若结果为“是”:则证明该条命令接收结束,执行Step12.4。若结果为“否”,则执行Step12.3。
Step12.3:继续接收数据,并将接收到的数据返回Step4.4进行判断。
Step12.4:接收结束,将数据传至命令处理模块6。
Claims (6)
1.一种用于通信系统集成电路设计的实时仿真验证系统,该系统包括:
测试模块,用于通过调用相关任务,产生被测系统所需的特定帧格式的激励数据以及收集被测系统产生的响应值;
验证模块,用于产生测试向量和参考响应值,并与被测系统的响应值进行比较,得到验证结果;
其特征在于,所述的测试模块,在仿真器中运行,包含命令处理模块,由各种任务块组成,当测试模块收到来自验证平台的指令后,调用所指定的任务块,这些任务块包含两个方面,一方面生成输入激励,或强制改变被测系统中寄存器的值,另一方面是收集被测系统的响应值,或者查询被测系统中寄存器的值反馈给验证平台进行处理;还包含通信接口模块,完成测试模块与验证模块之间的通信;
所述的验证模块,在linux tcl编译器中运行,包含通信接口,完成与测试模块的通信,及命令处理模块,生成由设计人员要求的输入转化为编码信号格式,传输给通信接口,并将由通信接口接收到的数据解码为有效数据,还包括断言判决模块,将响应值与参考值比较,得到验证结果,和报告生成模块,用于生成测试存档文件,以及人机交互界面和C语言接口;
在所述的验证模块与测试模块中,其中所述测试模块中的通信接口模块,验证模块中的通信接口,断言判决模块,报告生成模块,人机交互界面和C语言接口不因为被测通信系统的不同而改变;
所述的验证模块与测试模块之间的通信信号分为命令信号帧和响应信号帧;所述的命令信号帧由验证模块向测试模块发送,其格式为:命令长度,其后跟随命令代码,之后发送命令参数,以CRC校验码结尾;所述的响应信号帧由测试模块向验证模块输送,其格式为:响应长度,之后发送响应值,最后以CRC校验码结尾。
2.根据权利要求1所述的用于通信系统集成电路设计的实时仿真验证系统,其特征在于,其所述的测试模块中的命令处理模块包括:
解码模块,分解数据帧中的命令字与参数值,并进行CRC计算,与输入的CRC后缀比较,验证数据正确性;
编码模块,将收集到系统响应按照任务要求进行编码,并计算CRC,传输给测试模块中的通信接口模块;
配置模块,按照命令字和参数值,配置为不同的激励模式,其由verilog任务函数完成,函数主要包括接收数据、发送数据、设置时钟、设置模式;
激励产生模块,按照配置模块提供的激励模式以及接收到的命令参数生成激励输入给被 测系统;
激励收集模块,按照配置模块的指示,收集相关的响应值,输送给编码模块。
3.根据权利要求1所述的用于通信系统集成电路设计的实时仿真验证系统,其特征在于,所述的测试模块与验证模块的通信接口直接相连,完成与验证平台之间的通讯。
4.一种用于通信系统集成电路设计的仿真验证方法,其特征在于,该方法的具体步骤为:
Step1:向系统中输入测试向量及响应参考值,该向量及参考值由设计人员手动输入,或是由C程序或者tcl程序生成;
Step2:生成命令信号帧;
将输入向量按照权利要求1中所述的命令信号帧格式进行编码生成命令信号帧;
Step3:发送命令信号帧;
将信号帧输送给通信接口,由通信接口输送给linux标准输出通道;同时,若需要利用调用C程序计算响应参考值,则需将信号帧送至C语言接口;
Step4:测试模块接收命令信号帧;
测试模块的通信接口通过扫描标准输入通道接收命令信号帧;
Step5:分解命令信号帧;
去掉帧头长度部分,将命令信号帧按照命令编码输送给配置模块和激励产生模块;
Step6:命令处理;
在配置模块中,根据命令编码,调用系统任务,处理命令信号帧中的内容,之后执行根据命令内容选择执行Step7,Step8或是Step9;
Step7:生成激励;
根据命令处理中得到的内容,生成符合被测系统要求的输入信号;
Step8:设定被测系统某寄存器的值;
根据命令处理中得到的内容,设定被测系统某寄存器的值;
Step9:收集响应值;
根据命令处理中得到的内容,控制响应收集模块收集被测系统的响应值,或者直接提取被测系统中某寄存器的值;
Step10:将收集的响应值进行编码;
将收集到响应值按照权利要求1中所述的响应信号帧的要求进行编码;
Step11:将响应信号帧发送至验证模块;
Step12:接收响应信号帧;
Step13:对响应信号帧进行分解,去掉帧结构,该帧格式包括被测系统输出信号的帧格式和响应信号帧格式,提取有效数据,并将数据送至断言判决模块;
Step14:断言判决;
将得到的响应值与响应参考值进行比较;
Step15:可选操作,根据Step1的设置,对结果进行分类和统计,该步骤用于N测试向量的使用,其中,N为自然数,N≥2;
Step16:将结果输送至人机交互界面,完成本次验证过程。
5.根据权利要求4所述的用于通信系统集成电路设计的仿真验证方法,其特征在于,步骤3,4同时执行,其中,步骤3又分为:
Step3.1:打开仿真器;
Step3.2:向标准输入通道中输入命令信号帧,并以“/n”结尾;
在Step3.1执行的同时,Step4同时执行:
Step4.1:在测试模块中打开标准输入输出通道;
Step4.2:扫描标准输入通道,当通道中不为空时,开始接收数据;
Step4.3:判断接收到第一个字是否为偶数;
若为偶数,则命令信号帧帧头正确,继续执行Step4.4;否则,命令信号帧帧头不正确,完成此次接收过程,执行Step4.6;
Step4.4:判断接收到的数据是否为“/n”;
若结果为“是”,则证明该条命令接收结束,执行Step4.6;
若结果为“否”,则执行Step4.5;
Step4.5:继续接收数据,并将接收到的数据返回Step4.4进行判断;
Step4.6:接收结束,触发事件“command in”,启动解码模块和配置模块。
6.根据权利要求5所述的用于通信系统集成电路设计的仿真验证方法,其特征在于,步骤11,12同时执行,其中,步骤11又分为:
Step11.1:当编码完成后,触发event“result out”,启动发送过程;
Step11.2:将响应信号帧输出至标准输出通道,并以“eof”结尾;
在11.2执行的同时,Step12同时在验证模块中执行:
Step12.1:扫描标准输出通道,当通道中不为空时,开始接收数据;
Step12.2:判断接收到的数据是否为“eof”;
若结果为“是”,则证明该条命令接收结束,执行Step12.4;
若结果为“否”,则执行Step12.3;
Step12.3:继续接收数据,并将接收到的数据返回Step4.4进行判断;
Step12.4:接收结束,将数据传至命令处理模块。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100808690A CN101504690B (zh) | 2009-03-26 | 2009-03-26 | 用于通信系统集成电路设计的实时仿真验证系统及其方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2009100808690A CN101504690B (zh) | 2009-03-26 | 2009-03-26 | 用于通信系统集成电路设计的实时仿真验证系统及其方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN101504690A CN101504690A (zh) | 2009-08-12 |
CN101504690B true CN101504690B (zh) | 2011-04-13 |
Family
ID=40976935
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2009100808690A Expired - Fee Related CN101504690B (zh) | 2009-03-26 | 2009-03-26 | 用于通信系统集成电路设计的实时仿真验证系统及其方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN101504690B (zh) |
Families Citing this family (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2012037796A1 (zh) * | 2010-09-21 | 2012-03-29 | 清华大学 | 用于集成电路制造设备的仿真平台 |
US8539278B2 (en) | 2010-10-29 | 2013-09-17 | Infineon Technologies Ag | Methods and systems for measuring I/O signals |
CN102012957A (zh) * | 2010-12-17 | 2011-04-13 | 天津曙光计算机产业有限公司 | 一种基于五元组的包分类逻辑代码验证方法 |
CN102156784B (zh) * | 2011-04-18 | 2013-01-02 | 烽火通信科技股份有限公司 | 验证环境图形化的芯片验证方法与装置 |
CN102201022A (zh) * | 2011-04-22 | 2011-09-28 | 青岛海信信芯科技有限公司 | 用于fpga验证的方法和装置 |
CN102147831A (zh) * | 2011-04-22 | 2011-08-10 | 青岛海信信芯科技有限公司 | 逻辑验证方法和装置 |
CN102957553B (zh) * | 2011-08-25 | 2018-04-27 | 中兴通讯股份有限公司 | 一种激励代码自动生成方法和装置 |
CN102970113B (zh) * | 2012-12-04 | 2016-02-17 | 山东万博科技股份有限公司 | 一种适用于多种智能网关的触发指令及触发方法 |
CN103020395B (zh) * | 2012-12-31 | 2015-08-05 | 上海高清数字科技产业有限公司 | 解复用接口模块的验证方法及验证系统 |
CN103838908B (zh) * | 2013-09-14 | 2017-08-25 | 电子科技大学 | 一种基于aig和sat求解器的gste模型检测方法 |
CN104679963B (zh) * | 2015-03-20 | 2018-04-27 | 杭州士兰微电子股份有限公司 | 一种基于tcl的仿真验证装置和方法 |
CN106788825A (zh) * | 2016-12-13 | 2017-05-31 | 中电科航空电子有限公司 | 一种无线电调谐单元测试装置 |
CN107247859B (zh) * | 2017-08-14 | 2018-11-02 | 深圳云天励飞技术有限公司 | 逻辑电路设计的验证方法、装置、电子设备及存储介质 |
CN107679266A (zh) * | 2017-08-22 | 2018-02-09 | 珠海泓芯科技有限公司 | 闪存电路的仿真方法及仿真装置 |
EP3451202B1 (de) * | 2017-09-01 | 2021-02-24 | dSPACE digital signal processing and control engineering GmbH | Verfahren zum erzeugen eines auf einem testgerät ausführbaren modells eines technischen systems und testgerät |
CN109977437B (zh) * | 2017-12-27 | 2023-01-03 | 长鑫存储技术有限公司 | 晶体管级电路的验证方法、装置、设备及计算机可读存储介质 |
CN109245855B (zh) * | 2018-08-24 | 2020-12-22 | 西安微电子技术研究所 | 一种rs编解码器的覆盖性验证方法及系统 |
CN109815099B (zh) * | 2018-12-28 | 2022-08-05 | 北京时代民芯科技有限公司 | Jesd204b控制器的fpga验证方法 |
CN110472289B (zh) * | 2019-07-17 | 2023-06-30 | 陕西千山航空电子有限责任公司 | 一种基于动态信号仿真的飞参系统测试验证方法 |
CN113343629B (zh) * | 2021-06-25 | 2023-02-28 | 海光信息技术股份有限公司 | 集成电路验证方法、代码生成方法、系统、设备和介质 |
CN115719047B (zh) * | 2022-11-14 | 2023-06-06 | 沐曦集成电路(上海)有限公司 | 基于波形gpu联合仿真系统 |
CN116938594B (zh) * | 2023-09-08 | 2024-03-22 | 数盾信息科技股份有限公司 | 一种基于高速加密技术的多层次身份验证系统 |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6498999B1 (en) * | 2000-07-24 | 2002-12-24 | Lsi Logic Corporation | Method and apparatus for design verification of an integrated circuit using a simulation test bench environment |
US6937257B1 (en) * | 2001-01-31 | 2005-08-30 | Pharsight Corporation | Unit tracking and notification in a graphical drug model editor |
CN1808451A (zh) * | 2005-01-19 | 2006-07-26 | 精工爱普生株式会社 | 非同步电路设计工具及计算机程序 |
CN1996263A (zh) * | 2005-12-28 | 2007-07-11 | 中国科学院微电子研究所 | 一种实时位真仿真开发系统及其方法 |
-
2009
- 2009-03-26 CN CN2009100808690A patent/CN101504690B/zh not_active Expired - Fee Related
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6498999B1 (en) * | 2000-07-24 | 2002-12-24 | Lsi Logic Corporation | Method and apparatus for design verification of an integrated circuit using a simulation test bench environment |
US6937257B1 (en) * | 2001-01-31 | 2005-08-30 | Pharsight Corporation | Unit tracking and notification in a graphical drug model editor |
CN1808451A (zh) * | 2005-01-19 | 2006-07-26 | 精工爱普生株式会社 | 非同步电路设计工具及计算机程序 |
CN1996263A (zh) * | 2005-12-28 | 2007-07-11 | 中国科学院微电子研究所 | 一种实时位真仿真开发系统及其方法 |
Also Published As
Publication number | Publication date |
---|---|
CN101504690A (zh) | 2009-08-12 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN101504690B (zh) | 用于通信系统集成电路设计的实时仿真验证系统及其方法 | |
Konrad et al. | Real-time specification patterns | |
Owre et al. | Formal verification for fault-tolerant architectures: Prolegomena to the design of PVS | |
CN101512481B (zh) | 模型检验安全性的参数化线程 | |
Chiappini et al. | Formalization and validation of a subset of the European Train Control System | |
Kim et al. | NuDE 2.0: A formal method-based software development, verification and safety analysis environment for digital I&Cs in NPPs | |
Liang et al. | FlexCL: A model of performance and power for OpenCL workloads on FPGAs | |
Muttillo et al. | Hepsycode-RT: A real-time extension for an ESL HW/SW co-design methodology | |
CN104216703A (zh) | 嵌入式软件系统程序的开发方法 | |
Lukács et al. | Formal modeling and verification of the functionality of electronic urban railway control systems through a case study | |
Bunker et al. | Formal hardware specification languages for protocol compliance verification | |
Liu | An approach to applying SOFL for agile process and its application in developing a test support tool | |
Ebeid et al. | HDL code generation from UML/MARTE sequence diagrams for verification and synthesis | |
Goli et al. | Through the looking glass: Automated design understanding of SystemC-based VPs at the ESL | |
Erkkinen | Embedded control system implementation and modeling issues | |
George et al. | An Integrated Simulation Environment for Parallel and Distributed System Prototying | |
Broy et al. | Enriching the software development process by formal methods | |
Zeyda et al. | Mechanised translation of control law diagrams into Circus | |
Ait_Oubelli et al. | From uml 2.0 sequence diagrams to promela code by graph transformation using atom3 | |
Yue et al. | Trap: trace runtime analysis of properties | |
CN101998124B (zh) | 一种对视频编码方法进行验证的系统和方法 | |
Arbab et al. | Synthesis of Reo circuits from scenario-based specifications | |
Ziegenbein et al. | A framework for highlevel performance validation of embedded hw/sw systems | |
Shi | Java2CSP: A system for verifying concurrent Java programs | |
CN114756205A (zh) | 测井应用程序集成方法及装置 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
C17 | Cessation of patent right | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20110413 Termination date: 20140326 |