1.简介
在过去的十年中，无处不在的嵌入式系统引起了研究人员的注意。典型的嵌入式应用，从复杂的飞机飞行控制器到简单的数码相机，都需要对它们的定时性能做出最坏的保证，因此被称为实时系统。实时系统设计的标准方法依赖于静态地确定代码的执行时间，这个过程称为最坏情况执行时间(WCET)分析[22]。WCET分析用于确定任务周期和最后期限。然后使用RTOS模拟任务的并发性，并使用互斥锁和监视器等机制实现任务同步。这种方法有几个限制，包括确定严格的WCET界限的问题。本节首先区分WCET和WCRT分析。
WCET分析是确定在传统处理器上执行的给定程序中最坏延迟路径的过程。通过静态分析估计给定程序的WCET是一个非常复杂的过程，因为工具必须静态地探索程序的所有执行路径。推测性的处理器增加了这种复杂性，因此工具也必须考虑底层架构。Wilhelmet等人的[22]为这种分析给出了详细的调查方法。由于工具常常依赖于抽象，从而导致高估。
对于以离散瞬间执行的同步程序，分析要简单得多。同步程序使用全局时钟的节拍执行。在每个瞬间，来自环境的输入被采样和锁定。然后调用反应函数来进行所需的计算。最后，将该函数生成的输出发送给环境。因此，瞬间的长度取决于程序执行过程中最长反应的长度。这个任务被称为WCRT或最坏情况反应时间分析[5]。
KEP系列反应型处理器[13]以可预测的时间执行Esterel程序。他们通过将处理器上的节拍长度固定在静态分析得到的WCRT值上来实现这一点。或者，在“自由运行模式”中，每一次滴答将尽可能快地完成，这可以减少平均情况下的反应时间，但代价是降低可预测性。Boldt at al.[5]开发了单线程Esterel程序的WCRT分析方法，该方法在不同类型的KEP汇编图(KAG)节点上使用结构归纳。随后，他们将这种方法扩展到在KEP3a处理器[5]上执行的多线程Esterel程序。该算法通过深度优先搜索在称为CKAG (Concurrent KEP Assembler graph)的中间图格式上分析最坏的节拍长度。该算法计算每个线程的最大滴答长度，然后整个滴答长度就是这些最大滴答长度的总和(我们将这个值称为程序的WCRTmax)。因此，这种方法将导致对WCRT的过高估计，并通过在Estbench[8]程序上的实验建立WCRT。估计的WCRT平均高估了40%的[5]。最近在[10]中提出了一种获得更精确值的方法。这里，Esterel程序首先使用CEC编译器映射到C，然后开发一个ILP公式来消除代码中的冗余路径，从而产生更准确的结果。类似地，[5]的方法在[16]中进行了扩展，使用代数框架进行更精确的WCRT分析，从而消除了冗余路径。
同步程序可以使用变量刻度[19]的概念来执行，以牺牲可预测的执行来促进良好的平均用例性能。但是，对于实时系统，我们必须执行一个具有固定节拍长度的同步程序，这样就不可能出现计时错误。我们称这个刻度长度的精确值为，以表明在程序执行期间，小于这个长度的任何值都可能出现计时错误。为WCRT计算一个最优值将为设计精确定时机器(PRET)[9]铺平道路，这些机器最近被提出作为实时计算的替代架构。PRET机器要求体系结构在不牺牲吞吐量的情况下保证精确的定时。PRET机器的另一个隐含目标是促进并发C代码的可预测执行。为此，我们提出了一个对C的同步扩展，称为PRET-C，然后开发了一种方法，对在通用处理器上执行的PRET-C程序进行严格的WCRT分析，只需要进行最少的定制。
我们注意到，同步程序(如Esterel)的整体紧凑WCRT不一定是线程上的最大值之和，而是程序所有可能执行的局部瞬间(我们称之为局部滴滴)之和的最大值。反应性程序有无限次执行，因此通过程序的运行时模拟来计算它是不可行的。然而，我们注意到，任何同步程序都是强连接组件(SCCs)[7]的集合，全局程序的行为在这些SCCs之间不断分支。因此，全局行为达到一个固定点。在此基础上，我们提出同步程序的WCRT分析等价于计算这个不动点的模型检验问题。这是本文的主要假设。
使用模型检查来分析实时系统并不新鲜。梅茨纳在[17]中举例说明了使用基本块自动机概念来表示程序的WCET分析模型检查的有效性。类似地，在[15]中提出了一种基于静态分析的形式化方法来计算同步程序的紧界。我们的方法在以下方面与以前的WCRT分析方法有很大的不同。更严格分析的早期方法[10,16]集中于删除冗余路径，但忽略了程序整体状态空间中存在的冗余。我们提出了一种基于模型检查的紧密分析方法，该方法在消除冗余路径的同时，还考虑了基于状态的程序执行。在最坏情况下，[15]方法需要指数时间来生成定时Kripke结构，并对该模型进行了定时分析。相反，我们的模型是由多个自动机组成的，因此模型检查器可以执行许多优化或执行组合推理。最重要的是，WCRT分析的复杂度是CTL[7]的常规模型检查复杂度乘以一个常数项(参见3.6节)。据我们所知，我们的方法是第一个基于模型检验的同步程序紧密WCRT分析问题的公式。虽然是为PRET-C开发的，但所提出的方法也可以应用于其他同步语言，如Esterel。
1.1.激励的例子
与以前的方法不同[5,10]，我们提出了一种通过将WCRT分析问题映射到定点计算来确定同步程序的紧密WCRT值的方法。我们使用下面的简单示例来激发这种方法，如图1所示。本例捕获了一个同步程序，其中两个线程表示为两个FSMs。FSMs的状态对应于tick的结束(在PRET-C中表示EOT，在Esterel中表示暂停)。转换由整数加权，整数表示在两个指定的EOT之间移动的计算长度。这种表示对于任何同步语言都是通用的。
给一些同步程序的中间表示,滴答明确的在图中[24]和每个节点的显性成本值一起被标注起来(成本代表了最大数量的处理器时钟周期需要执行代码对应节点),很容易将这种中间表示转换为一组FSMs,类似于图1所示的。我们将这些FSMs称为TFSMs(定时FSMs)，因为转换是由实际的时间实例(处理器时钟周期)保护的。例如，对应的TFSM需要5个时钟周期才能从
状态移动到
。我们将在2.2节中介绍PRET-C的中间格式和TFSMs的翻译过程。
给定一个同步程序到一组TFSMs的映射，很容易计算这个程序的WCRTmax[5]。对于本例，这个值是线程1和线程2的最大滴答长度的和：10 + 8 = 18。但是，请注意，同步程序的执行会使两个线程的节拍在移动到下一个时刻之前同步。可以将此执行建模为与[24]中使用的屏障同步。在这个执行过程中，在程序的第一个实例中，线程1将在5个时间单元之后首先完成它的本地标记。如果线程2下一次被调度，那么它将花费8个时间单位。因此，程序的第一个全局滴答的时间长度将是13个时间单位。由于两个程序都在两个固定的周期内执行(EOT0→EOT1→EOT2→EOT0)，所以如果我们假设两个线程之间没有数据依赖关系，那么程序的实际WCRT：WCRTtight将是max(5 + 8,10 + 5,7 + 6) = 15。我们将在3.4节中讨论数据依赖关系的问题。
注意，对于这个简单的示例，手工进行分析是可行的。但是，对于具有许多分支的通用程序，不可能以这种方式进行分析，因为每个线程都有许多循环，而且在这些循环之间还会有任意的分支。然而，我们做了两个关键的观察，以便能够自动地做这个严密的分析。首先，所提出的分析类似于程序的运行时仿真。一般来说，这个问题对于复杂的程序来说是不可行的。然而，我们注意到，任何同步程序都是强连接组件(SCCs)[7]的集合，全局程序的行为在这些SCCs之间不断分支。因此，全局行为达到一个固定点。第二个观察结果是，可以使用自动机对TFSMs建模，该自动机使用单个整数变量来建模转换成本。然后利用符号模型检验技术计算一组并发自动机的WCRT值。我们选择了UPPAAL[1]工具，因为它不仅为定时自动机(TA)[2]提供了非常有效的算法，而且还为整数操作的自动机提供了非常有效的算法。利用这些观察结果，我们现在提出一个TFSMs到没有任何时钟变量的TAs的映射，然后为WCRT分析问题开发一个模型检查解决方案。
本文的总体目标是精确定时体系结构(PRET)的开发和编程。(1)提出了一种同步程序静态时序分析的新方法。所提出的方法结合了状态依赖和消除冗余路径以产生更紧密的结果。(2)开发了一种新的同步C扩展，称为PRET-C，用于使用逻辑时间概念编程PRET机器，该概念使用静态定时分析器映射到物理时间。(3)提出了一种简单定制软核处理器的PRET架构设计新方法——ARPRET。这与[14]中为PRET提出的定制处理器方法不同。
论文的组织如下。在第2节中，我们介绍了用于可预测执行的同步C扩展，称为PRET-C。我们还将在本节(第2.2节)中介绍PRET-C的中间格式。在第3节中，我们提出了一个基于模型检验的公式，用于PRET-C程序的精确WCRT分析。我们将通过第2节中的一个运行示例来说明我们的方法。第4节介绍了通过对通用处理器(GPP)进行简单定制而得到的PRET体系结构。在第5节中，我们展示了我们的WCRT分析的一些基准测试结果，将提出的方法与使用PRET-C编写的一些Estbench[8]程序的现有方法进行比较。最后一部分是结语。
2.PRET-C概述
请参见《PRET-C:一种用于精确定时架构的编程新语言》。
3.使用模型检查进行WCRT分析
3.1.前文
同步程序以称为滴答的离散瞬间执行。同步程序的编译器，通常将逻辑并发性编译成纯顺序函数，称为响应函数。在程序执行的每个瞬间，来自环境的输入首先被读取和锁定。然后使用这些输入作为参数调用反应函数，并最终将该函数生成的输出发送到环境中。每一次滴答都会重复这种行为。为了尊重同步假设，任何实现都必须确保外部事件的最小到达时间必须大于反应函数的最大到达时间。WCRT分析是指通过确定响应函数的最大值来确定同步程序的最坏情况下的时钟周期长度，使这个时钟周期长度始终保证程序的安全执行(不存在任何时间错误的可能性)。我们首先定义一个程序的WCRT的三个不同方面，即紧值、最大值和最小值。
定义1：同步程序的WCRT值等于在程序所有可能执行路径上获得的反应函数的最大执行时间。我们还将其称为程序的紧WCRT值，即，表示任何小于该值的值都可能在程序执行期间导致计时错误。
定义2：同步程序的最大WCRT值(称为WCRTmax)被定义为该程序的参与线程的最大本地标记长度的总和。
定义3：同步程序的最小WCRT值，称为WCRTmin，定义为该程序的参与线程的最小本地标记长度的总和。
WCRTtight介于这两个值之间。 WCRTtight处于区间[WCRTmin,WCRTmax]。例如，在生产者消费者的情况下，WCRTmin = 31 + 28, WCRTmax = 54+56(如图3所示)，因此，WCRTtight的取值区间为[59,110]。
建议的方法概述如下。我们将TCCFG转换为具有单个整数变量的等效自动机，以捕获转换的成本。为了便于说明，我们首先将TCCFG映射到TFSMs，然后将其映射到一个等效的TA，该TA没有时钟，只有一个整数变量。我们使用一个著名的定时自动机模型检查器UPPAAL[1]来做这个映射。然后，我们将WCRTtight计算问题模型化为UPPAAL上自动机的一个CTL属性的检查，该自动机有整数变量，但没有时钟。
3.2.映射到没有任何时钟的定时自动机
为了说明，我们首先将TCCFG映射到一个等价的TFSM。图2中生产者消费者TCCFG的两个线程对应的TFSM如图3所示。这个映射是通过深度优先搜索从每个EOT节点到该节点可以访问的所有EOT节点自动完成的。在遍历过程中，只需添加每个节点的成本，就可以得到这两个EOT之间的总成本。例如，在图2中，线程1中和
之间的边的代价是31个时钟周期，这是通过将这两个节拍之间的所有节点的代价相加得到的。单个节点的成本首先从C源获取装配程序，然后从该装配程序生成TCCFG。在我们的例子中，这个程序对应于Microblaze程序集，通过查看对应于该节点的程序集代码，我们自动计算每个节点所需的处理器时钟周期。请注意，我们是基于ARPRET架构生成这些成本的(详细信息见第4节)。因此，计算成本很简单。例如，由于我们不使用分支预测，每个条件节点的假分支都有5个时钟周期的额外开销来考虑管道刷新(参见图2，其中23+5表示管道刷新的开销)。
下一步是将TFSM映射到一个定时自动机。注意，TFSMs之间的组合是严格同步的，而TA组合是异步的[18]。因此，必须小心地进行映射以保持同步。我们使用图4所示的相同生产者消费者示例来演示映射。整个映射是通过将每个TFSM映射到一个等容TA来实现的。另外还引入了一个称为barrier的TA来实现PRET-C执行的同步语义。
3.3.图解
生产者消费者示例的建议解决方案如图4所示。我们首先描述该图中使用的约定。在映射的TA中有两种状态，即EOT状态和barrier状态(分别称为和
)。每个过渡有两个部分。转换的第一部分表示转换保护，它是转换的启用条件。它们出现在每个转换的顶部。转换的底部部分是在执行转换时执行的操作(在UPPAAL中，这称为转换的更新部分)。例如，图4中从
到
的转换使用
(在UPPAAL中捕获'¬gtick'的语法)作为保护，
分别作为更新部分。
对于建议的映射，使用单个整数x来捕获全局标记的成本。我们还使用布尔变量lt来捕获给定线程是否完成了其本地标记。我们使用一个名为gtick的布尔变量，它在全局tick发生时为真。这五个变量被定义为全局变量。
TAs由一个类似于CCS[18]的异步并行操作符组成。为了将给定的TFSM映射到等效的TA(没有时钟)，以实现同步执行语义，我们执行以下操作。对于TFSM中的每个状态，我们在TA中也有一个相同的状态
。对于每一个在TFSM中的转换
，我们通过在两者之间添加一个额外的状态，称为barrier态
来引入两个跃迁。在UPPAAL中需要barrier状态来实现TAs的同步执行。我们接着介绍在TA中的两种转换：
和
。当全局滴答还没有出现的时候，从
向barrier节点过渡（这是过渡守卫'¬gtick'）。在执行此转换时，变量x将增加转换d的成本，并且与线程对应的本地标记(lt1或lt2)被设置为true(这是转换的更新部分)。然后，自动机到达一个barrier节点，并一直停留在那里，直到全局滴答发生。例如，请查看与采样器线程对应的TA中从
到
的转换。这种转换发生在gtick为假的时候。在转换期间，lt1被设置为true，表示采样器的本地标记已经结束，并且x将增加54以捕获转换的成本。为生产者消费者示例生成的TAs如图4所示。
确保达到屏障的任务是通过引入第三个自动机来完成的，该自动机称为barrier，如图4(c)所示。这道屏障只有两个状态，分别叫做WaitLT和GTReached。在两个线程将lt1和lt2都设置为true之前，barrier一直处于WaitLT状态。在这种情况下，两种TAs都将各自从EOT状态过渡到各自的barrier状态。当局部tick变量为真时，barrier将把全局tick变量gtick设置为真，并在GTReached状态中等待。只有当两个自动机都完成了各自的barrier转换，以响应gtick变为真时，barrier才会重置回初始状态。当这种情况发生时，它们将各自的本地滴答再次重置为false。请注意，当barrier执行到初始状态的转换时，计数器x的值将被重置。因此，当到达屏障(屏障处于GTReached状态)时，x的值捕获程序的一个全局标记的成本。
3.4.考虑数据相关性
像Esterel这样的同步程序有信号依赖性。WCRT分析技术必须考虑这些因素，以消除冗余路径以进行更严格的分析[10,16]。这种依赖关系很容易在我们的方法中建模，只需通过附加的保护(用于捕获信号测试)和分配(用于捕获信号发射)来增加自动机的转换。一旦这样做，模型检查器将在定点计算期间自动删除冗余路径。PRET-C没有信号依赖项，但由于是完全C语言，PRET-C程序有数据依赖项(变量测试和分别设置)。在模型检查过程中，消除冗余路径也采用了处理信号相关性的相同思想。
3.5.将WCRT作为CTL属性
我们可以通过模型检查AG()的一个属性来计算程序的WCRT，其中val的值确定如下：我们已经知道程序的WCRTmax，方法是对每个线程的最大本地标记值求和。类似地，可以通过为每个线程添加最小的本地标记长度来获得最小的WCRT值WCRTmin。紧界WCRT值WCRTtight位于这两个值之间。WCRTtight处于区间[WCRTmin,WCRTmax]。例如，在生产者消费者的情况下，WCRTmin = 31 + 28, WCRTmax = 54 + 56。因此，WCRTtight的取值区间为[59,110]。因此，val的值也是完全相同的区间。我们可以使用标准的二分查找来最小化查询的数量。例如，为了获得生产者消费者案例的紧值，我们必须最多编写6个查询(
)。在生产者消费者的情况下，上述分析得到的紧值为92，而最大值为110。
3.6.复杂性
基于时间自动机的模型检查TCTL属性的复杂性已经被证明是完全空间完成的。同样的复杂性也适用于一个或两个时钟[11]的TA。在我们的设置时钟根本不需要，和成本估计的全局滴答是通过简单的增量到一个整数变量称为x。模型检查一个查询AG()的复杂度是：
（是CTL的标准模型检查复杂度）乘以整数x的可能估值数。注意：x的取值范围：[WCRTmin,WCRTmax]。因而：检查单个查询WCRT分析的复杂度：
。自此，最坏情况下，我们需要
次查询。总结而言：总的模型复杂度：
。
注意，我们使用UPPAAL来快速原型化WCRT分析问题的解决方案。是因为它采用激进式状态空间减少和符号分析技术,这将是非常有利于WCRT分析技术规模化。然而，这里开发的WCRT分析问题本质上是一个有界整数的同步自动机上的安全检查问题。因此，将来可以使用自定义工具进行分析，使分析达到最优，并证明所提出的分析确实能产生紧密的WCRT，其核心类似于近期为SoC数据交换协议[20]进行的有界整数模型检查工作。
4.ARPRET架构
我们PRET设计的总体设计理念可以用以下三个简单的概念来概括:
- 1. 并发性:并发性的概念是逻辑上的，但是执行的概念是顺序的，在思想上类似于[6]。这用于确保同步执行和线程安全的共享内存通信。
- 2. 时间:时间的概念是逻辑的，逻辑时间到物理时间的映射是由编译器和WCRT分析器实现的。
- 3.设计方法:ARPRET通过简单定制通用处理器(GPPs)来实现PRET。C语言的扩展是最小的(并发性和逻辑时间的概念)，这些是通过C宏实现的。
本节介绍GPP Microblaze[23]的硬件扩展，以实现时间可预测性。ARPRET平台的基本设置由Microblaze软核处理器组成，该处理器使用两个单向先进先出(FIFO)通道连接到称为可预测功能单元(PFU)的硬件扩展。PFU的作用是使用硬件调度器加速PRET-C线程的调度。
Microblaze[23]是一个可定制的基于RISC的软核处理器，针对Xilinx FPGA的实现进行了优化。为了保持可预测性，它禁用了随机性的功能，如指令和数据缓存。没有使用来自内存管理单元的任何特性，也没有使用并行移位器或浮点单元。我们选择了一个禁用分支延迟槽的五阶段管道。
PFU在本质上与STARPro[24]处理器中的线程控制块有些类似，后者是为直接执行Esterel而设计的。对于每个线程，线程表存储程序计数器和线程状态。根据线程状态，调度程序在请求时发出下一个程序计数器。
Microblaze通过启动线程创建、终止和暂停来充当主线程。PFU在thread表中存储每个线程的上下文，并在线程在Microblaze上执行时监视线程的进程。当给定线程在Microblaze上完成EOT指令时，它使用单向FIFO向线程控制块发送适当的控制信息。作为对此的响应，PFU将这个线程的本地标记位设置为1，然后调用调度器。然后，调度器通过从线程表中检索其程序计数器值并使用FIFO将其发送给Microblaze来选择下一个最高优先级的线程执行。此外，当所有参与的线程都完成了它们的本地节拍时，PFU将等待节拍长度过期。每当完成一个本地标记以等待来自PFU的下一个程序计数器值时，Microblaze都会被阻塞。当所有线程都完成了它们的本地标记，但还没有发生全局标记时，它也会等待。滴答长度由PRET-C程序的静态WCRT分析决定，详见第3节。
Microblaze与任何功能单元(如PFU)之间的通信都是通过使用Xilinx提供的快速单工链路接口[23]来完成的。这种通信是通过使用硬件fifo来完成的。它将Microblaze与PFU紧密结合，分别使用两个fifo，FIFO1和FIFO2来提供确定性和可预测的通信。与FIFOs通信需要交换一些常见的控制信号，如时钟、复位、缓冲区状态、读、写以及程序计数器值等数据。这个架构的更多细节在[3]中提供。
引用
[1] UPPAAL tool. www.uppaal.com. last accessed on 29.4.09.
[2] R. Alur and D. L. Dill. A theory of timed automata. Theoretical Computer Science, 126:183–235, 1994.
[3] S. Andalam, P. Roop, A. Girault, and C. Traulsen. PRET-C: A new language for programming precision timed architectures. Technical Report 6922, INRIA Grenoble Rhˆone-Alpes, http://hal.inria.fr/inria-00391621/fr/, 2009.
[4] G. R. Andrews. Concurrent Programming: Principles and Practice. Benjamin/Cummings, 1991.
[5] M. Boldt, C. Traulsen, and R. von Hanxleden. Worst case reaction time analysis of concurrent reactive programs. Electronic Notes in Theoretical Computer Science, 203(4):65–79, June 2008.
[6] F. Boussinot. Reactive C: An extension of C to program reactive systems. In SOFTWARE PRACTICE AND EXPERIENCE, VOL. 21(4), 401-428, APRIL 1991.
[7] E. M. Clarke, O. Grumberg, and D. Peled. Model Checking. MIT Press, 2000.
[8] S. A. Edwards. Estbench Esterel benchmark suite. http://www1.cs.columbia.edu/ sedwards/software/estbench1.0.tar.gz.
[9] S. A. Edwards and E. A. Lee. The case for the precision timed (PRET) machine. In Proceedings of the 44th DAC, pages 264–265, June 2007.
[10] L. Ju, B. K. Huynh, A. Roychoudhury, and S. Chakraborty. Performance debugging of Esterel specifications. In CODES+ISSS, pages 173–178, 2008.
[11] F. Laroussinie, N. Markey, and P. Schnoebelen. Model checking timed automata with one or two clocks. In CONCUR, pages 387–401, 2004.
[12] L. Lavagno and E. Sentovich. ECL: A specification environment for system-level design. In Proceedings of Design Automation Conference (DAC), New Orleans, June 1999.
[13] X. Li, M. Boldt, and R. von Hanxleden. Mapping Esterel onto a multi-threaded embedded processor. SIGARCH Comput. Archit. News, 34(5):303–314, 2006.
[14] B. Lickly, I. Liu, S. Kim, H. D. Patel, S. A. Edwards, and E. A. Lee. Predictable programming on a precision timed architecture. In In Proceedings of International Conference on Compilers, Architecture, and Synthesis from Embedded Systems (CASES), October 2008.
[15] G. Logothetis, K. Schneider, and C. Metzler. Generating formal models for real-time verification by exact low-level runtime analysis of synchronous programs. In RTSS, pages 256–264, Cancun, Mexico, 2003. IEEE Computer Society.
[16] M. Mendler, R. von Hanxleden, and C. Traulsen. WCRT algebra and interfaces for Esterel-style synchronous processing. In Proceedings of the Design, Automation and Test in Europe (DATE’09), Nice, France, April 2009.
[17] A. Metzner. Why model checking can improve WCET analysis. In CAV, volume LNCS-3114, pages 334–347, 2004.
[18] R. Milner. Communication and Concurrency. Prentice Hall, 1989.
[19] P. S. Roop, Z. Salcic, and M. W. S. Dayaratne. Towards direct execution of Esterel programs on reactive processors. In 4th ACM EMSOFT, 2004.
[20] R. Sinha, P. S. Roop, S. Basu, and Z. Salcic. Multiclock SoC design using protocol conversion. In Design Automation and Test in Europe (DATE), 2009.
[21] F. Vahid and T. Givargis. Embedded System Design. John Wiley and Sons, 2002.
[22] R. Wilhelm, J. Engblom, A. Ermedahl, N. Holsti, S. Thesing, D. Whalley, G. Bernat, C. Ferdinand, R. Heckmann, T. Mitra, F. Mueller, I. Puaut, P. Puschner, J. Staschulat, and P. Stenstr¨om. The worst-case execution-time problem—overview of methods and survey of tools. Trans. on Embedded Computing Sys., 7(3):1–53, 2008.
[23] Xilinx. Microblaze Processor Reference Guide, 2008.
[24] S. Yuan, L. H. Yoong, S. Andalam, P. S. Roop, and Z. Salcic. A new multithreaded architecture supporting direct execution of Esterel. EURASIP Journal on Embedded Systems, 2009:Article ID 610891, 19 pages, 2009. doi:10.1155/2009/610891.
总结
2236
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
