前言

当面临复杂的项目时，硬件与韧体两方面的人才必须从一开始的规格制定，一直到产品的实际推出期间密切合作，在整个开发过程中，双方面都必须要有一个方法来验证所开发的内容，虽然在硬件宏功能方面可以使用RTL仿真来独立进行除错，不过面临的问题还是在韧体方面，因为它只有在硬件完成时才能进行精确的测试。

但等待硬件的完成会对项目的进程带来时间的浪费，原因是这两个部份无法同时进行作业，另一个硬件与韧体RTL协同仿真所面临的问题则是有关速度的效能。

韧体的测试有时代表了必须产生用来验证算法中特定情况的测试序列码，要在仿真中找出单一算法中的一个错误可能会非常耗时，同时当韧体的复杂度越来越高，再加上它本身采用算法的特性，RTL仿真的不足就越来越明显。

问题描述

对于这些传统的问题，解决的方法只能靠软件仿真器，完全针对韧体开发设计，它们能够用来进行算法的除错，但在硬件的精确度上却非常低，原因在于它并没有导入时间的概念，也没有考虑到硬件同时运作的情况，虽然算法中的宏错误能够被侦测，但却有相当大部份的错误无法被发现，造成错误的伪验证码。

就算采用独立的韧体与硬件验证可以进一步产生一些在两个部份合并测试时才会出现的错误，但还是会面临当问题发生时，到底哪一方面才是出错来源的困扰，甚至在最糟的情况下还可能造成需要重新设计的情况，代价可谓不低。

在目前的系统设计中，通常缺乏成熟并且定义明确的系统化设计方法，可行的第一个有效改善步骤是采用以RTL开发为基础的传统设计方式，搭配上适合软件开发，使用SystemC以及TLM标准的高效率软件仿真器。

透过这样的方式，将可以架构出相当接近硬件规格的SoC仿真环境，同时也可以节省大量的仿真时间。

SystemC/TLM介绍

SystemC主要来自于使用C++语言架构系统软硬件部件模型的想法，在1999年9月第一次公开推出，同时并将掌控权交给OSCI(Open SystemC Initiative)，这代表了SystemC链接库可以免费使用，同时直接由因特网下载(www.systemc.org)。

《图一 SystemC的发展历史》

架构介绍

SystemC链接库主要由实现以下功能的C++类别组成：

硬件部件以模块方式表示，模块(module)可以包含一系列相互或与其他外部模块同步的程序(process)，要与外部模块沟通，程序可以使用模块端口(port)，每个端口都链接到一个接口(interface)，并在接口上进行一系列访问方法(access method)的宣告，所提供的访问方法则依信道(channel)的型态而定。

SystemC的仿真可以在单处理器计算机上执行，为了要管理并行运作的同时性、程序同步以及时间的仿真，SystemC整合了类似于VHDL中所使用的排程器(scheduler)。

《图二 SystemC架构》

抽象层

SystemC拥有以RTL层级描述硬件模型的能力，因此，和传统的VHDL仿真比较，用来仿真一项工作的计算机处理器信息量基本上大致相同，事实上SystemC并没有提供能够强化效能的技巧，因此处理器指令的数量必须要降低。

为了达到这个目的，唯一的解决方案就是舍弃包含在RTL层的部份信息，抽象的程度越高，仿真的速度就越快。

《图三 抽象层》

而在设计时程上，Vasishta表示，eASIC的解决方案仅需4周就能完成工程样品，之后的验证和修改也十分的容易和便利，最快2个月就能完成一个设计时程。

为了达到这个目的，唯一的解决方案就是舍弃包含在RTL层的部份信息，抽象的程度越高，仿真的速度就越快。

在RTL模型描述中，通常会使用一个频率来进行同步，每一个缓存器、每个总线以及每个位都以单一频率周期的方式描述。

SystemC设计工程师可以依本身的需求来描述系统，同时在同一个设计中自由混用不同程度的抽象层。

交换层级模型的建立(TLM)

由于一个系统可以用许多不同的方式来建立模型，因此需要定义一些模型建立标准，其中的一项标准为交换层级模型(TLM, Transaction Level Model)，它建议了一个将模块以层级结构方式安排，并在功能与RTL模型间建立抽象层，并在同时维持高仿真效能的通用方式，由于具有这些特点，TLM标准相当适合用来测试嵌入式软件。

《图四 TLM交换》

TLM的概念是将每个硬件模型的功能和与其他外围模型的通讯分离。

当模块处理完内部工作并希望将结果与其他模块沟通时，就必须进行一个交换动作，交换动作的型态则由信道接口中所宣告的一系列方法中选择。

这些交换动作的实现在信道内进行，这代表了：

交换动作并不一定要有数据的传输，中断也可以以TLM交换动作来加以仿真。

通常模块的功能或接口应该要：

TLM的效能

RTL层级的许多信息在TLM抽象层并不会被采用，例如总线交换动作所使用的周期数并未进行仿真，但另一方面，交换动作所需耗费的大略时间则会加以导入，也就是说，只有对模块同步有用的信息才会被保留，因此可以节省大量的处理器指令。通常变量所使用的数据型态为C++本身所原有，以便能够尽可能地接近计算机处理器的架构。

虽然在仿真速度上的改善很难量化，但在效能表现上则可以比使用RTL仿真更接近序列仿真的结果。

TLM的进一步改善

在整个TLM系统模型建立完成后，将单一模块或信道的实现交给更低阶层，例如在交换动作发生时观察RTL信号的行为表现，或者在系统的精确位置测试硬件实现的相关动作将会有所帮助。

TLM架构的模块化特性让整个改善动作变得更加简单，所有的硬件模型都拥有独立于外围模型以及相关信道的内部功能。

这代表了单一硬件模块中的功能可以全部重新定义，并重新整合到整个系统中而不会影响其他功能，相同的情况也可以在信道上实现，它们也能够在不影响模块实现的情况下重新定义。

《图五 TLM信道的改善》

设计方法

如前面所描述，在传统的设计流程中，韧体团队在RTL硬件完成前，基本上无法进行程序代码的开发。

为了加速韧体开发的速度，在软硬件功能分割确定后，第一个目标就是要知道哪些功能必须在SystemC/TLM仿真器中建立模型。

硬件架构的分析应该要在进行任何RTL开发前提供模块的硬件规格，当架构的规格符合双方团队的要求后，就能够同时进行开发工作：

由于TLM模型的描述要比RTL设计快上许多，因此SystemC设计工程师可以相当快速地完成TLM模型，同时硬件团队也能够继续使用RTL仿真来进行除错。在设计时程的初期，应该要进行韧体驱动程序的开发以便验证RTL外围以及SystemC外围模型，接着再进行真正的韧体开发。

选择适当的模型建立层级

现在让我们考虑使用SystemC软件仿真器进行通用系统化单芯片开发的情况，系统包含由硬件外围环绕的可程序处理器组成，由于仿真器的目的是测试嵌入式软件，因此所有的硬件模型在设计时必须保留韧体测试的功能，TLM标准提供了硬件模块模型建立的主要原则，并为抽象层留下弹性自由空间。

如果能够降低硬件模型执行一项工作的交换动作数量，那么模型就能够提供更佳的仿真速度，但从另一个角度来看，如果细节被抽象得太过分，那么就可能会遗漏某些关键步骤。

SystemC设计工程师的责任是以韧体开发工程师的角度决定有用与无用的功能，高效率的TLM模型必须：

SystemC设计工程师应该要先阅读模块的规格以便萃取出对韧体有用的宏功能，相当明显地，最终系统的验证也必须以FPGA或硬件仿真平台为基础。以韧体要求开始并在新韧体介入发生时结束来进行宏功能的安排，因此，每个宏功能都能够以下列的交换动作程序来总结：

硬件外围在对韧体要求进行响应前可能需要与其他硬件模型进行一些交换动作。

案例研究

这个通用案例研究包含了以C语言进行编程的处理器，处理器与C/C++语言兼容的事实相当重要，因为它将可以简化在SystemC(C++)环境中测试韧体的整合动作。

处理器由两个硬件外围环绕，分别为执行：

韧体团队必须进行微处理器的编程，两个硬件模块的RTL功能会在专用的硬件规格中描述。

韧体的功能与限制必须要事先确认，以便能够为硬件模块选择模型建立的层级，同时也必须考虑到这个适配卡会由外部接收数据并将它写入内存中：

《图六 系统化单芯片案例力研究》

仿真环境

我们的目标是进行前述系统化单芯片的仿真：

SystemC链接库并无法与任意能够进行C/C++程序代码除错的其他软件兼容，因此必须使用兼容的开发环境进行编译，这些链接库可以简单地以免费的gcc Linux套件进行编译。

SystemC链接库必须搭配选用的开发软件进行编译，其他软件可能无法进行这项工作，不过我们可以使用gnu C++轻松地进行编译。

基本架构

依TLM原则，应该要有：

要进行系统化单芯片模型的除错，我们必须先定义测试的方法。

《图七 系统化单芯片模型》

微处理器模型

微处理器的模块与其他不同，原因是它的功能是以韧体原始码的方式来加以实现。

相当明显地，微处理器是一个包含许多内部组件的复杂组件：

所有的组件都与外部振荡器同步，内嵌软件首先以C/C++语言编写，接着经过转换/编译与链接转化成为CPU可以了解的汇编语言码，汇编语言码会被下载到CPU能够存取的内存当中。

TLM描述

大部份的系统化单芯片设计项目都会使用已经在市场上流行已久的微控制器组件而不会重新设计新的架构，由于微处理器模块的高复杂度，因此进行控制器的仿真相当耗时，整合微处理器的TLM模型而非RTL模型将可以大幅改善仿真的效能。

对于这个低成本的案例事实上还有进一步改善的方法，通常会在以SystemC概念为基础的昂贵商业工具中采用，以下我们将提出以TLM建立微处理器模型的简化方法。

微处理器的通讯是以模型内的信道来加以实现，在这里有两个，所有的可用交换动作会依韧体需求以及所连接硬件模块的功能列在相对应的端口接口上，例如一个简单的例子是以下的内存模型。

我们观察程序计数器(PC, Program Counter)的动作，它定义了两个CPU的宏功能：

这些功能可以使用两个内部的并行运作程序来建立模型：

两个程序间的同步可以使用内部事件达成。

当启动主程序模块时，它会呼叫以韧体原始码实现的主功能，透过这样的方式，真正的主程序原始码会由MAIN主程序部份执行。

而中断程序则与由硬件外围所产生的中断同步，依中断来源的不同，它会呼叫韧体原始码中适当的ISR函数，让实际例程原始码在INTERRUPT中断程序部份执行，透过这样的安排，就能够在加入其他程序时轻松管理中断的优先次序。

《图八 微处理器模型》

而中断程序则与由硬件外围所产生的中断同步，依中断来源的不同，它会呼叫韧体原始码中适当的ISR函数，让实际例程原始码在INTERRUPT中断程序部份执行，透过这样的安排，就能够在加入其他程序时轻松管理中断的优先次序。

轫体的整合

硬件缓存器和传统的韧体变量不同，它们被韧体用来与硬件外围沟通，当硬件缓存器被赋予一个数值时，韧体与硬件外围都必须指到相同的地址。

当硬件缓存器被韧体指定一个新的数值时，它有可能会对硬件外围产生中断要求，由于中断动作在TLM中以交换动作做为模型，因此必须呼叫适当的信道。

基本上有两种可能性：

在这两种情况中，韧体原始码必须包含专门针对仿真目的编写的特殊程序代码。

内存模型

在内存方面，这个例子中所使用的是一个FLASH组件，请参考图九。由于它的通讯协议要比传统的RAM内存复杂，因此我们将讨论如何依韧体的需求选择适当的抽象层级。

例如以目前的韧体限制，FLASH内存只用来作为数据写入，要进行数据FLASH内存的写入，就必须以特定顺序的写入序列码来进行：

在RTL数据流中，我们可以看到发送这些序列码时所有FLASH总线信号的变化，在输出入总线上，我门可看到以红色标示的两个命令周期，以及之后组件进行内存数据写入时的忙碌时间。

《图九 RTL中的Flash数据写入流程》

TLM描述

RTL中的Flash数据写入流程

在这里我们拥有两个模块，一个称为MICRO，用来实现韧体CPU，另一个称为FLASH，用来实现FLASH内存功能，两个模块间的通讯可以透过将所有总线交换动作重新分组的信道进行，每个模块也有都拥有存取信道的专用接口。

当微处理器(MICRO)已经准备好在仿真时间T0对FLASH送出命令时，整个仿真程序就进入了交换动作阶段，依韧体要求的不同，FLASH交换动作的实现可以通过以下步骤进行优化：

韧体程序暂停直到整个命令已经由FLASH处理完成：一个MICRO交换动作加上一个FLASH交换动作

仿真时间T0：MICRO交换动作取得命令型态、目标地址以及所要写入数据等参数

仿真时间T2：FLASH在工作完成后通知韧体

韧体程序暂停直到整个命令已经由FLASH处理完成：一个MICRO交换动作加上一个FLASH交换动作

韧体程序暂停直到命令完全送到FLASH：一个MICRO交换动作加上一个FLASH交换动作

仿真时间T0：MICRO交换动作取得命令型态、目标地址以及所要写入数据等参数

仿真时间T1：韧体程序重新启动

仿真时间T0：第一个MICRO交换动作取得第一个命令字节、目标地址以及所要写入数据等参数

仿真时间(T1+ tfw)：第二个MICRO交换动作取得第二个命令字节参数

仿真时间(T2+ tfw)：FLASH在工作完成后通知韧体

由于两种不同通讯方式的交换动作数量不同，因此模型的效能也有所不同：

依所选用解决方案的不同，MICRO与FLASH间的接口宣告也会不同，信道可以进一步改善来贴近RTL描述，但两个接口还会保持一样，修改的只有信道的内部实现方式。

同时更进一步，FLASH的功能必须依FLASH接口的交换动作来加以实现，如果信道经过改善，将不会影响FLASH的功能。

《图十 FLASH内存模型》

通讯协议模型

通讯协议模型是内部系统化单芯片组件与外部间的沟通桥梁，也就是测试内嵌软件的入口，通用的通讯协议接口可以将外部送入的数据转换成系统化单芯片内部组件能够了解的信号序列，并以相反的动作进行输出。

TLM描述

通讯协议模型是内部系统化单芯片组件与外部间的沟通桥梁，也就是测试内嵌软件的入口，通用的通讯协议接口可以将外部送入的数据转换成系统化单芯片内部组件能够了解的信号序列，并以相反的动作进行输出。

在内部通讯上我们拥有两个模块，一个是实现韧体CPU的MICRO，另一个则是实现通讯协议功能的PROTOCOL，两个模块间的通讯透过一个信道进行，并将韧体所需的总线交换动作重新分组，如果需要简化的范例可以参考内存模型部份。

外部系统化单芯片模块的通讯则对应到测试平台的输入，基本上并没有清楚定义的方法来进行测试，不过我们可以简单地区分为两种形式：

《图十一 内部通讯的通讯协议》

静态测试平台

SystemC仿真由SystemC主函数执行，称为sc_main，接着通过以下列四个步骤进行的典型仿真：

由sc_main程序离开

仿真可以先行启动一段预先设定的时间，或者直到所有的系统化单芯片模块结束执行动作。

所有触发动作的产生与结果的检查可以嵌入到：

不管是哪一种情况，在执行过程中用户都无法介入，如果韧体开发工程师希望执行新的测试以便对内嵌软件进行除错，那么他就必须修改测试码然后再进行新的仿真动作。

《图十二 静态测试平台》

不管是哪一种情况，在执行过程中用户都无法介入，如果韧体开发工程师希望执行新的测试以便对内嵌软件进行除错，那么他就必须修改测试码然后再进行新的仿真动作。

动态测试平台

如果韧体开发工程师可以在执行时直接进行新的测试而不需要重新启动SystemC仿真，那么整个仿真环境将会更有弹性。

基本上测试平台公用程序是一个GUI图形用户界面，为韧体开发工程师提供所有有用的测试，数据经过共享内存进行交换，而线程间的同步则由操作系统的事件处理程序负责。

PROTOCOL通讯协议的实现整合了操作系统的事件，当所有的系统化单芯片模型完成工作后，模型就会等待进行测试平台公用程序的触发，线程间通讯细节的选择采用与内存模块范例中相同的做法，例如依内嵌软件而定。

通过这样的方式，我们仿真了实际系统化单芯片的行为，并为韧体开发工程师加入除错功能。

依系统化单芯片应用的不同，结果的检查可以在测试平台公用程序或系统化单芯片的线程中完成。

《图十三 动态测试平台》

依系统化单芯片应用的不同，结果的检查可以在测试平台公用程序或系统化单芯片的线程中完成。

案例研究的应用

测试平台公用程序可以依韧体开发工程师的个别需求加以客制化。

例如完整的FLASH记忆卡仿真器已经依这些原则开发完成，韧体开发工程师可以通过智能型互动化公用程序实时地与系统化单芯片模型沟通。

这个GUI接口实现了韧体除错部份较高或较低阶层的功能：

以现有的系统化单芯片TLM模型为基础，我们也能够进行部份RTL/SystemC的协同仿真：

任何的TLM模块都可以整合到RTL设计中而不需要相对应的RTL模块，要链接这两种描述式语言，我们必须：

《图十四 测试平台公用程序范例》

结论

测试平台公用程序范例

目前许多市场上的软件已经使用SystemC语言来加速系统化单芯片项目的开发，毫无疑问地，SystemC在整合到设计方法后带来相当大的好处。

与其他语言比较，SystemC的一个重大优势在于它的标准化，每家公司都能够架构自有的除错工具而不需要受到任何工具供货商的限制，透过这样的方式，数据以及免费链接库的交换将变得更加容易。

依照这样的做法，ST推出了整合功能强大算法内嵌韧体的系统化单芯片记忆卡仿真环境，所使用的唯一外部工具是C/C++开发环境，和先前的设计方法比较，在由软件仿真转换到硬件仿真时可以取得相当良好的成果。