数字系统软硬件协同综合设计.docx

上传人:b****6 文档编号:16813239 上传时间:2023-07-17 格式:DOCX 页数:21 大小:319.09KB
下载 相关 举报
数字系统软硬件协同综合设计.docx_第1页
第1页 / 共21页
数字系统软硬件协同综合设计.docx_第2页
第2页 / 共21页
数字系统软硬件协同综合设计.docx_第3页
第3页 / 共21页
数字系统软硬件协同综合设计.docx_第4页
第4页 / 共21页
数字系统软硬件协同综合设计.docx_第5页
第5页 / 共21页
数字系统软硬件协同综合设计.docx_第6页
第6页 / 共21页
数字系统软硬件协同综合设计.docx_第7页
第7页 / 共21页
数字系统软硬件协同综合设计.docx_第8页
第8页 / 共21页
数字系统软硬件协同综合设计.docx_第9页
第9页 / 共21页
数字系统软硬件协同综合设计.docx_第10页
第10页 / 共21页
数字系统软硬件协同综合设计.docx_第11页
第11页 / 共21页
数字系统软硬件协同综合设计.docx_第12页
第12页 / 共21页
数字系统软硬件协同综合设计.docx_第13页
第13页 / 共21页
数字系统软硬件协同综合设计.docx_第14页
第14页 / 共21页
数字系统软硬件协同综合设计.docx_第15页
第15页 / 共21页
数字系统软硬件协同综合设计.docx_第16页
第16页 / 共21页
数字系统软硬件协同综合设计.docx_第17页
第17页 / 共21页
数字系统软硬件协同综合设计.docx_第18页
第18页 / 共21页
数字系统软硬件协同综合设计.docx_第19页
第19页 / 共21页
数字系统软硬件协同综合设计.docx_第20页
第20页 / 共21页
亲,该文档总共21页,到这儿已超出免费预览范围,如果喜欢就下载吧!
下载资源
资源描述

数字系统软硬件协同综合设计.docx

《数字系统软硬件协同综合设计.docx》由会员分享,可在线阅读,更多相关《数字系统软硬件协同综合设计.docx(21页珍藏版)》请在冰点文库上搜索。

数字系统软硬件协同综合设计.docx

数字系统软硬件协同综合设计

数字系统软硬件协同综合设计

作者:

RajeshK.GuptaGiovanniDeMicheli

计算机系统实验室,斯坦福大学

摘要

随着系统设计复杂度的不断提高,预设计组件的使用,如通用微处理器,有效的降低了综合硬件的复杂度。

当系统的设计包括更换新的处理器和ASIC芯片时,由于针对特定应用的硬件和处理器软件,计算模型和频率不同,给这种异构或混合系统的计算机辅助综合设计带来了挑战性的问题。

在本论文中,通过使用时间限制来控制软硬件上的任务,最终达到要求的性能限制,我们展示了实现异构系统合成的可行性。

介绍

大多数特定用途的数字系统是由通用处理器,存储器和特定应用的硬件电路组成。

这种嵌入式系统广泛分布于医疗仪器,工程控制,汽车自动化和网络与通信系统中。

除了针对特定应用之外,这类系统的设计还要考虑到针对执行时间的各种限制,至此这类系统之称之为实时嵌入式系统。

设计和分析实时嵌入式系统面临诸多挑战,如性能评估,合适的系统实施步骤选择,系统功能性和时间性属性的验证。

在实际应用中,这类系统是从没有严格定义功能的系统规格说明书开始实施,并采用以设计为导向的开发方法。

例如,如图1所示的网络处理器的设计,它连接了一条串行线和存储器。

这个处理器的作用是通过串行线使用特定的通信协议(如以太网连接中的CS/CD协议)发送和接受数据。

用特定硬件还是用运行在处理器上的软件来实现该功能,通常是基于可获得的性能和实现该功能的各部分成本。

这种软硬划分很大程度上取决于设计者的经验,而且发生在系统设计实施的早期阶段,并影响着设计的每个阶段,它通常导致设计部分不是无法满足性能要求,就是过于超出性能要求。

更重要的是,由于整个设计过程的对等性质,无法保证给定的实现是否满足系统的性能需求(可能的话,除非重复设计)。

图1–面向设计的系统实现

相反,一种称之为协调设计的系统实现方法学已经在独立的集成电路芯片(芯片级协同设计)方面取得很大成功。

系统设计对于特定系统的硬件属于行为级,可以通过适当的专用语言来描述。

为数字系统选择一种合适的描述语言属于正在进行的一个研究课题,近年来,使用硬件描述语言HDLs已经广泛地为人所接受。

针对数字硬件电路的系统设计方法学,实现了电路功能的行为描述,并试图产生一种纯硬件的门级实现(如图2所示)。

图2–软硬件协同综合设计

最近在高水平协同设计方面的进展,使得从高水平的系统规格开始实施数字电路软硬件协同设计成为可能,并且在工业界和学术界已经有了一些可用的这类系统。

协同设计的输出是由单个或多个芯片实现的门级或几何级描述。

随着门数(逻辑单元)的增加,这种设计方法需要利用定制或半定制的设计方法,从而也导致了成本和设计周期的相应增加。

因此,对于大型系统设计,综合硬件解决方案依赖于芯片实现所需要的技术选择而变得相当的昂贵。

在系统开发成本和性能簇的另一方面,我们可以用通用编程语言创造一个仿真的软件原型系统,如快速原型系统。

这类软件原型系统可以快速的创建,经常用于需要修改系统功能的开发中。

然而,软件原型系统在有时间限制的系统设计中往往达不到性能要求(如图2)。

尽管如此,在实践中,有效成本设计常常综合使用软硬件来实现全部的目标(如图1),这就为尝试使用综合设计方法实现由软硬件组成的系统提供了动力。

这种方法得益于普遍存在的权衡设计的系统分析,并设计出有效成本的系统。

实现这个目标的一种途径就是指定最终实现的系统在成本和性能上的要求(如图3)。

图3–系统实现的建议方案

在本论文中,我们将阐述一种系统的研究方法,实现以限制为驱动的系统设计。

此项研究建立在数字硬件的高水平综合设计技术之上,并扩展了系统实现的资源需求的思想,图4表示了这种方法必备的各种条件。

图4–嵌入式系统综合设计

在一个初步确定了软硬件实施方案的系统模型中,需要考虑到行为规范。

然后将这个软硬件划分模型综合成一个软硬件组件相互关联的目标系统架构(如图5所示)。

这个目标架构将一个处理器嵌入到一个特定用途的硬件中,这个处理器的指令和数据操作只使用一级存储器和地址空间。

同时,为了简化硬件组件的的综合和性能评估,特定用途的硬件不采用流水线。

用于它的相对简化,该目标架构可以在嵌入式系统领域得到广泛的应用。

图5–目标系统架构

本论文的组织结构如下:

第二章阐述了如何获取系统功能和限制,并产生一个中间表示,从而系统地研究软硬件划分权衡方案。

第三章介绍了一种系统功能划分的技术。

第四章阐述了实现混合系统设计中使用的综合设计技术。

第五章和第六章我们举了一个设计实例,并为我们在系统综合设计方面的试验做了一个总结。

获取系统功能和限制规约

我们用一种硬件描述语言(HardwareC)来描述系统功能,这里阐述的系统综合设计方法并不依赖于HDL语言的某个特定选择,也可以用其他的硬件描述语言(HDLs)来描述,如VHDL或Verilog等。

HardwareC利用Olympus开发工具进行芯片级综合设计。

HardwareC遵循C编程语言的大部分语法和语义,并作了必要的纠正和修改以适应明确的硬件建模。

HardwareC描述由一系列相互关联的流程组成,这些流程都被实例化为由语义声明组成的多个块。

在系统规格参数中,一个流程模型与其他流程并发执行。

一个流程在一次执行结束后重新自启动,流程体的执行允许嵌套并发和连续操作。

图6展示了一个HardwareC规格参数的实例,这个实例执行了两个数据输入操作,紧接着条件生成一个计数器值。

这个计数器值z被用于为while循环设置递减计数器值。

HDL规格参数被提取并用一种基于图形的方法表示。

图6–输入参数和输入捕获实例

通常,系统模型由一系列分级的相关序列图组成,在每个图中,定点表示语言级操作,边表示操作之间的依赖关系。

这种表示方法使得输入参数的并发继承关系非常明确,输入描述的属性推理也变得更简单了。

正如我们将看到的一样,它将允许我们分析输入描述的时间属性。

模型属性

序列图是一种资源极坐标图,交汇顶点代表无操作,定义操作之间共享内存的每个模型图中都有一系列变量与之相关联,资源和交汇顶点通过多次迭代实现操作执行的同步。

因而,模型图的极性保证了只有一个操作执行与其他操作的每个执行有关,这样使得操作以单一速率执行(如图7)。

图7-模型图的属性

与模型图相关的变量序列定义了操作之间的共同存储空间,用于为操作间的通信提供便利。

因为单一速率执行模型,它直接与确保模型图中保护操作之间共享存储内容的完整性的操作顺序相关。

尽管如此,模型图之间的操作是多速率执行语义,即一个操作的执行变量号可能与另一个模型图中的操作相关。

用于这种执行得多速率特性,通过通信模型图是通过消息传递原语是实现的,如发送和接受原语。

这些原语的使用简化了模式之间通信的规约。

多速率规约是对异构系统进行建模的一个重要特点,因为处理器和特定用途硬件可以用不同的时钟和速度运行。

HardwareC可以用操作规格表示与外部事件的同步,如接受操作和数据依赖循环操作。

这些操作称之为非决定性延迟操作,表示不可知的执行延迟。

对这些操作建模的能力是反映嵌入式系统描述的关键因素。

图6中,用双周起来表示操作。

规约中的时间限制

一个系统模型可能有多种实现方式,再定义实现需求中特定性能需要时,时间限制非常重要。

时间限制主要有以下两种(如图8所示):

图8–时间限制类型

最小/最大延迟约束:

这些约束对连续两个操作执行的时间间隔有一个边界。

执行频率约束:

这些约束对连续的同一操作之间的时间间隔有一个边界。

这两种约束足于捕获大多数实时系统需要的约束,最小延迟约束在图形化表示中可以通过在边上设置权值表示相应资源操作的延迟时间来捕获约束条件。

另外,回退边需要捕获醉倒的延迟约束(如图9)。

图9–时间约束

模型分析

提出系统模式图中功能和约束之后,就能评估系统的性能,验证特定约束的一致性。

性能测试需要预测操作延迟,这些延迟基于使用的不同硬件类型和运行软件的处理器,分别进行软硬件实现测试。

处理特性的通过一种处理器成本模型来获取,这种模型由一系列处理器基本操作执行延迟功能,存储器寻址计算功能,存储器访问和处理器终端响应时间组成。

实践约束分析试图找到以下问题的答案:

实施的约束条件能满足给定的实现吗?

一种实现模型是通过为模型图中延迟可知的操作指定适当的延迟时间来实现的。

约束的可满足性与图表的结构,确切的延迟时间和约束值有关。

有些图(与延迟操作和它们之间的依赖相关)的结构化属性可能由于没有考虑到操作的准确延迟时间而无法满足约束条件。

有些约束条件可能完全没有一致性,例如两个操作之间的最大延迟约束同时也有一个更大的最小延迟时间约束,这种约束条件无法通过指定非负的操作延迟时间值来满足。

对于模型图中存在操作,如果时间约束满足操作延迟的所有可能的确定和非确定值,则认为满足时间约束条件。

如果时间约束满足指定操作延迟界限的所有可能值,则认为该约束有限满足时间约束条件。

有限可满足性分析在允许使用时间约束的地方是很有用的,这些时间约束在一些假设条件(如可接受的操作延迟边界)是可以满足的,没有这些假设,通常的时间约束可满足性分析将视之为病态。

时间约束分析通过分析图表中的有权值的子序列图来实现。

为了解释清楚,我们假设模型图中没有任何操作,那么,图中的每条边都可以被标记为一个确定的可知权值。

在这图中,如果存在一个良性的循环,最小/最大延迟约束将是不可满足的。

下面,对于存在的操作,如果不存在包含操作的循环,那么时间约束就是可满足的。

对于包含一个操作的循环,它不可能决定时间约束的可满足性,只能保证时间约束的有限可满足性。

通过图标转换和保存代码语义来打破这个循环是可能的。

我们通过一个例子来简短的说明这个思想。

对于非流水线实现,频率限制可视为模型图中相应资源和交汇定点之间的最小/最大延迟限制。

应该注意到,在某些情况下,系统吞吐量(由频率约束指定)在每个执行延迟的整个过程中可以独立的优化,如系统延时可以通过利用流水线执行模型和额外的资源来优化。

对于确定性的的固定频率系统,特别是DSP应用系统,已经开发的扩展转换可用于确定和获取系统吞吐量的界限。

通过序列图建模的系统通常在多个不同的频率上进行操作。

此外,由于循环中操作延迟的存在,随着时间的推移,某个特定的操作执行的频率可能会改变。

在控制领域的嵌入式系统中,这个属性是必不可少的,它使得获取系统吞吐量的确切边界的问题变得更加困难。

我们用以下的例子来说明包含操作的图中的频率约束。

例1:

思考如下的HardwareC处理段

V是一个表示整数的布尔数组。

由于频率约束的存在,在读操作上,约束图中有一个包含一个操作的循环,这个操作与没有边界的while循环相关联(注意频率约束对应于图10中从交汇定点t到资源s的有向边)。

图10–通过图转换打破循环

两个连续的读操作执行之间的时间间隔由整个while循环的执行时间决定的。

由于这种依赖变量的循环存在,端口p的输入频率是可变的,并且无法保证总是能够满足需要的频率约束,通常,测定端口p的确切吞吐量是很困难的。

通过图转换和使用确定大小的缓冲区,频率约束的有限可满足性是可以保证的,这一点我们将在下面作出解释。

图10展示了测序图模型和相应的流程测试。

用,rd表示读操作,lp表示while循环操作,在以下的执行跟踪中,标号P1,P2等表示第一个,第二个等,在进程调用测试中,L1,L2等表示lp操作的多次调用。

由于循环体产生的边际效应,可以将原来的图转换成片段,为了提高读操作的吞吐量,

 

约束分析和软件

在单一处理器目标体系架构上运行的软件会强加一种线性执行的语义,这使得对软件实现的图形模型的限制性分析变得更加复杂了。

也就是说,为了分析软件操作的执行延时,在图形模型中需要一个完整的操作执行的顺序。

在建立一个完整的执行顺序的过程中,无边界的环有可能被建立出来,这将使得约束不被满足。

正如图11所示的那样,任何把一个操作放在操作op1和op2之间的串行化都会使得op1和op2之间的最大延时限制不被满足。

然而,要注意到,虽然软件中的所有计算必须串行化的执行,但是通信操作可以被同时处理。

换句话说,覆盖掉等待同步或者与其他计算通信的操作的执行是有可能的。

但是这种覆盖,需要在软件中动态调度操作的能力,因为同时活跃的操作可能以不同的顺序完成。

一般来讲,操作的动态调度会牵连到延时的开销,这些开销是由于对操作的选择和调度引起的。

因此,一个好的软件模型会把软件当成一个固定延时的并发的线程的集合(图12)。

一个线程被定义为一个线性化操作的集合,这些操作可能会由图12中由一个环指示的操作开始。

一个线程不包含任何操作,一个初始操作的延时被认为是调度操作延时的一部分,因此,不包括在一个线程延迟中。

实现一个软件的时候,用多并发线程代替一个单一程序也避免了完全串行化所有操作的需要,这种完全的串行化会建立无边界的环,正如先前图11解释的那样。

在这个软件模型中,不同线程的操作的约束满足性可以用边界满足性来检查,这里假设调度操作的延时是固定的和已知的(比如上下文切换的延时)。

系统划分

系统的划分问题指的是把操作分配给硬件或者软件。

这种分配决定了操作的延时。

另外,把一个操作分配到一个通用处理器或者一个或多个具体应用的硬件电路牵连到附加的延时,这是由于分配需要通信开支。

任何一个有效划分策略必须试图将这种通信开支最小化。

更进一步,由于软件的操作是在一个单一的通用处理器上实现的,所以增加软件中的操作会增加通用处理器的利用率。

所以整个系统的性能取决与软硬件划分能否有效的利用通用处理器以及通用处理器和领域特定的硬件之间的总线带宽。

因此一个划分策略必须通过权衡一个操作的软硬件实现来影响整个系统的性能。

一个有效的方法是设计一个划分开销函数,这个函数可以捕获这些特性并利用它使得划分算法达到一个期待的解决方案,在所有的解决方案之中,一个最优的解决方案被定义为可以获得划分开销函数的最小值的方案。

需要注意的是,我们不但需要捕获硬件和软件部分的大小的影响,也需要捕获这些部分在划分开销函数中的时间行为的影响。

与此相反,大多数对硬件的划分策略都将注意力放在了优化电路的面积和输出管脚上。

在划分阶段捕获划分对时间性能的影响是很困难的。

部分是因为时间特性在本质上通常是全局的,这使得划分开销函数的增量计算变得困难,而这种计算对于开发有效的划分算法又是必须的。

考虑划分对整个延迟的影响的时候,近似技术被建议使用。

然而,要注意到,在软件世界的划分,为了驱动划分算法,大量的利用了统计时间特性[23]。

硬件和软件划分的两种极端情况的区别可以由调度操作的灵活性得出。

硬件划分试图将实现调度操作的电路分开。

另一方面,程序级别的划分关心的是在运行时被调度的操作。

在我的软硬件划分的方法中,我采取了中间的方法(图13),在这种方法中我采用了计算时间特性的确定的边界,这种时间特性可以在划分开销函数中被增量的计算,也就是说,新的划分开销函数能在常数的时间计算出结果。

这是由一个软件模型实现的。

这个软件模型在形式上是一个图12中的程序线程的集合和一个划分开销函数,这个函数是它的变量的线性组合。

软件组件可以被以下的特性所描述:

1线程延时,指示一个程序线程的执行延时。

2线程响应速率,程序线程被请求的速率。

3通用处理器利用率,

指示通用处理器的利用率,被定义成

4总线利用率,

(每秒)发生在硬件和软件之间的总的通信的数量。

对于在硬件和软件之间传送的

个变量,

是变量

的两个相继执行的样本的最小时间间隔的相反数。

这个时间间隔由与一个变量相联系的输入输出操作的速率限制决定。

用参数确定的软件特性使得静态计算软件性能的边界变得容易。

这些边界对于合适的选择系统功能的软硬件划分是有帮助的。

然而过分的估计性能参数,比如通用处理器和总线利用率也是有不利的地方的,因为一般来说,基于实际传送的数据的值,要有一个线程请求和通信的分配。

硬件的尺寸是自底向下的从实现每一个操作的资源的尺寸估计计算出来的。

另外,软硬件之间的接口是以软件和硬件之间的通信端口的集合来表征的,软件和硬件之间是通过一个公共的总线来通信的。

硬件和软件之间通信的开销是由上面描述的总线利用率来表明的。

用划分代价模型来考虑,软硬件划分的问题可以用下面的问题来陈述:

已知一个顺序图形模型的集合

和操作之间的约束,建立两个顺序图形模型

,使得一个可以用硬件来实现,另外一个可以用软件来实现,以下说明是正确的:

1时间限制被

中的所有流图所满足,

2处理器的利用率,

3总线利用率,

,总线利用率的边界是总线带宽和内存访问延时的函数,

4一个划分开销函数,

是最小化的。

在这里

定义了通过划分传送的变量

的积累大小,

是正的常量。

一个具体的首先划分问题的解决方法,也就是一个最小化划分开销函数的解决方法,需要检验大量的解决方案,这些解决方案的数量随着划分操作的数量呈现几何态势的增长。

因此为了找到一个开销函数的最优值,也就是与局部特性有关的最小值,启发式策略经常采用。

大多数一般的解决划分问题的启发式策略以一个具有建设性的初始的解决方案开始,然后这个方案会通过一些迭代的过程被改进。

迭代式的改进是可以被实现的,举例来说,可以通过在划分之间移动或者交换操作和路径来改进。

一个好的启发式策略对初始的解决方案相对来说是不敏感的。

一般来说,大量的操作的交换使得启发式策略对开始的解决方案更加的不敏感,但这是以增加时间复杂性作为代价的。

下面,我们描述划分算法的直觉上的特征。

具体的细节在别处说明[24]。

首先要确定出能被软件实现的操作,使得相应的限制性的图形实现可以被满足并且软件(程序线程的集合)在输入和输出上满足要求的速率限制。

作为一个初始的划分,我们假定与数据依赖的循环操作相关的操作定义了软件中的程序线程的开始,其他所有的操作都用硬件实现。

软件输入输出的速率限制被转化为要求的相应速率的边界。

一个程序线程的最大的可达到的相应速率被计算为它的延迟的倒数。

一个程序线程的延时是用一个通用处理器延时开销模型来计算的,并且包含一个固定的调度开支的延时。

从一个初始的解决方案开始,我们通过在划分之间迁移操作来执行迭代的改进。

操作在划分之间的迁移影响它的执行延时。

也会影响到操作被转移到的线程的潜在的响应速率。

它对通用处理器和总线带宽利用率的影响也被计算出来。

在任何一步中,都会选择操作进行迁移,使得这种迁移降低通信的开销并且可以维护时间限制的可满足性。

另外,我们可以通过证明对于每一个线程,通用处理器和总线利用率的约束都可以被满足来检查通信的可行性。

系统综合

从划分的图形模型开始,下一个问题就是综合单独的硬件和软件组件。

从顺序图形模型生成硬件电路已经在其他地方被详细的描述了([18]其他的方法在[1,2,3,5,7]中)。

所以我们将注意力集中在从划分模型中生成软件和接口电路上。

软件综合的问题可以被描述为从划分图形模型中生成一个程序,这个程序正确的实现了最初的系统功能。

我们假设生成的程序被映射到真实的内存中,所以相关的内存管理问题与这个问题是没有关系的。

先前的划分识别出了将要被实现为硬件的图形模型和将要被实现为软件的操作(组织为程序线程)。

例4.1在例2.1中展示的过程test可以被实现为如下的两个软件中的程序线程。

在test过程的软件实现中,线程T1执行读操作,另外一个线程T2有循环体中的操作组成。

对于T1中的每一个执行单元,T2中有v个执行单元与它对应。

从线程中生成程序可以使用协同例程或者是子例程方案。

由于一般来说,程序线程之间会有相互依赖,一个协同例程模型更加适合。

两个操作之间的依赖既可以是数据依赖也可以是控制依赖。

取决与先前的关系和操作的时序,通过插入一些其他的依赖关系,这些依赖关系中的一些会变得冗余,这导致一些程序线程是凸包的,也就是说,所有的外部依赖关系都不第一个和最后一个操作所限制。

对于一个给定的对应一个程序线程的子图,一个输入的数据依赖可以被转移到它的第一个操作,一个输出的数据依赖可以被转移到它的最后一个操作。

这种处理结果导致潜在的并行性的丢失,然而它使得例程实现的任务更加容易,因为所有的例程都可以被实现为互相独立的程序,这些程序具有静态嵌入的控制依赖。

速率限制和软件

正如先前提到的,在有操作间依赖存在的情况下,保证一个给定软件的实现可以满足在I/O端口上数据速率限制并不总是可能实现的。

在相关操作同步的情况下,通过将上下文切换的延迟分配到各个等待操作中来检查时间限制的边界满足性是可能的。

然而在相关的操作无边界的循环的情况下,这些操作产生的延迟由主动计算时间组成,因此,边界满足性的分析需要对循环索引值的估计。

我们将在下面的例子中描述这种情况。

例4.2考虑从例2.1中提到的进程test中生成的线程T1和T2。

两个相继执行的读操作的时间间隔由整个while循环的执行时间决定。

由于这个延迟时间可变的loop循环,端口p的输入速率是可变的并且T1的响应速率不能总被保证可以满足它。

由于在循环体中的操作可以改变test进程内存的内容,这个进程可以被认为由两个平行的进程组成,如图14所示。

线程T2的第一个操作,wait1,需要观察线程T2中的操作的数据依赖性。

第二个等待操作wait2,需要保证T2对于T1的变量所有的内存副作用都被正确的反应。

为了获得对于调用线程的响应速率的确定的边界,通过创建一些数目可变的程序线程来展开循环线程是可能的。

然而,在这种情况下,循环线程的每一次迭代都将承担调度的开销。

正如前面部分描述的,程序线程的动态创建也可以导致违反通用处理器利用率的限制。

然而,用线程T1的执行来覆盖循环线程T2的执行并且保证边界时间限制的可满足性是有可能的。

可以观察到,如果循环线程不会产生对调用线程S1的存储空间的副作用,操作wait2是可以被移除的。

也就是说1和2共同的变量是只读的并且不能被循环体修改。

在这正情况下,程序线程的响应速率可以通过在程序线程之间使用数据缓冲来维护。

具体的实现细节,读者可以参考[25]。

硬件软件接口

由于软件组件的串行执行,从硬件转移到软件的数据必须被显示的同步,采用轮询策略,软件组件可以被设计成执行基于数据需求的事先计划好的从硬件组件的转移。

这要求硬件组件的静态调度。

在软件功能被通信限制的情况下,也就是说,通用处理器大部分时间都在忙等待输入输出操作的情况下,这样的方案已经足够了。

更进一步,在没有任何无边界延迟的操作的情况下,这种方案下的软件组件可以被简化成一个单一的程序线程和一个单一的数据通道,因为所有的数据传输都是串行化的。

然而,这种方案不会支持任何分支和数据到达的重新排序,因为硬件层面的操作的动态调度是不被支持的。

为了适应硬件和软件组件执行的不同的速率,而且由于无边界的延迟的操作,我们需求为不同的执行线程寻求一种动态调度策略。

这种调度是基于数据的可用性的。

一种支持这种调度的机制是通过一个控制FIFO,这种控制的FIFO尝试强加一种策略,在这种策略中,数据按照它们被产生的顺序进行消费。

这个软硬件接口由在每个通道上的数据队列和一个按照输入数据到达的顺序保持使能程序线程的标识的控制FIFO组成。

这个控制FIFO的深度等于执行线程的数量,因为一个线程的执行由于等待请求数据的可用而被停止。

软硬件的接口协议是用保护命令来描述的,如下面的例4.3所示的那样。

例4.3考虑一个图形控制器的混合实现,这个控制器包含两个在软件中生成线和圆的坐标的线程,如下图所示。

使用控制FIFO的接口协议由下面的语句来说明。

在这个例子中,两个具有16bit宽度和1bit深度的数据队列,line_queue和circle_queque,和一个具有2bit宽度和1bit深度的controlFIFO被声明了。

保护命令说明了1号或者2号被放入队列的条件,一个信号名称

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 经管营销 > 经济市场

copyright@ 2008-2023 冰点文库 网站版权所有

经营许可证编号:鄂ICP备19020893号-2