陈祺琦Modeling Kahn Process Networks on.docx
《陈祺琦Modeling Kahn Process Networks on.docx》由会员分享，可在线阅读，更多相关《陈祺琦Modeling Kahn Process Networks on.docx（27页珍藏版）》请在冰豆网上搜索。
陈祺琦ModelingKahnProcessNetworkson
MPSoC平台KPNs（KahnProcessNetworks）建模
InesViskic,DanielGajski
TechnicalReportCECS-08-08
July11th,2008
CenterforEmbeddedComputerSystems
UniversityofCalifornia,Irvine
Irvine,CA92697-3425,USA
（949）824-8919
iviskic@uci.edu,gajski@ics.uci.edu
摘要
KPN（KahnProcessNetwork）是一个在系统应用中被广泛使用的计算模型。
KPN包含由单向FIFO信道（KahnChannels）进行通讯的并行的处理过程。
KPN过程是一种自由调度的处理过程，而且只与输入数据流有关，这使得它特别适用于媒体处理和其它数据流应用。
另一方面，为了缩短市场投放（time-to-maket上市时间）规划时间，嵌入式系统设计师使用系统平台模板？
，并对MPSoC各部分重新配置，设计复杂的MPSoCs（Multi-ProcessorSystemsonChip）。
设计过程将应用分成一些并行的工序，并将它们一一映射到平台部件上。
然而，在KPN规格说明中FIFO信道为点对点原语，不能直接映射到总线中心的？
MPSoC平台上。
因此，想要在MPSoC执行KPN应用，需要手动对应用重新编码，进行平台实现。
这篇论文介绍了一种将KPN整合到MPSoC平台上的简单高效的方法。
它分两步将KPN的Kahn信道通讯进行改变，使其与底层的MPSoC平台相对应。
第一步用一个存储部件和两个点对点信道代替Kahn信道。
第二步将存储部件映射到MPSoC平台的存储构件上，两个信道分别映射到MPSoC平台的总线构件里。
目录
MPSoC平台KPNs（KahnProcessNetworks）建模1
摘要5
1.相关工作5
2.KahnProcessNetworks5
3.基于平台的设计6
3.1.输入6
3.2.输出7
4.问题明确7
5.解决方案7
6.步骤1：
Kahn信道映射为Spec信道+存储元素8
6.2共享内存实现9
6.3.共享TX单元实现10
7.KPN与ESE建模工具（前端）整合10
7.1.GUI/System的扩展11
7.2TLMgen扩展12
7．3.TLMest扩展15
8．步骤2：
Spec模型映射到MPSoC平台内16
9.试验性平台建立17
9.1平台117
9.2.平台218
9.3.平台319
9.4.H264编码器通讯分布20
9.5.结果：
21
10.结论：
21
引用22
图目录
图1.一个进程网络模型的例子6
图2.ESE设计流中的KPN7
图3.将KPN修正为支持基于平台设计的方法8
图4.KahnFIFO映射到间接通讯示例：
通过共享内存或（b）通过桥（TX）单元9
图5.Kahn信道共享内存实现9
图6.Kahn信道共享TX实现10
图7.ESE建模工具11
图8.Kahn信道定义的GUI窗口12
图9.FlagStruct实现（在ubc.sc文件内）12
图10.read_mem_flag实现（在ubc.sc文件内）13
图11.write_mem_flag实现（在ubc.sc文件内）14
图12.存储模块定义（在tlm.cpp文件内）14
图13.Send/Recv通讯方法（在tlm.cpp文件内）15
图14.延时定义（在ubc.sc文件内）15
图15.SpecChannel映射到UBC对象。
16
图16.H.264应用详述17
图17.MPSoC平台118
图18.MPSoC平台219
图19.MPSoC平台320
表目录
表1.KPN信道的特性6
表2.Kahn信道共享内存实现特性10
表3.Kahn信道共享TX单元实现特性10
表4.H264编码映射到平台1到平台2的通讯简介20
表5.H264编码器映射到平台1到3的TLM模型仿真时间21
MPSoC平台KPNs（KahnProcessNetworks）建模
摘要
KPN（KahnProcessNetwork）[4],[5]是一个在系统应用中被广泛使用的计算模型。
KPN包含由单向FIFO信道（KahnChannels）进行通讯的并行的处理过程。
KPN过程是一种自由调度的处理过程，而且只与输入数据流有关，这使得它特别适用于媒体处理和其它数据流应用。
另一方面，为了缩短市场投放（time-to-maket）规划时间，嵌入式系统设计师使用系统平台上的样板，并对MPSoC各部分重新配置，设计复杂的MPSoCs（Multi-ProcessorSystemsonChip）。
设计过程将应用分成一些并行的工序，并将它们一一映射到平台部件上。
然而，在KPN规格说明中FIFO信道为点对点原语，不能直接映射到总线中心的MPSoC平台上。
因此，想要在MPSoC执行KPN应用，需要手动对应用重新编码，进行平台实现。
这篇论文介绍了一种将KPN整合到MPSoC平台上的简单高效的方法。
它分两步将KPN的Kahn信道通讯进行改变，使其与底层的MPSoC平台相对应。
第一步用一个存储部件和两个点对点信道代替Kahn信道。
第二步将存储部件映射到MPSoC平台的存储构件上，两个信道分别映射到MPSoC平台的总线构件里。
1.相关工作
随着MPSoCs变得越来越大，越来越复杂，在设计产业中，基于平台的建模方法变得越来越高效。
METROPOLIS[6]是一种分成三步的基于平台的混合MPSoCs设计仿真建模。
Kopetz[7],[8]为可靠的自动化的系统提出了一个构件模型。
这两种方法都使用预定义的平台样板对系统进行建模，目标都是为了在混合MPSoC上达到更高的可靠性和可依赖性。
然而，它们的设计流程要求输入的模型与提供的平台相兼容。
Eclipse架构[2]提供了一个混合媒体处理系统的平台样板。
它支持有片上共享存储通讯的总线中心样板，而我们的研究则支持有相同协议的通讯（通过存储器）和不匹配的总线协议通讯（通过转换器）。
研究执行应用模型有好几种方法，比如将KPN映射到MPSoC平台上。
ESPAM工具[1]输入为KPN应用模型，一个抽象的平台描述和一个平台应用映射，从而自动生成通讯部件和驱动。
但是，它所支持的平台局限在拥有本地存储的处理器，这些存储器可执行本地写操作，并且能够被平台上所有其它处理器远程读取访问。
此外，所有的处理器必须支持同样的通讯协议，这样才能够读取其它处理器的本地存储。
而我们的方法则支持更多的MPSoC通用通讯架构。
在[3],[9]中，目标是在交易级上对系统建模，需要纯粹的功能性和预估时间进行性能评估。
输入为应用，平台详述以及映射决策。
在[3]中要求输入应用要与一个包含没有存储能力的点对点阻塞式信道的通讯架构相适应。
我们的方法不仅支持阻塞式信道而且支持存储有限的FIFO信道。
2.KahnProcessNetworks
KahnProcessNetwork（KPN）是一种高效的，高性能数据相关媒体处理的应用设计模型。
KPN在信号处理和数据流中更为高效，因为KPN的功能行为只由输入数据决定，与Kahn过程执行后的输入命令没有关系。
KPN程序在它们的私有状态矢量空间实时地执行它们的计算，通讯则通过单向的点对点FIFO信道完成。
在理论模型中，FIFO信道拥有无限的容量，访问方式为阻塞式读取和非阻塞式写入。
图1中我们展示了一个简单的KPN的例子，其中有3个处理过程（P1,P2,P3），由两个大小为m和n（均大于1）的FIFO单元（f1,f2）连接。
在P1->P2的通讯中，发送方P1调用非阻塞式write（）函数将数据推入到FIFOf1，接收方P2调用read（）函数将数据从相同的FIFO中拉出来。
在P2->P3的通讯中，P2将数据写入FIFOf2，P3从其中读取数据。
在P1和P2发送数据过程中，如果接收方P2,P3在FIFOs为空的时候调用read（）函数，它们将会中断，直至数据存储到相应的FIFO。
图1.一个进程网络模型的例子
表1列出了KPN信道的特性，两个纵列分别为这种方法优点（PROs）和缺点（CONs）。
优点
缺点
1.KPN模型运算逐个实现
1.FIFO信道与平台不相对应
2.通过FIFO访问完成进程同步
非阻塞式写操作=推进FIFO
阻塞式读操作=从FIFO拉出来
2.FIFO类型是固定的，所以不同类型的报文需要统一为一种类型（例如字节）或者通过独立的FIFOs传送
表1.KPN信道的特性
3.基于平台的设计
实现systemsonchip（SoC）传统意义上是在RT（registertransfer）级上用诸如VHDL和Verilog这些硬件描述语言来描述。
随着Multi-ProcessorSoCs（MPSoC）的发展和系统应用复杂性的提高，从抽象层次对系统进行详述已经优于RTL。
新兴的基于平台的设计加速了设计过程，因为它支持模块复用，通讯模式隐含在管脚里面，各种细节由设计人员确定。
它使得同时详述系统的HW和sw特征成为可能，它将应用代码分成多个并行的过程，并将它们分别映射到MPSoC平台上预定义的各个部件上。
设计过程中输入系统定义（Spec）和应用所要映射到的MPSoC平台。
输出为系统的功能性交易层模型（TlM），可以用来通过对计算/通讯延时，缓冲/存储所需空间和总线利用率的分析，对系统进行评估。
3.1.输入
系统定义（Spec）是系统的功能性陈述，总线信道通讯与封装运算并行进行。
信道调用含有通讯基本要素的send/recv/write/read/程序来实现路由选择，同步和数据传输。
MPSoC平台是各种平台部件的网表，这些部件分别用于执行计算，通讯和存储（存储器）。
计算部件包含处理器核，ASIC单元和HW加速器，而通讯部件包含总线，桥和接口单元。
3.2.输出
TLM模型计算过程包含在模块内，而总线通讯按UniversalBusChannels（UBCs）的方式建模。
UBC表示系统总线，执行发送/接收程序和共享内存访问。
4.问题定义
KPN的通讯是通过执行单向FIFO信道的读写来实现。
然而FIFO信道为点对点基本元语，因此不能直接映射到平台上。
也因为MPSoC平台内的各部件的连接基于共享系统总线而不是点对点的连接。
图2.ESE设计流中的KPN
因此，在实现KPN系统过程中，设计者还需要根据选择的MPSoC平台手动分割映射应用的工作。
图2中说明了这一问题。
5.解决方案
我们提出了一个简单的两步法，让KPN的FIFO通讯与MPSoC平台相适应。
第一步，每个FIFOKahn信道根据对应的Kahn过程，分解为一个存储段和两个访问它的点对点信道。
发送方通过第一个信道的写入原语访问存储段，接收方通过第二个信道读取这段存储的内容。
第二步将每个存储段映射到MPSoC平台的存储构件上，而每个信道映射到MPSoC平台的UBC构建里。
KPN过程直接映射到平台的模块上（模块可以包含不止一个过程）。
我们的方法在图3中展示。
图3.将KPN修正为支持基于平台设计的方法
6.步骤1：
Kahn信道映射为Spec信道+存储元素
在我们的两步法中，每个Kahn信道首先由两个double-handshakeSpec信道和一个存储元素（存储，桥）代替。
Kahn信道会被转换成下面这些对象：
1.两个Spec信道+共享内存段
a）共享内存段在两个过程中都是局部的
b）共享内存段在两个过程中都是全局的
2.两个Spec信道+共享TX单元
本地共享内存段仅在两个过程都在同一处理器/模块时能被用作通讯缓冲区（处理器内通讯）。
如果处理过程都是远程的，但支持同样的通讯协议，可以用全局共享内存段作为通讯缓冲区（处理器交互式通讯）。
当一个处理过程所在的模块与其它过程所属的总线不同（支持其它通讯协议）时，则需要TX单元进行协议转换。
无论通讯缓冲的类型是什么（存储段或TX），都由信道C1和C2执行读/写访问。
Kahn信道的非阻塞式写操作特性是受保护的，发送方（P1）可以在写入存储区之后继续执行，而不受接收方（P2）的状态影响。
而在KPN中，接收方在数据读取完成之前是不会继续执行的（阻塞式读取特性）。
图4.KahnFIFO映射到间接通讯示例：
通过共享内存或（b）通过桥（TX）单元
图4展示了当两个过程分属于不同的模块，并且共享一个全局存储的时候，Kahn信道映射到交互式处理器通讯架构的两种可能。
如果发送和接受过程属于同一条总线，信道C1和C2执行同样的通讯协议（在图4的下方C1和C2标记为绿色）。
如果两个处理过程支持不同的协议，它们必须通过桥单元TX实现通讯（图4的右侧）。
TX单元会使用一种协议从发送方接受数据（C3，标记为绿色），然后用另一种协议将其传输到接收方（C4，标记为红色）。
最后，如果两个过程在同一模块中（处理器内部通讯），共享内存则是处理器本地的。
在这种情况下，处理过程调用RTOS，而不用通过总线访问存储器。
按之前的经验，RTOS通讯服务由一个点对点阻塞式信道建模，与本地内存相连。
6.2共享内存实现
图5.Kahn信道共享内存实现
图5展示了一个共享内存的FIFO实现，包括一个存储列（FIFO）和三个整型变量：
一个指针head指向可进行写入访问的地址，一个指针tail指向可进行读取访问的地址，还有一个status信号注释当前存储内容的字节数。
每个过程在进行写入和读取操作时，都需要测试status信号，status信号的地址由head指针或者tail指针指示。
在信道C1和C2内执行通讯程序（send/recv）测试这个信号。
如果存储器没有空间了，发送程序则等待POLLING_INTERVAL，然后再次查询。
在报文存入存储之前它不会放弃信道的send（）指令。
相对应的，如果存储器是空的，程序会查询存储的每个POLLONG-INTERAL（在recv指令内），直至报文可获取。
优点
缺点
1.比输入KPN模型更好地与平台的执行模块相对应
1.需要对现有的UBC作极小的改动
2.在FIFO单元n>1的的复杂系统中，FIFO映射到m<>n存储模块可以有不同的选择
2.内存是隐式的，所以报文需要转换为字节流
3.内部存储零碎
表2.Kahn信道共享内存实现特性
6.3.共享TX单元实现
图6.Kahn信道共享TX实现
Kahn信道映射包括一个桥单元TX（图6），它有两个支持不同协议的信道C3和C4。
每个程序使用它的信道申请TX服务，然后将报文转移到TX的FIFO内。
服务申请根据调用它的程序存储在对应的寄存器Rq1或Rq2中。
接收到的TX申请和FIFO的访问由TX控制器程序处理（Ctrlr，入图6所示）。
如果无法及时响应申请，调用它的程序就会中断，直至控制器能够处理申请。
优点
缺点
1.与系统平台相对应
1.需要对现有的UBC作极小的改动
2.对于n>1的FIFO单元，FIFO映射到m<>nTX单元有不同的选择
2.通讯需要多余的代码：
在实际数据传输之前需要对TX发送请求
3.对现有的UBC不需要改动
3.在处理数据传输时需要额外的开销，因为TX
表3.Kahn信道共享TX单元实现特性
7.KPN与ESE建模工具（前端）整合
图7将ESE建模工具用黑框标识了出来，它输入系统的Spec模型，输出它的功能性TLM（没有时间标识）和带有预估时间的TLM。
这个工具允许系统设计者通过交互式GUI定义MPSoC平台，然后在SystemCapture内将应用源代码映射到平台上。
获得的系统输入到TLMgenerator产生SystemCTLM，其中有三个主要的文件：
1.tlm.cpp-定义映射到SystemC的平台和应用
2.ubc.sc-定义总线模型和系统通讯
3.tx.sc-定义桥模型（当系统内存在桥模型时）
图7.ESE建模工具
为了将KPN整合到EmbeddedSystemEnvironment（ESE）工具内，我们需要将下列内容归入到ESE内：
7.1.GUI/System的扩展
设计者定义Spec模型的系统需求，使其能够创建一个Kahn信道。
卡恩信道为单向信道，有缓冲功能，支持非阻塞式写入特性。
它的完全定义为：
1.程序发送方ID/接口：
例如send_P_ID_Sender_P_ID_Receiver
2.程序接收方ID/接口：
例如recv_P_ID_Receiver_P_ID_Sender
3.共享内存段或一个TX单元，以及：
a）每个程序到存储段/TX对应的路径
b）FIFO尺寸（即存储段或TXFIFO的地址范围）
因此，Kahn信道定义的菜单与存储信道的定义非常相似，除了这里用一个中间的存储段连接两段过程，而不是直接用一个存储连接一段过程。
并且，与存储信道不同的是，Kahn信道的通讯方法（例如send_P_ID_Sender_P_ID_Receiver,recv_P_ID_Receiver_P_ID_Sender）包含FIFO管理方法（read_flag,write_flag）.
图8展示了一个Kahn信道定义的GUI窗口的例子。
图8.Kahn信道定义的GUI窗口
7.2TLMgen扩展
将KPN归入到TLMgeneration（TLMgen）内，不需要对已有的TX模型做任何改动（tx.sc不改动）。
但是，为了将Kahn信道映射到两个信道+共享内存段时，TLM发生器需要一个环形FIFO的结构和方法实现一个存储段。
如同6.2部分中的规定，一个FIFO由一个存储阵列和三个无符号整数标识：
fifoValue，fifoHead和fifoTail（第一个包括FIFO当前存储数据的字节数，后两个为FIFO的开头和结尾私有指针）定义。
每次对存储进行读写操作时都会更新这些指针。
typedefstructflag_structure{
2.unsignedintValue;
3.unsignedintfifoHead;
4.unsignedintfifoTail;
5.}FlagStruct;
图9.FlagStruct实现（在ubc.sc文件内）
图9展示了在UBC定义文件中（ubc.sc）FIFO管理所需的标示的设置（一FlagStruct结构实现）。
图10和11介绍了read_mem_flag和write_mem_flag方法，它们同样存在ubc.sc中，每次对存储段进行访问时都会调用它们。
在read/write数据移动之前会调用read_mem_flag，确保段内存在有效的数据（UBC_READ，图10，13-16行），或者有足够的空间写入新数据（UBC_WRITE，图10，17-20行）。
1.extern"C"voidread_mem_flag（unsignedintProcID,unsignedintMemFlagAddr,
2.FlagStruct*Flag,unsignedintMsgSize,unsignedintTransferType）{
3.switch（ProcID）{
4.caseP_ID_Process1:
5.P_ID_Process1*p1=（P_Process1*）ptr_Process1;
6.p1->Bus0busport->read（ProcID,MemFlagAddr,（void*）Flag,sizeof（FlagStruct））;
7.break;
8.caseP_ID_Process2:
9.P_Process2*p2=（P_Process2*）ptr_Process2;
10.p2->Bus0busport->read（ProcID,MemFlagAddr,（void*）Flag,sizeof（FlagStruct））;
11.break;
12.}
13.if（TransferType==UBC_READ）{
14.//thememoryisempty
15.if（Flag->Value16.cout<Memoryempty.\n",ProcID）;
17.}elseif（TransferType==UBC_WRITE）{
18.//thememoryisfull
19.if（Flag->Value+MsgSize>MEMORY_M0_CAP）
20.cout<Memoryfull.\n",ProcID）;ProcID）;
21.}}
图10.read_mem_flag实现（在ubc.sc文件内）
在数据传送完成之后调用write_mem_flag更新存储段的指针。
如果传送过程是读取数据（UBC_READ，图11，3-10行），fifoTail会将它所指的地址加上读取的字节数，如果是写入数据，对应的增加fifoHead所指的地址（UBC_WRITE，图11，11-18行）。
而fifoValue会减少/增加读取/写入的字节数（10和18行）。
1.extern"C"voidwrite_mem_flag（unsignedintProcID,unsignedintMemFlagAddr,
2.FlagStruct*Flag,unsignedintMsgSize,unsignedintTransferType）{
3.if（TransferType==UBC_READ）{
4.//updatepointersforread
5.Flag->fifoTail+=MsgSize;
6.if（Flag->fifoTail>=MEMORY_M0_CAP）
7.//circularFIFOcompletedonecycle;backtoinitvalue
8.Flag->fifoTail=MEMORY_M0_EMPTY;
9.//updatememorystatus
10.Flag->Value-=MsgSize;
11.}elseif（TransferType==UBC_WRITE）{
12.//updatepointersforwrite
13.Flag->fifoHead+=MsgSize;
14.if（Flag->fifoHead>=MEMORY_M0_CAP）
15.//circularFIFOcompletedonecycle;backtoinitvalue
16.Flag
升级会员 