嵌入式硬件和软件设计工具的优缺点，通常建立在设计者对于IP能否有完整的掌握度和能见度，以及在开始设计的时候，这些IP是否能够被完整的取得。本文将探讨SoC的系统模型是如何设计和如何提供附加价值给软件开发者，并提供早期的虚拟原型（prototype），使IP更弹性的嵌入到设计工具中。

系统层级设计和模型

自从半导体理论上可以将整个系统整合到单一模型之中时，IP设计公司已经达到平台式设计的一个新纪元，并且鼓吹此种设计趋势多年。但迄今为何尚未见到以平台为基础设计IP的大流行呢？其关键就在于平台的范围不够大。现阶段只有包括系统层级的设计（system-level design；SLD），这包括：RTL硬件定义、BUS架构、电源管理策略、设备驱动器、操作系统通讯端口和应用软件。

而研发成功关键在于一个平台仍须可区分差异性的必要元素，这包括先进的系统模型和验证环境。开发者需要来自RTL、系统模型、软件开发模型和真正的硬件开发主板所提供的完整平台。

平台的每个部份都对应到相同的系统架构，设计者在任何高阶的地方都可使用测试软件来做验证。在这个环境下，方便求出系统的带宽和性能需求。系统规模一定要能够扩展，允许设计者充分利用既有且经检验过的硬件IP和软件IP之外，亦能利用自行研发的IP，来设计自己独具的应用功能。而每个设计工作都有不同的方法需求，SoC设计者需要在每个设计时间扩增IP，举例如(表一)。

在系统层级中，软件的必需性相对重要，在过去要求软件开发人员花费时间等待原型系统完成，不甚合理。软硬件同步验证能够缩短整合的时间，纵使如过去一样，提前到RTL设计完成时，开始进行同步验证，仍然会延误软件的整合，因为大多数硬件设计已完成，并无法更改。此时系统和软件设计者仍然缺乏共同的环境。

新一代解决方法为，首先使用SystemC定义系统，规划设计流程，然后区分硬件和软件区块，并交给不同的软硬件小组。此对软硬件系统整合而言，是一个重大突破。软件工程师不仅拥有一个平台可发展其软件，亦拥有一个C++虚拟环境，可重复使用既有的链接库。

系统层级的抽象描述

定义任何新系统，从定义正式的规格到最后制成硅芯片和软件执行档（image），通常使用不同的抽象层来描述。共有五个抽象层用来涵盖一个完整的系统。系统功能描述越详细，产生的硬件功能越能满足需求。这些抽象层与OSCI（Open SystemC Initiative）的技术提案有许多相似之处，其中不同之处，如(图一)所示。

《图一 SoC设计的五个抽象层》

在(图一)中，平台设计的RT抽象层是用蓝色描述，在这个层级上使用的语言是VHDL和Verilog，用以实现硬件。在RT层上方显示的是交易层（transaction level），在此抽象层中，对共通开放标准的落实提供一种语言模型，主要是SytemC。平台模型本身可能使用对内核心仿真上更具效率的特殊模型格式（非SystemC），但是它们皆可以透过接口连接到SystemC的仿真核心。

在抽象的系统模型环境中﹐一定要支持下述的三个抽象层：

在系统层级建模的方法

没有一种方法能完全适用于所有的系统，但是上述的抽象层方法对于一个系统的不同表示已尽可能达到。一个系统要在哪一个抽象层被实现，大部份是由系统设计者对此系统架构的信心，以及针对特殊的算法开发出新架构的可行性而定。

对一个已知架构的系统，其中的实现细节，例如：不同总线的性能，并不为常人所知，下述方法可被利用。业界早已关注此方法，该方法是由RTL设计自然演进而来，而且硬件设计师对模型环境特别放心。

使用该方法，系统设计者能够容易地将软件和硬件区分。并且能够从CC抽象层开始，对系统的性能做深入的调查。虽然算法设计工具可能无法以正规方式获取所需的规格，然而AL的主要任务并不一定是描述系统，因此算法超出在系统层级使用IP来设计的讨论范围之外，在此将不涉及算法设计工具。

微结构的设计

在CC层级建立系统模型，能够让设计者藉由粹取信号层级的细节内容导入每个交易中，因而能更有效率建立系统架构模型中每一细微部份。对一个完整的系统仿真，利用诸如SystemC这样的建模语言和抽象技术，可以达到10～100KHz的速率。从单一的总线传输周期到一整个总线通讯协议周期，针对每一个频率周期（cycle-by- cycle）CC层级都提供映像。在这个环境下，结合一些高价值的IP模型，并在单一周期到一整个通讯协议周期中，减少一些信号事件，这使仿真效率提高，处理速度可以加快。

通讯架构是由三个基本模型构成的：阶级化的信道模型，负责管理每个组件的连接状态；仲裁者，负责接受请求，并按照请求者的优先级分配信道资源；译码器，负责将地址译码，进入特定的连接区段（传入或送出）。仲裁者和译码器本身虽然是硬件，但一般是希望能用SystemC模块来建立其模型，且每个SystemC模块之间是由单一接口相通。

此系统的主宰者（host）可能是处理器模型或内存控制器，而从属者（slave）可能是接口设备，例如：UART。主宰者是频率模型，它产生数据结构形成总线的交易内容；处理器传送这些数据到总线。从属者也是频率模型，它被总线驱动，接受由总线传来的数据结构，并处理之。

此方法的重要部份是：转换到RTL设计的能力和对整个系统保有一个验证的基础。利用SystemC模型的CC接口，可以进入RTL模型。以ARM为例，在SystemC模型中已经存在一个AHB总线之间交易的映像，和一个AHB硬件的各种信号，这个接口通常是通用型的（generic），并保证装置能正确运作。

软件的实现

微架构的主要优点是能够将它当作韧体和中间软件（middleware）的开发雏型（prototype）。一般而言，这是属于指令集仿真（instruction set simulation；ISS）的范畴，但是在复杂的装置里面，软件和硬件之间存在着实时的互动关系，很难利用ISS技术来观察。典型的现代ISS包括简单的周边装置之架构模型，它们在PV抽象层上操作，因此无法提供真实的系统层级信息。

随着硬件和软件复杂性的增加，一个可替代ISS的技术逐渐流行，即利用FPGA来建立系统原型。这些工具可在真正的硬件上高速地执行软件，通常允许硬件装置，例如：网络装置，彼此相互连接，传输真正的数据。针对正在目标板中执行的软件，软件开发者使用硬件除错和追踪工具，就能够得到绝佳的侦错能见度。当软件开发者需要针对与操作系统紧密相关韧体做除错时，则除错工具必须提出操作系统的现况信息，并提供操作系统层级的原始信息，例如：线程（thread）和号志（semaphore）等。

然而，这种原型系统的基本缺点是，在需要许多软件工程师一起开发时，是很昂贵的。并且当硬件广泛地完成后，软件在开发周期上相对比较缓慢。和传统的软件开发工具相比较，在CC抽象层上建立系统模型不失为一个好方法，其优点有：@內標:(1)用来开发硬件微架构的工具，提供一个早期的系统原型，可执行完整的系统软件。

(2)和软件模型一样，虚拟的原型能提供给许多软件工程师使用。

(3)在CC层级上可以达到100KHz的速度，通常这对低阶软件开发是适合的，并且对于大型的开发，譬如操作系统的启动（bring-up）也是适用的。

IP模型

对一个完整的系统仿真而言，想要能够达到100KHz的速度，高质量IP模型是重要关键。业界已将SystemC当成系统层级的建模语言，现在的IP供货商已能提供标准模型给使用多种不同EDA工具的设计者。使设计者能够结合最好的模型与最好的工具。

以ARM为例，它的微架构SystemC模型如(图二)所示，ARM RealView模型链接库结合ARM周期呼叫模型技术和最新的AMBA AHB周期层级接口（AHBCLI）

和ARM RealView除错器。AHBCLI允许设计者在CC抽象层上建立完整的AHB模型，同时确保能完全遵守AHB通讯协议。

《图二 ARM的微架构》

依据AHBCLI建模，界于ARM核心模型和AHB总线架构之间的传输完全是周期精确（cyclic-accurate）的，ARM核心模型和总线架构都是以共同的系统频率来计时。AHBCLI可以将周期频率映像到实际的电路转换成接脚（pins），故允许RTL SystemC模型的直接连接，或可以和硬件描述语言（HDL）或逻辑闸模型一起仿真。这工具提供下列优点：

(1)验证SystemC模型时，能够对RTL周期性的检验。这对由上而下的设计方法是必需的。它亦支持由下而上的自动产生系统，这可由HDL-SystemC模型中自动抽取出来。

(2)能够混合各种不同层级的模型。例如，将一个新功能区块的系统层级模型置于RTL- SC（SystemC）中「精炼」，同时维持系统的其它高层级和快速模型不变。此在「单元替换（unit-substitution）」的验证方法中是很重要的。

(3)对ARM和AMBA用户而言为简单之事，实因接口的内涵容易映像到真正的硬件上。

架构的探索和开发

虚拟系统的原型

在(图三)中，PV抽象层的输出是一个虚拟系统的原型。它完整地将系统的功能模型化，而且针对一个软件应用，提供程序设计者所必需的硬件。为达到这个目标，装置的整个硬件功能都要在PV层上被仿真出来。

功能区块设计的一重要因素是接口的设计：在一个系统中的组件要如何与其他组件沟通。在PV系统模型化中，一系统仅由一群IP组件组合成的。在这个抽象层上，设计者唯一关心的是哪些组件是需要沟通，而不是何时沟通（虽然排序亦很重要）。为了确保只有系统的功能，而不是实时数据（timing critical data）被包含在这个虚拟原型中，有关系统中每个装置的时间响应信息，不应该由软件程序设计者来决定。

《图三 SoC设计流程》

主宰者模块（master module）可能对系统频率很敏感，或对系统的其他任何事件很敏感。但是设计者必须了解：时间准确的观念是无法维持的。因此一旦启动一个程序（process），大量工作可能将会被执行。PV抽象层提供设计者所需的工作时间最小单位（granularity size）的提示，大约是数个频率周期。一个PV模型必须尽全力符合这个最小时间单位，而不会在计算已经过去的周期数量上，花费任何重大成本。

对于从属模块，一般的期望是：它的传输功能必须立即传回（return）数据结构，在此数据结构中包含着任何回传的数据。并不期望它对任何事件敏感，或真正产生任何事件。

因为硬件架构的功能是在系统层级（SystemC）完成的，它必须和系统的环境模型（例如：虚拟面板）结合，为软件开发提供一个系统原型。然后，软件的实作就能在一个完整的系统环境中被检验。而且也可以同时在硬件空间中，进行标的比较（benchmarking）和硬件实作。

系统的性能模型

除了验证新架构的功能外，架构设计者需事先了解此架构被实现后的表现如何。新技术藉此功能模型利用时序信息来描述，并对系统中的每一个组件提供性能数据。当每一个时序模型通讯时，这些信息可以被收集和对照，如此一完整的系统性能就可以获得。PVT方法被用来开发系统性能模型，因为其为PV模型的延伸。因此时序和PV无关。由PV建构的系统性能模型在功能上是正确的。PVT不添加任何需要被传输的数据，而只提供数据何时要被传输的额外信息。

PV和PVT之间的不同，可以从AMBA通讯协议中看出来。PV抽象接口层将AHB-Lite看成地址、数据、保护信息、讯爆（burst）长度的组合。AHB-Lite的时序通讯协议是由HREADY信号来描述。在AXI通讯协议中，程序设计者心中的系统架构没有改变，但是接口的时序问题变得更复杂，并且需要引用额外的时序来描述此通讯协议（AREADY、AVALID、RREADY、RVALID、WREADY、WVALID、BREADY、BVALID）。

在系统中，复杂的时序模块可能含有对频率边缘（clock edges）或其他事件敏感的元素。这些时序和与它们通讯的功能对象，完全交由IP设计者针对每个组件逐一解决。当传输作业已经在某组件的接口上进行时，此通讯将会通知该传输组件上的时序模块，和与它们相关的内部状态之重要变化。

该层级的模型化将提供一个机制，藉此时序模块和系统频率之间能彼此同步。这与周期呼叫模型的输入和输出相似，唯一不同是没有传送数据。在一个CC模型中，数据是在指定的时间内传送。在一个PVT模型中，数据已经由PV模型送出，在数据被送出的时间点上，即由时序模块负责管理输入和输出作业。为便利设计，一般希望PVT时序模型的范例和CC抽象层是相同的。

IP模型的范例

如同CC模型一样，高质量的IP模型也需要确定能够达到PV和PVT的性能目标。PV抽象层的点对点传输通讯协议结合高速模型，目前约可达1MHz的速度。这对大多数的软件开发而言是足够，但是应用软件通常需要更高的速度。这需要更新的模型，但是在业界公认的SystemC环境里，目前还没有这种模型出现。

(图四)是ARM架构SystemC模型，包含ARM RealView模型链接库、ARM ISS技术整合高效率的点对点接口。在PV抽象层上的接口标准定义现在正由OSCI的TLM工作小组拟定中。

在此系统中，模型之间的传输是点对点。ARM核心模型的内存接口是透过一个SystemC通讯端口将交易内容直接传输到总线目标系统的接口上。当一笔交易从DMA控制器经由一个具单一传输功能（Rx FIFO）的内存，传送到系统的主存储器时，DMA控制器将「拦阻（block）」其它传输作业，直到此传送作业完成，且内存传回数据为止。

结语

因为SystemC的发明，SoC的设计已进入群雄竞逐的阶段。虽然OSCI所制定的标准，目前尚未被任何一个正式的国际组织所承认和采用，但是它已俨然成为业界事实上的（de facto）标准。

国内设计16-bit以上SoC的公司目前都面临着软件开发困难的苦恼，本文所介绍的系统层级设计方法将是解决此问题的方法。

《图四 ARM架构SystemC模型》