集成电路设计规模越来越大，速度越来越快，复杂度也越来越高，因此有必要在更高的抽象级别对设计对象进行描述和验证，以实现更快的仿真速度及软硬件的协同验证。但是传统的设计在前期完成软硬件的划分后，对软硬件部分进行单独设计，在软硬件的集成平台没有完成之前，很少进行软硬件的协同仿真验证。许多重要的性质如性能、成本、实时性等，很大程度上是在设计早期决定的，在传统设计流程中，要到设计的后阶段进行系统整合和验证时才能发现，这时再返回设计的开始阶段修改设计，必然会大大延长设计周期，增加设计成本，其工作量往往也很大。
随着开发语言的不断完善，出现了些支持更高抽象级别的设计语言，如SystemC、System Verilog等，这些语言较好地实现了软硬件的协同验证。其中SystemC以更接近于C++的风格特点，而受到设计者的青睐。本文介绍了采用SystemC语言，在设计的前期实现软硬件协同验证的方法。
SystemC的简介
SystemC是由开放性的SystemC联盟组织(Open SystemC Initiative，OSCT)推出的一种系统级设计和验证语言，SystemC是基于C++的建模平台，其本质是在C++的基础上添加了硬件扩展库和仿真核，支持EDA设计中的各个抽象层次，如寄存器级、行为级、系统级的建模，能够表达并发性、实时性、交互性等硬件模型的概念。
SystemC完全支持C++的数据类型，如果从系统级建模而言，完全可以将SystemC作为C++来处理，可以使用标准的C++语言开发工具来建立、仿真、调试和探索设计对象的各种体系结构和算法描述。在本文中，对SystemC的调试采用了Visual C++ 6.0，对其进行的仿真用了ModelSim SE 6.1f。 RFID技术网
使用SystemC，可以像使用VHDL或者Verilog语言一样进行RTL级和行为级的建模。SystemC中主要的类包括模块(modules)、进程(processes)、端口(ports)、信号(signals)等，还有一个调度内核，负责在每一个时钟周期调度进程和更新信号值。为了支持寄存器传输级的并行描述，SystemC采用了与传统硬件描述语言基本相同的调度模式——基于△(delta)延时。一个△周期包括求值和更新两个阶段，在一个时间点上，这样的△周期会持续出现，直到再求值前后的结果不再发生变化。 电子技术书籍网
SystemC中的模块用关键字SC_MODULE来定义，其端口定义与Verilog类似。当存在多个模块时，在SystemC中用顶层函数sc_main()来实现各个模块的连接，没有该函数的代码是无法编译的。在SystemC中，进程是一个基本的执行单元，它被调用来仿真目标系统的行为。进程的行为是多样化的，可以实现某个函数的功能，也可以在运行过程中被挂起，并且进程是并行执行的，一个进程中不能包含或直接调用其他进程。SystemC的进程主要有两种，方法进程(SC_METHOD)和线程进程(SC_THREAD)。方法进程是唯一可以综合的RTL进程，它的特点是当敏感表上有事件发生，它就被调用，调用后立即返回。只有该类进程返回后，仿真系统的时间才有可能前进，因此该类进程不能被挂起。线程进程不是RTL级进程，它可以被挂起和重新激活，所以它的一个用途是用来描述验证平台(testbench)。 PCB设计网
基于SystemC的硬件软件协同验证技术
在传统的系统设计中，系统设计人员自己选择语言(通常是C或C++)编写可执行程序，调试并验证功能后，对系统进行软硬件的划分，并将需要硬件实现的部分交给RTL设计组，RTL设计组再在C/C++基础上重新编写设计对象，以将其综合成门电路，该流程如图1所示。在这个过程中，软件部分往往是用C/C++来编写的，对这部分的验证可以用Visual C++等来实现，而硬件部分通常是用Verilog或VHDL来编写的，这就需要设计者将C/C++转换为HDL，对其验证也只能单独用Modelsim等工具来完成，这样很难在早期实现协同验证，必须等软硬件都各自验证完成，再用基于软硬件的集成平台来验证，但此时设计已经基本完成，如果发现错误，其修改工作量是很可观的。 RFID技术网
图1 传统设计过程图
与传统的方法相比，基于SystemC的设计流程与以前的设计流程本质区别在于，使用一种统一的语言就可以完成从系统级到RTL，从软件到硬件的全部设计，整个设计的软硬件可以协同设计和仿真。SystemC提供了在高抽象级别使用抽象数据类型对系统的硬件部分进行建模，支持软硬件早期的协同验证。图2为基于SystemC的设计流程，从C/C++到HDL的过程不需要再作转换，可以用一种语言完成所有设计和验证。 电子电路图
图2 SystemC设计流程图
在图2中，由于SystemC实质上就是C++，所以把C/C++的模型转换为SystemC的模型并没有多大难度，设计者完全可以用SystemC进行设计，并用它生成各种测试基准进行验证。同时软硬件协同验证的阶段也提前到了设计的初期，这样在硬件平台实现之前就可以对设计的合理性和可行性做出充分的评价，并可以尽早对设计进行优化。 电子电路图
用SystemC进行软硬件协同设计和验证的具体过程如图3所示。通过使用SystemC类库，设计者可以编写目标系统的系统层(system level)、行为层(behavioral level)或RTL层的SystemC模型代码。SystemC类库在其中起到两个作用：一是提供了描述硬件行为如并发、层次化模块、端口、时钟等这些类的实现；二是提供了一个轻型的进程调度核。使用标准的C++编译器，如Visual C++等，可以将设计者编写的SystemC代码进行编译、链接，得到一个可执行的程序，该程序的执行的结果就是设计者所设计的目标系统的模拟运行，用于验证设计正确与否的各种测试基准同样使用SystemC编写，并且随同设计一起编译，SystemC的代码调试可以使用任何常见的C++调试环境进行调试，如Visual C++。另外在模拟中还可以产生波形文件，并使用常见的波形显示工具如Modelsim等进行分析。
图3 SystemC设计流程图
上面提到的在系统级和行为级时，软硬件划分之后，对整个系统的功能用SystemC来实现软硬件的协同验证，接下来就是设计中硬件部分的细化，在RTL级实现。一种理想的情况当然是在RTL级也一直沿用SystemC，对系统级的SystemC进一步的细化到RTL级。但事实上，现在SystemC对RTL级的支持并不够，所以将SystemC转换为可综合的HDL就不可避免。 PCB设计网
SystemC不仅可以在高抽象层次单独对设计进行软硬件的协同验证，还可以和Verilog或VHDL一起进行联合的验证，这就为真正意义上的协同验证提供了可能性。
在ModelSim SE 6.1f及其以上的版本中，都支持对SystemC和HDL的混合验证。在这种情况下，设计的硬件部分已经用HDL语言完成，而软件部分完全可以用SystemC来实现。在集成平台没有完成时，只要能用SystemC实现软硬件的通信，实现软硬件协同验证显然可以做到。而SystemC充分考虑到这一点，在ModelSim SE 6.1f中很好地支持了混合的编译和验证。在ModelSim SE 6.1f中，对Verilog的module编译用vlog命令，对SystemC的module编译用sccom-g命令，编译完成后用sccom-link命令将所有的对象连接起来，从而可以完成编译和仿真，具体的过程可以参阅ModelSim SE 6.1f的用户手册，本文也讲在接下来的例子中有针对性地进行说明。 电子技术书籍网
软硬件协同验证举例 电子技术论文网
下面将以H.264解码器为例，介绍如何进行软硬件的协同验证。限于篇幅，只对其中关键性的步骤给出相关的分析和介绍。 PCB设计网
根据上文中给出的过程，在完成对解码器进行软硬件划分后，对软硬件部分用SystemC语言来设计，并进行Visual C++下的协同验证，限于篇幅，对这部分不做说明，设计者可以自己参考SystemC的语法完成。这之后，将硬件部分用Verilog实现。在完成软件部分和硬件部分各自单独的验证之后，为了实现软硬件的协同仿真，在软件部分加了一个实现系统总线传输功能的进程，而硬件部分的各个模块则作为接在系统总线上的单元，这样以来，软件部分就可以通过进程实现与系统总线上的硬件模块通信。实验室中对H.264解码器完成了软硬件的划分，并完成了行为级协同验证，在接下来的过程中本文将对读者关心的几个关键步骤进行简单介绍。
● C/C++向SystemC的转化
由上文中可以看出，C/C++模型向SystemC模型的转换是协同验证的开端。C语言向SystemC的转换，可以认为是C语言向C++转换的过程。在H.264解码器设计中，软件部分是用C语言描述的，故而这里将着重完成C模型向SystemC模型的转换。
在所有的C语言代码中，程序的开始都是main()函数，通过main函数调用其他函数。而在SystemC中，主要成分则是进程。于是很容易想到用进程来代替函数的功能，但是直接的转换是行不通的，因为进程是并行的。根据H.264解码器的C语言代码，把它整个作为一个module，先定义SystemC的一个顶层模块SC_MODULE(H264top)，接下来对H264top这个模块定义端口和进程，对端口的定义可以根据具体情况而定，而对于进程的定义，必须把原来的C语言的main函数定义成一个方法进程SC_METHOD(prc_main)，这个取名为prc_main进程在功能上完全等同于main函数，通过这个进程来调用原先的其他函数。完成这些转换后，再加上一个顶层函数sc_main()来实现连接，这样软件部分向SystemC的转换就基本完成，可以到Visual C++中编译调试了。
● 完成软硬件部分的结合，实现协同仿真 电子电路图
这一步是整个协同仿真中最为关键的一步。一般意义上，软件部分和硬件部分无法直接连接，它们之间必须要有一条系统总线来实现通信。
在SystemC改写的软件模块中，为了要实现软硬件的交互，用Modelsim实现软硬件协同仿真，定义了一个线程进程SW2HW，用于软件与硬件之间的通信。在用SystemC实现这这个进程时，要注意使它的行为符合系统总线的传输协议。根据SystemC语法，SW2HW作为模块H264top的一个进程，它与方法进程prc_main是并行的，并且两者不可以互相调用，那么更谈不上互相通信。为了解决这个矛盾，SystemC中指出，进程可以和模块的其他成员函数相互调用。于是在实现软硬件通信的进程SW2HW后，还需要把原来在进程prc_main中的，需要和硬件交互的函数重新在模块顶层模块H264top中定义为成员函数。这样软硬件的交互才能真正实现。 RFID技术网
结语 电子电路图
以往，硬件软件协同验证技术往往是使用一些复杂的数据结构作为描述、分析和综合的平台，这样的结构只能称为虚拟平台，它需要复杂的工具来整合不同软硬件设计语言和进行协合验证。本文的研究采用一个可执行的SystemC描述来代替这个虚拟平台，在设计过程中，设计者可以使用一个可执行的SystemC描述做为设计对象，在完成RTL级的设计后，也可以通过SystemC编写的通信机制实现软硬件的实时通信，达到软硬件协同仿真的目的。 RFID技术网
原文地址:http://www.epc.com.cn/magzine/20070201/8455.asp
点击这里免费订阅《今日电子》杂志.