对系统单芯片（SoC）设计而言，能尽早在设计流程中得到可执行的平台模块是很重要的[3]。目前的作法是根据硬件描述语言平台模块的接脚（pin connection），这种方式受限于三个主要的问题：

在处理层级将系统单芯片平台模块化可以解决以上这些限制。处理层模块（TLM）是一种仿真数字系统的高阶处理方式，其内部详细的讯号传输方式与功能单元或通讯架构的详细建构分隔开来。讯号处理的需求藉由呼叫包覆低阶讯息交换细节的信道模块功能接口来达成。讯号处理层接口则专注在数据转换的功能性，而非它的架构。

随着SystemC 2.0的出现，它使得在缓存器转换层（RTL）之上，利用完美定义与标准模式来仿真系统模块的方式成为可能。SystemC是一种C++类别数据库，用来立即建造准确频率周期的模块、硬件架构、系统单芯片的软件与接口。较早的SystemC版本为设计架构的合成引进模块单元、输出入埠与讯号，以及利用程序来指定同时发生的行为。SystemC 2.0 为讯号传输与同步的广义模块加入一组新的特殊功能；这些功能是信道（channels）、接口（interfaces）与事件（events）。

信道是用来作为讯号传输与同步的包容物，建立一个或多个接口，一个接口表示在信道中所建立的一组存取方式，但接口本身不提供建构方式。接口方式呼叫（IMC）定义信道上模块单元间的讯号传输，信道连接模块单元的输出入埠，而模块可藉由输出入埠存取信道。事件是一种有弹性、低阶同步的基础，用来构成其它形式的同步行为。藉由等待与动态感应相关联（所组合而成）的事件，具有暂时改变程序感应（起动状态）的能力。

SystemC 2.0能够创造用户所定义的信道与接口，用户定义信道能被用来建立成为具有存取其它信道架构的模块。相较之下，基础信道没有可观察的架构，以及没有能力存取其它的信道。SpecC 定义类似的架构[1]，但私有语言缺乏SystemC／C++的面向对象方式，例如运算符溢载（overflow），与不支持讯号接脚层（pin-level）仿真。

SystemC 2.0 可以在讯号处理层建立高效能平台模块。高效能是因为模块容易发展且易于使用，时序与非时序功能模块，以及仿真低阶模块的整合变得容易，因此在设计发展过程的初期就能够产生可执行平台模块。

TLM模块可快速地执行

相较于讯号接脚层平台模块，仿真的加速来自于抽象概念的适当使用，而不是藉由使用C++或SystemC。抽象概念的适当应用表示摘取造成设计复杂化及降低仿真速度等不相关的讯息，同时保留相关讯息数据。在我们的例子当中，我们藉由使用抽象接口增加仿真速度，利用IMC结构，而非操作多数的讯号接脚。另外藉由使用区块接口方式的动态感应，也可以避免多余的处理程序活动，进而增快仿真的速度，

为了在系统背景下藉由附加侦错装置在以SystemC 覆盖的主控处理器顶层，侦错软件利用使用接口建立的直接接口达成这个目的。这样的设定不需要复杂的硬件／软件协同验证设定。

先前提到的一些问题，已经从其他地方获得解决了。相较于讯号接脚基础接口的方式，讯号处理层的抽象模块有较快的仿真速度，它同时也加速建立模块的过程[3]。ClassMate[4] 提供建立模块时所需类别的C++环境。其中所讨论到的测试输入组以类似平行的方式执行，却并不能确保与频率准确同步。而在硬件描述语言的环境下，模块仿真能够与频率准确同步且同相。但因为是属于讯号接脚层的模块，它的内容数据详尽且仿真速度很慢。最重要的是，发展详细复杂的模块很花时间，以及用来侦错硬件描述语言内容的软件非常地复杂。

讯号处理层总线模块

讯号处理层模块乃用于仿真模块与总线间数据的传递。在这种抽象层级下，只描述传输数据的重要部份，排除其余不相关的细节。这些细节数据将于稍后描述讯号接脚层传输时再来补充说明。抽象描述也因此加速仿真速度，并且仍旧是频率准确同步。

典型地，总线建立许多主从接口间的讯息传递。总线从主控端（master）传送数据到受控端，也从受控端传送数据到主控端。主控端触发数据传递的开始。主控端可以对受控端点读／写数据。利用地址数据可以明确地指定受控端的位置为何。当一个主控端取得总线的存取权，其余使用总线的需求就会进入排序。为了紧接而来的使用需求，主控端点可以发出“锁定”讯号以保留总线的使用权。在此注明，这些特性会应用在这篇论文所描述的简易总线测试装置。

主控端的读或写呼叫将启动数据传输的开始。呼叫参数为传递数据与目标地址。总线依照请求地址选择受控端点，将读／写呼叫传送给它。受控端可能需要数个频率来完成这个工作；每一个频率总线都需要检查呼叫状态，直到总线能够“示意”到主控端所发的需求讯息已经结束。同时，总线将新到的使用需求放置到排序序列当中。

当数个主控端发出总线使用需求时，仲裁装置将选择一个需求，而将其它的需求置放到排序序列当中。使用需求依照它们的优先级来执行，也就是有最高优先权的需求最先被执行。每一个主控端有它自己唯一的优先级。

讯号处理层功能呼叫描述了模块与总线间的接口。主控接口（master interface）定义了主控端与总线间的数据传递，而受控接口（slave interface）则定义受控端与总线间的数据传递。

简易总线的建立

所谓的简易总线，是建立成为阶层式（hierarchical）SystemC的信道。受控端与仲裁者也建立成为阶层式（hierarchical）SystemC信道。主控端有接脚可以连接到总线接口。总线以受控多重接脚连接受控端点，详见(图二)。

《图一 讯号接脚与接口符号》

我们使用特殊的符号代表讯号接脚与接口，如同(图一)所示，主控端M连接到总线。接脚符号包含两个箭头，分别指向左，右，而接口符号则有回馈箭头。讯号传输开始于主控端（右箭头）藉由讯号接脚连接到总线接口，从事功能呼叫。控制讯号以回馈箭头及主控端接脚的左箭头返回主控端。

《图二 简易总线图式》

每一个主控端包含一个于特定时间区隔内在指定地址读／写一些数据，而发出总线使用需求的程序。总线包含一个重新发出这些需求的处理程序。以这个例子来说，它假设主控端在频率的上升边缘发出总线使用需求，而总线处理这些需求在频率的下降边缘。

区块的读／写（Blocking Read/Write）

区块读／写功能传递在总线上区块间的数据数据。只有当数据传递完成时，功能呼叫才会结束。一旦主控端发出使用需求，只要使用需求状态表示不允许，功能呼叫将被阻挡下来。对线程处理程序来说（也就是，从线程处理程序中呼叫这个功能的主控端也如此运作），执行动作会以“wait( )”宣告来暂缓。方法处理程序的执行无法暂缓，因为“waits”并不被允许。功能呼叫必须立即结束，这与区块读／写接口规格相反。然而，藉由利用“next_trigger( )”功能呼叫[6]的动态感应功能，有可能获得类似的行为结果。

总线处理程序在频率落下的边缘启动。从堆积在排序列里未处理的使用需求中选择最适合的需求来执行。选择与使用需求讯号传递的地址相对应的受控端，与建立受控端接口呼叫。这种读／写呼叫会立即结束。总线处理程序会检查功能呼叫的结果。如果响应状态没有问题，它会结束这个使用需求，不然它就会将主控端的使用需求状态设定为等待（WAIT），这样它就必须在接下来的每一个总线活动中检查受控端的状态。只有在受控端的状态响应没有问题的情况下，时总线处理程序才能结束目前的使用需求。如果它是最后一笔需要处理的数据项，主控端需求结束，以及总线处理程序将为主控端区块功能产生一个事件讯息。如果有更多的数据项要被传送，主控端需求会以稍微修正的数据地址区间再次被排序。

非阻隔读／写（Non-blocking read/write）

当主控端发出非阻隔读／写功能呼叫时，功能呼叫将在总线需求表填入后立即结束。主控端则必需等待直到需求状态，也就是，呼叫状态变为没问题或有错误发生。这项检查发生在每一次上升频率边缘（静态感应列）触动主控端处理程序时。

这种读（或写）使用需求在下降频率边缘由总线处理程序执行。被指定位置的受控端可能需要数个频率周期来完成这个功能呼叫。在这段期间，总线不接受任何使用需求，但是必须一直等到功能呼叫结束。因此在每一次被触动时，它必须检查受控端读／写活动的状态。这与主控端处理程序相类似，只有现在它考虑到讯号处理层对受控端的呼叫。

直接读／写

当主控端在上升频率边缘发出直接读／写功能呼叫时，总线处理程序便会直接执行这个呼叫。选择地址数据对应到的受控端，以及呼叫相对的直接受控接口功能。这个功能也立即执行活动，因此可以产生内存数据马上读／写的结果；受控端的等待讯号则被忽略。所以，在不需要复杂的硬件／软件协同验证（HW/SW co-simulation）来设定的情况下，使软件侦错器在SystemC 覆盖的处理器模块（主控）顶层上动作并不困难。

受控端读／写接口

当受控端是没有等待状态时，完整的受控端功能性乃建立在接口功能的本身。受控端可能需要零个或多个频率周期来执行一个读或写的接口呼叫。对零“等待频率周期”而言，受控接口功能立即回复没问题的状态。对一个或多个“等待频率周期”而言，引发受控端功能呼叫的总线方式必须等待直到受控端状态响应没问题。这就像发生在主控处理程序中，非阻隔主控接口的功能呼叫。这里也一样藉由利用动态感应列机制，在数个“等待频率周期”之后通知总线操作已经完成来达到加速的目的。

仲裁者

所有主控端都能够彼此独立，而发出使用需求呼叫。所有接收到的使用需求呼叫都被置于排序列当中。如果总线准备要执行一个使用需求呼叫，最佳的选择会来自于排序列当中。如果排序列中只有一个使用需求，那这将是唯一的选择。对两个或更多个使用需求来说，就需要仲裁装置。每一个使用需求都有一个优先级的识别号码。这个号码愈低，优先级愈高。拥有最高优先权的使用需求呼叫，会最先从排序列中被选择出来。

使用需求可以是爆发性的读／写活动，在这里，众多数据项将被传递。一旦这样的使用需求被选择，第一笔数据项将被处理，以及使用需求将被放置回排序列当中，直到完整的数据项组传递完成。同时，如果有其它较高优先级的使用需求呼叫在排序列之中，这个使用需求将被选取，造成爆发式数据传递的中断。

如果排序列中包含一个有锁定设定的使用需求呼叫，这个使用需求只会在前一个被处理的使用需求有相同优先权时才会被选取。以这种方式，一个使用需求能够比拥有较高优先级的使用需求享有优先使用总线的等级。

实验结果

为了说明总线与其接口正确的操作行为，如同图二所示，产生一组测试数据。三种不同形式的主控端连接于总线，以及两种形式的内存也被连接作为受控端。仲裁装置同时也被连接。在特定的时间内，每一个主控端针对读写数据发出总线使用需求呼叫。第一个主控端利用非阻隔接口功能读写单笔数据；第二个主控端利用非阻隔接口功能的锁定模式读写数据串；第三个主控端利用区块接口功能移动整个区块的数据。而在受控端的内存，一个受控端需要一个频率周期完成操作，而另外一个受控端能够在频率为零点时就完成操作。主控端这样的设定方式，将使总线平均有大约百分之八十的时间都被占据使用。有时候，使用需求会在同一个时间发出，而仲裁器会选择一个最适合的使用需求呼叫。这样的设定结果显示在表一的第一行。

测试数据（testbench）（优化编译（-O3））

在107的仿真频率周期下执行不同处理程序。可以测量出所花的时间与计算出每秒的仿真周期数目。然而，执行时所用的CPU时钟速率，会影响到测试的结果。在这个例子里是利用1 GHz CPU的Linux机器来执行测试的工作。

藉由增加多个主控端与多个受控端来改变设定，不会降低多少仿真执行的速度。将主控端的数目加倍，以及／或是增加受控端的数量，降低少于百分之二十的仿真速度。

简易总线的建立是利用有动态感应列的线程处理程序。其它架构会是利用有动态感应列的方法处理程序。与线程处理程序相比较，方法处理程序有较快的仿真速度，因为在处理程序切换时管理的仿真核心较少。然而，建立方法处理程序比建立线程处理程序稍微复杂一点。为了简化起见，这个例子里只有使用线程处理程序。

结论

今日，在设计流程初期缺乏可执行平台模块，正成为系统单芯片设计中最大的障碍。利用SystemC的高效能仿真可及早获得可执行平台模块，而这些模块?对是易于使用的。抽象的适当运用使TLM平台模块加快执行速度，主要的关键在于抽象接口的使用、避免掉多余的处理程序活动，以及运用IMC结构。

（作者任职于新思科技德国分公司）

〈参考数据

[1] G. D‥omer and P. Gajski. System Design: A Practical Guide with SpecC. Kluwer Academic Publishers, 2001.

[2] L. Guerra, J. Fitzner, D. Talukdar, C. Schl‥ager, B. Tabbara, and V. Zivojnovic. Cycle and phase accurate dsp modeling and integration for hw/sw co-verification. Design Automation Conference, pages 964-969, 1999.

[3] M. Kawarabayashi, J.-Q. Lu, K. Goto, and P.W. Fung. System level design methodology for system on a chip. NEC Research & Development, 41（3）:248-252, July 2000.

[4] H. Kurokawa, H. Ikegami, H. Ryu, K. Nitta, and T. Kawatsu. C++ based system simulator for pre-verification of system-on-a-chip devices. NEC Research & Development, 41（3）:258-263, July 2000.

[5] K. Svarstad, N. Ben-Freduj, G. Nicolescu, and A. A. Jerraya. A higher level system communication model for object-oriented specification and design of embedded systems. In Proceedings of the Asia and South Pacific Design Automation Conference, Yokohama, Japan, Feb. 2001. IEEE.

[6] SystemC 2.0 functional specification and source code. available at: www.systemc.org.〉