SoC是IC设计的现在进行式

对于消费者而言，SoC设计方式的好处在于整合多颗晶片之功能至单一晶片，使产品更符合低功率消耗与缩小产品体积的需求；对于生产业者而言，藉由晶片制程上的进步，将数颗晶片整合至单一晶片将大幅节省晶片制作成本，使得该晶片更具经济效益与竞争力，所以，SoC的设计方式为目前晶片设计不二法门。

然而，对晶片设计师来说，无论是业者或者学界皆发现发展SoC的挑战其实很高，除了要将数颗晶片功能整合至单一晶片时要考量的功能复杂度，还有许多采用SoC设计方式时所需付出的风险与代价，都必须考虑在内，以下将列出数点主要的问题。

开发时程考量

在传统的晶片设计?程上，软体工程师必须等到硬体工程师提供硬体系统的样本后，才能开始着手设计，这样将延迟软体设计的时间，不符合有效人力资源分配原则。

软硬体共同设计、验证的重要性

若只有设计该晶片的硬体工程师在早期独立工作，除了有时程上的问题，常遇到的问题还有对于只有硬体工程师根据经验法则所规划出来的整体系统架构，软体工程师的设计往往会陷进这些样本的框架中，造成无法对整体系统做出最佳化的困境。于是在各项成本考?下，软体工程师只好牺牲效能做为妥协，当情况严重的话，如在晶片设计开发后期才发现其晶片不符合设计规格要求或设计功能错误而导致系统因软硬体无法配合，这将使得该系统整体必须重新开发甚至于直接宣告失败。

开发成本考量

既然在系统级晶片复杂度如此之高，晶片设计业者为了确保开发的晶片符合需求，常会借助于FPGA帮助验证，但由于FPGA本身的物理限制造成无法完整表达系统所有的功能，当然也就无法验证其功能是否正确或者其演算法是否合乎需求。再者，由于高阶的FPGA单价昂贵，若想要比较众多不同系统架构下的系统效能，开发者可能要分段验证或者所费不赀地支付高额的FPGA材料费。这些环境因素都会局限设计者的做法导致原本的想法无法实现。

虚拟平台采用ESL Design设计方式协助SoC开发

对于开发SoC来说，上述的问题常常造成开发晶片失败，或是开发的时间过长。为了解决上述的种种问题与现象，学者开始提出一种名为「电子系统级设计」（Electronics System Level Design；ESL Design）的方法学（Methodology）去建构一系统级的软硬体共同设计虚拟平台。这个方法学是利用高阶语言的抽象化的功能，将设计者所想要验证的电路以模型化的形式包装，并且提出为了要符合模拟硬体电路动作必须加入共同式电路行为模拟功能（Concurrent Behavior Simulation）。由于整个系统采取由软体建构方式，所以把实现的系统称之虚拟平台，当虚拟平台建构出来后，软硬工程师们就能在这个平台上共同开发系统，并在短时间内方便地即建造多种系统模型找寻合适的系统架构。由于系统模型可以被虚构出来，对于许多本来不易建构的实体模型将能在低成本的方式下建立，所以软硬体工程们能在早期即能完成系统晶片功能性上的验证，这将大幅缩短晶片开发时程，解决软硬体共同设计、验证时的需求、符合兼具低成本与高弹性度的设计方式。

现有的虚拟平台产品的限制

由于ESL Design Methodology兼具如此多的优点，所以市面上有许多的公司都积极地开发这类型的软体，举例如说，如ARM SoC Designer、CoWare Platform Architecture都是解决上述问题的商业产品。但这些公司常基于商业考?与保护，造成工程师无法修改软硬体元件的原始码?符合特定的设计并探?系统的可调性，因此造成在做跨平台的工具整合时的发生?多困扰。此外，在学术上常使用的系统级模拟工具「QEMU」，由于无法任意?动硬体模型设定或变?系统架构，只能提供「软体工程师」一个固定的系统平台，无法透过不同的系统架构测试，让整体系统达到最佳化的设计。

建立属于您的虚拟平台

踏出建置虚拟平台的第一步：开发软体的取得（SystemC）

针对这个问题，目前有许多免费的开发软体可供使用，其中最著名的为OSCI（Open SystemC Initiative）构机发展的SystemC，它提供类似硬体描述语言的模拟功能，除此之外，它的核心是由c++所建构而成，并且开发的语法与c++非常类似，对于软硬体的开发来说，它既可以使用高抽象化的模拟方式建造系统模型，也可以采取低抽象化的模拟方式验证系统中电路中的低阶行为特性（例如时脉误差所导致的电路行为，汇流排拥塞现象等）。由于OSCI是非营利组织，所有人皆可免费地从网路上下载原始码（Source Code）。由于这个原始码是开放性且相容于Linux与Windows两大作业系统，使用者可以任意修改想要改良的地方，所以广体许多的系统开发者所喜爱，有兴趣的读者可以参考网站：http ://www.systemc.org/home。

建置虚拟平台时的核心概念（一）：系统模型的抽象化程度

如同前面提到的，虚拟平台的建构目的是模拟系统运作，所以模拟速度将是考量的重点，而影响模拟速度最主要的因素来自于物体抽象化程度，高抽象化模拟是表达物体的功能或演算法，忽略系统各功能模型间沟通时繁杂的交握讯号状态，所以模拟速度较高，但对于时间上的精确度则较低；反之，低抽象化模拟如同之前所提，是模拟系统中电路的低阶行为特性，针对在时脉准确度下的电路行为做解析，相较于高抽象化模拟来说需要考量较多次的同步行为，在相同时间单位下，能够模拟的指令则较少，所以模拟速度相对为低。

建置虚拟平台时的核心概念（二）：采用有利的资讯交换方式（Transaction-Level-Modeling；TLM）

系统的模拟速度除了取决于抽象化程度外，另一方面取决于各功能模型间资讯的交换的频率，由于模型的资讯交换会有讯号同步或交握情况，对于模拟器来说在相同时间单位下，资讯交换的频率愈高则代表要代出愈高的资讯交换（Content Switching）代价。

为了解决这个无法避免的问题，则必须采用对于交换资讯较佳的模拟方式提升模拟的速度，这种模拟方式通常有两种做法可供参考，第一为减少资讯交换的频率，因为ESL模型所建立的系统是由软体所构成，所以方便大量采用function calls并夹带必要的参数变数将所需交换资讯透过『交易』（Transaction）用最少次传输的方式完成，这样的做法虽然会?牲交握讯号时序的准确度，但却能大幅增进模拟速度，然而，有关准确度与模拟速度之间的抉择，则是得由使用者依据当时状况的需求​​做判断。

第二为采用软体工程中常介绍的方法指标传递（Transfer-by-P​​ointer），由于使用软体模拟交易的过程，常用到的方法是将欲传递物件（Object）资讯拷贝一份给对方，可以预想若有许多接收的模型或者是欲传递物品的资讯量很大时，采用资讯拷贝的将要付出相当大的代价（较多的时间与记忆体），对于这种状况，工程师们常用指标传递做有效率的处理，虽然指标传递的方式很有效率，但这种做法对于硬体模拟将可能产生资料一致性的问题，这个问题将在本文中「虚拟平台的问题与挑战」有较完整的介绍讨论。

目前所要关心的是上述的主要两个问题将会伴随着系统建置愈大而愈明显，这点专家学者们也注意到这个问题，所以提出了一些参考的方法，以OSCI为例，它提供了Transaction Level Modeling（TLM）的程式库（SystemC extension library），这个程式库提供许多的函式呼叫元件对应于不同的传输方式，但是这些元件的共通点都是让各硬体模型间免除繁琐的?辑电?沟通讯号增进传输效率，并且元件皆透过函式呼叫（Function Call）方式，搭配两种资料传递方式（Transfer-by-Value or Transfer-by-P​​ointer）供使用者自由选择以达到最有效?的资?传输；相较于目前大多数的硬体描述语言皆是以观测模型间讯号变的模式以达到交换资讯的目的，TLM模拟方式将能大幅改善模拟的速?，有效的帮助系统开发者?使系统级的大?模拟，有兴趣的读者可以参考网站http://www.systemc.org/downloads/standards/tlm20/。

用虚拟平台开发一个嵌入式系统的实例

在介绍了许多有关虚拟平台建置的观念后，接下来将以本实验室团队（http://dvlab.ee.ntu.edu.tw）所建置的虚拟平台（Qute Virtual Platform；QuteVP）为实际范例，分享我们的实际经验，并探讨建置过程所遇到的问题与挑战。

处理器模型的建置

这个虚拟平台目前提供了以ARM v5Te处理器（ARM 9 & 11相容）模型为核心的完整系统设计架构，如图一，并且使用SystemC语言所撰写的指令集处理器模型（Instruction Set Architecture；ISA ）。除了支援ARM 9/11所有的指令之外，因其高抽象阶层的描述特性，与传统暂存器转换层的周期正确性模型相较，拥有绝对的模拟执行速度的优势。

《图一 QVP系统架构图》

周边模型的建置

此虚拟平台其中亦包含了要安装作业系统所需要的周边模型，如：计时器模型（Timer Controller）、中断控制器模型（Interrupt Controller）、直接式记忆体存取控制器模型（Direct Memory Access Controller ）等，所以该虚拟平台其实已为使用者做好「作业系统」移植的准备，让使用者拥有更多的时间专注于软体程式或系统架构的开发。

快速扩充系统模型的样本

有关系统扩充性的方面，本虚拟平台提供一组Wrapper Class，可透过物件导向程式语言的继承方式，简单地完成硬体模型的Bus Functional Wrapper，让使用者能方便地自行建构各类硬体模型于平台的系统上，因此提高了矽智财的重复利用性（IP Reuse）。在此种模型的计算与通讯分离设计（Computation-Communication Separation）下，各类硬体模型更可透过只抽换Wrapper Class，便可以在沟通的行为模式上达到不同阶层的模拟。

模型间的沟通方式

有关模型间传输的部份，本虚拟平台采用Transaction Level Modeling（TLM)做为硬体模型间沟通的行为模式，加速彼此的讯息传输。由于采用TLM的行为模式，让各硬体模型间免除繁琐的逻辑电路沟通讯号，使用者也可搭配使用不同的资料传递方式配合函式呼叫（Function Call）的方式进行有效率的资料传输。此外，我们也提出了一个考虑传输资料相依性的模拟加速演算法，利用虚拟同步（virtual synchronization）的机制，将SystemC模拟核心引擎在做context switch的overhead由原先占整个模拟将近90％的时间，大大的降低到1％左右，详细的演算法请见我们今年在International SoC Design Conference（ISoCC）所发表的文章。

应用软体开发与效能评估

关于产品开发应用的部份，本虚拟平台接受由ARM Compiler、Linker编译、连结后的无格式二进制文件（Plain Binary File），并透过指令输入介面，让软体工程师选择欲测试的执行档。免除传统流程中，软体工程师将执行档烧录于相对应的唯读记忆体（ROM）时，所需的一连串繁杂程序，提供系统开发时的便利度。除此之外，在执行系统模拟时，本虚拟平台可以自动记录在BUS上所有的传输过程，例如：封包传送时间、封包传送个数、系统模型使用率（如指令的执行总数、记忆体最大使用量等）之相关资讯，并在软体程式执行结束后，自动储存为文字档案，供使用者参考。有关系统评估的部分，本平台亦提供一个基础的工具程式让使用者可依照自己的需求稍做修正以达到各项的系统评估。目前此虚拟平台的模拟速率在一般的Linux工作站上可达3.66MIPs（million instructions per second）。

虚拟平台的问题与挑战

前面介绍了虚拟平台建置的方法与范例，接下来要讨论的是如何在真实生活中实现建置好的虚拟平台，这是一个目前许多学者、专家、业者们都还没有一个统筹式解决方案，甚至有些问题都还未被挖掘出来，所以接下来，本文将归纳三个在建置与实现虚拟平台时遭遇到问题与期待解决的问题。

将抽象化的模型具体化

抽象化的用法与所带来的优缺点在面的文章中已被提及，所以这里要做的是更进一步讨论实现抽象化模型时的困难与挑战。其实，将抽象化的模型转换成实体的电路早在硬体描述语言的合成流程（Synthesis Flow）中行之有年，当年成功的经验在于业者们对于该语言语义解析有统一的标准方式，并且这些硬体描述语言的语法被区分成可合成与不可合成的部份，所以工程师们可以轻松分辨并且使用它们。

相较于虚拟平台所采用的语言则无法完全采用上述的方式解决，以SystemC为例，由于使用者常为了提升模拟速度而采取高抽象方式模拟，可是高抽象的描述物体方式带给编译器辨认语义时极高的复杂度，这个现象，造成编译器区分可合成电路与不可合成电路时的困难，如果要解决这个问题，通常需要使用者自己增加或者删减编译器对于该语法上的辨认条件，然而，这个步骤无形中却增加了使用者的负担，甚至带来人为错误判断条件的风险，这点是学者专家们常常提及从虚拟平台至实体电路想要解决的主要问题。依照经验来说，使用者必须在建置抽象化模型时考虑该模型的用途，一旦决定要建立的为可实现化的虚拟平台时，则采用的抽象层次可能就不能太高亦或者必须定义高低不同抽象层中相对应模型的电路功能、电路讯号、电气特性等关系。

指标问题

指标通常对于软体最大的贡献在于分享一个物件所拥有的内容，而且透过对指标的运算，使用者可以从一大群资料中挑选到所需要的资料，这种方式将节省许多软体工程上的资料拷贝时间与免除不必要的资讯交握讯号，所以增进了电脑模拟效能，但若把这个特性用于硬体模拟则可能导致资料不一致的问题，试想，若有二个模型同时内皆使用指标指定至相同记忆体位址并使用该记忆体所分享物件的内容，一旦有任何一模型更改记忆体位址内的内容，将可能对另一个模型造成资料存取错误的状况而导致不可预期的后果。

为了修正这个问题，使用者必须在传递资料或使用资料时注意资料一致性的问题，所以在撰写程式码甚至得加上锁（Lock）或门闩器（Semaphore）等同步元件，这样的做法也会造成使用者的负担而且降低模拟速度。

验证问题

验证对于虚拟平台的挑战不在于只是确认功能性是否正确，它还包括了系统架构是否合适，因为采用适当的架构才能达到高效能、低功率消耗的要求，但对于验证什么是最合适的架构而言是相当困难的，常见的两种验证方式：模拟方式（Simulation-Based method）对于众多系统级的架构模拟验证需要用到大量的时间；正规方法方式（ Formal Verification-based method）则是需要将抽象化的模型再次用正规语言转换、描述，所以，困难点不仅在于描述方式的转换，还包括无法明白知道要验证的项目有多少与用何种正规方法才是最有效率的验证方法，所以对虚拟平台的验证来说，还有非常多的部份值得研究、探索。

虚拟平台的高投资报酬率

虽然建置虚拟平台以发展SoC存在许多的困难，但是它的投资报酬却相当地高，除了前面所提及的高弹性度的设计方式、低开发成本外，专家学者们认为虚拟平台的可重覆利用性很好，因为，一旦虚拟平台建置完成后，往后要再开发新的系统都可以仿照原先虚拟平台的建置方式，甚至只需要像堆积积木一样的方式抽换或增减所需要的功能模型即可，所以对于产品时程（Time-to-Market）而言将更显其竞争力。另外，从现在就投入虚拟平台建置以开发系统级晶片就如同在1990年代就开始接受SoC设计方式一样，因为这种设计方法学是一种设计上的趋势，所以善加利用虚拟平台，将带领工程师们能够面对更高、更严峻的挑战，创造出更大的晶片设计价值。

---作者叶昱甫为台大电子所博士班学生、黄钟扬为台大电子所助理教授；两人亦是台大电子所设计验证实验室成员---