电子系统级设计（ESL）所面临的挑战

一般而言，电子系统级设计（ESL）模型可分为Programmer View（PV）、Programmer View with Timing（PVT）、Cycle Accurate（CA）等不同层级。除了CA层级的设计验证可以沿用传统RTL除错（debug）概念：如在多设计语言（mixed-language）设计中作信号追踪，以及常以批次模式（batch mode）进行验证与除错之外；层级越高的模型，通常更着重在功能（functionality）和资讯交换（communication）的验证，一些不必要的细节通常会被忽略，因此，除错的方式也应有所不同。基本上，信号（signal）在ESL模型中是属于较低阶的资讯交换表现方式，在PVT或PV层级中，表现资讯交换的方式通常为transaction和 event；如图一所示：
　

图一

复杂的资讯交换与行为追踪
在现今的平台式（Platform-based）数字IC设计中，多个处理器的设计已是常态，其间资讯交换的复杂度更是提高了许多。除了传统同一层RTL或CA层的资讯交换外，关于其设计模型的行为追踪（trace）有着更复杂的问题，这些追踪可分为下列几种：

■水平追踪
追踪在不同bus上同一层级（PV，PVT）模型之间的资讯交换。在多处理器的架构中，处理器和处理器之间或处理器和周边的资讯交换，往往要经过许多层级的bus，再加上处理器经常运用pipeline的架构，追踪在某个bus上的一个传输；若要找出它是来自哪个处理器的哪个thread，而又和哪些传输有先后顺序的关系，是很难从原始码（source code）看出问题（如图二所示）。若有工具可在transaction和waveform的视窗上，在除错的时候，根据使用者的需求，将某个thread id或是某些属性（attribute），把不同bus上相关的读写传输明显标示出来，对实体工作上会有相当大的帮助。
　

图二
　

■垂直追踪
追踪相同bus上不同层级的资讯交换。不同层级间代表其资讯交换内容与细緻度不同，这通常需要一个transactor来建立不同层级间的关系。在这个追踪课题中，需要了解PVT层（较高层）中的某一transaction，是由其下面哪些信号基于何种规则（protocol）组合而成；在CA层（较低层）的某些信号变化属于PVT阶层的哪个transaction，若要工程师直接用肉眼从信号层去辨认上层的通信协定是很烦人的工作。如图三所示：
　

图三

程序同步问题的追踪与除错
除了资讯交换外，不同模组（module）之间通常会用程序（process）来做同步（synchronization）的控制。当程序间的同步出现问题时，有可能是某个程序未通知其他的程序，或某个程序没有接收到通知，甚至接收到的通知并非预期程序所产生…。譬如：当两个process存取同一块VGA的frame buffer时，write frame buffer的process必须等前一个display到萤幕的read process读完才能写，不然就会出现萤幕乱掉的情形。这时，就需要进行程序间同步问题的追踪与除错，常遇到的问题包括：

1. 如何写出（dump）程序的执行状态？
2. 当某个程序出现错误或该出现而没出现的时候，这个程序和事件，模组之间的关系为何？

在delta-cycle中，可能出现多个程序对同一资源写入状况的资料有误（这个资源可能是系统记忆体，全域变数，档案…），此时就需要探讨，到底造成问题的最后一个程序是哪一个？而这个程序又是否可预期？乃至于这个程序和其他程序或事件的关系等，可说是相当的复杂。

当delta-cycle出现多个程序对同一资源写入的状况时，对于模拟器来说，其值不应该由于执行的顺序不同而有所变化。若真的发生因为顺序不同而造成结果的差异，对于程式设计师来说，是一件非常头痛的事情，因为他们并无法真正了解模拟器在这delta-cycle中发生了什么事，甚至不知道会发生这种违背规则的错误，若无模拟器的检查和告知，这种除错势必很难发现和解决。

除了debug之外，如何更有效率的验证以节省时间，对系统验证也非常重要。因为 系统上的验证更加复杂，像是不同的应用程式对不同的主要IP进行随机测试（random test）。常发生的状况是在OS开机成功之后，先后挂上视频和音频的标准检查程式（benchmark）来做随机测试（random test），而每次都需要从头开始跑是非常耗时的。（如表一:不同阶层在linux上所需的开机时间）因此，若能将开机成功的状态储存起来，再挂上不同的标准检查程式，势必可以节省好几个小时甚至数十小时的时间。
　

表一: Oleg Petlin, Wilson Snyder, “Functional Verification of the SiCortex Multiprocessor System-on-a-Chip”, in the 44th DAC, June 2007
ps： Beh means Behavior
　

另外，对包含各个层级的设计验证来说，一旦验证结果发现有bug存在，也必须从头开始模拟，以复制错误产生状况进行除错，可能要耗费数小时到数十小时不等，这也是令人头痛的问题。

新旧IP工具与验证模拟
在系统级的设计验证中，常有许多用Verilog，VHDL所写的旧IP，而新的IP则往往可能会用SystemC来撰写，以达到快速验证的目标。但是这些新旧IP混用市面上的多语言混合模拟器，其进行模拟的结果，往往比纯粹用SystemC的时间慢许多，主要是因为两个不同模拟器需要一定的互动沟通，比起把这些事件放在单一个模拟器来模拟，自然是慢很多。由图X的比较中我们可以发现，以同一设计运用不同模拟环境进行的结果来看，纯SystemC的速度要比SystemC + Verilog的速度快三倍以上。如表二所示：
　

表二: The Study on the Behavioral Model of IEEE 802。3 MAC Using SystemC Language
　

当系统层级越往上提升时，模拟速度就会更快速，如表三所示（在表三中的Architecture View（AV）指的是比CA高一点层级的cycle-approximate）。 Architecture View （AV）层级会比RTL快18倍；而PV层级会比RTL快500多倍。
　

Model Benchmark Dhrystone（7 stage， 32-bit RISC Processor） Cjpeg（Jpeg Compression） Djpeg（Jpeg Decompression ）Synthesizable RTL 1x 1x 1xArchitecture View 18x 18x 19xProgrammer’s View 509x 504x 521x

表三 : Realtek,“Microprocessor Modeling and Simulation with SystemC”in VLSI-DAT, 2007

结论
 由以上列出的问题，我们可以了解在ESL所遇到的硬件除错问题，包含了：

1. 追踪硬件各个不同层级的资讯交换。
2. 程序错误所造成的问题：资源竞争（resource racing），信息竞争（message racing）， 死结（deadlock），活结（livelock）…。
3. 模拟时间或重复复制错误的时间过长。

除了硬件相关的问题外，软件和硬件的除错更是复杂：

1. 当有错误发生时，如何暂停（break）在软件某一点，追踪软件和硬件资讯交换之间的关系？
2. 当停在软件的某一点，如何让其他处理器继续跑或是停下来？
3. 如何分析硬件资源应用是否最佳化？经由软件工程师或编译器产生的threads是否能将硬件资源充分应用？
4. 根据不同的应用，如何在价格、速度、省电上快速抉择，并用于软硬件系统的架构上？

因此，在ESL的工作中，好的除错与分析软件扮演着举足轻重的脚色！