陈祺琦-ModelingKahnProcessNetworkson.doc

MPSoC平台KPNs(Kahn Process Networks)建模Ines Viskic, Daniel GajskiTechnical Report CECS-08-08July 11th, 2008Center for Embedded Computer SystemsUniversity of California, IrvineIrvine, CA 92697-3425, USA(949) 824-8919 , 摘要KPN(Kahn Process Network)是一个在系统应用中被广泛使用的计算模型。KPN包含由单向FIFO信道(Kahn Channels)进行通讯的并行的处理过程。KPN过程是一种自由调度的处理过程，而且只与输入数据流有关，这使得它特别适用于媒体处理和其它数据流应用。另一方面，为了缩短市场投放(time-to-maket上市时间)规划时间，嵌入式系统设计师使用系统平台模板？，并对MPSoC各部分重新配置，设计复杂的MPSoCs(Multi-Processor Systems on Chip)。设计过程将应用分成一些并行的工序，并将它们一一映射到平台部件上。然而，在KPN规格说明中FIFO信道为点对点原语，不能直接映射到总线中心的？MPSoC平台上。因此，想要在MPSoC执行KPN应用，需要手动对应用重新编码，进行平台实现。这篇论文介绍了一种将KPN整合到MPSoC平台上的简单高效的方法。它分两步将KPN的Kahn信道通讯进行改变，使其与底层的MPSoC平台相对应。第一步用一个存储部件和两个点对点信道代替Kahn信道。第二步将存储部件映射到MPSoC平台的存储构件上，两个信道分别映射到MPSoC平台的总线构件里。目录MPSoC平台KPNs(Kahn Process Networks)建模1摘要51.相关工作52.Kahn Process Networks53.基于平台的设计63.1.输入63.2.输出74.问题明确75.解决方案76.步骤1：Kahn信道映射为Spec信道+存储元素86.2共享内存实现96.3.共享TX单元实现107.KPN与ESE建模工具（前端）整合107.1. GUI/System的扩展117.2TLMgen扩展1273.TLMest扩展158步骤2：Spec模型映射到MPSoC平台内169.试验性平台建立179.1平台1179.2.平台2189.3.平台3199.4.H264编码器通讯分布209.5.结果：2110.结论：21引用22图目录图1.一个进程网络模型的例子6图2.ESE设计流中的KPN7图3.将KPN修正为支持基于平台设计的方法8图4.Kahn FIFO映射到间接通讯示例：通过共享内存或 (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.Spec Channel映射到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模型仿真时间21MPSoC平台KPNs(Kahn Process Networks)建模摘要KPN(Kahn Process Network)4,5是一个在系统应用中被广泛使用的计算模型。KPN包含由单向FIFO信道(Kahn Channels)进行通讯的并行的处理过程。KPN过程是一种自由调度的处理过程，而且只与输入数据流有关，这使得它特别适用于媒体处理和其它数据流应用。另一方面，为了缩短市场投放(time-to-maket)规划时间，嵌入式系统设计师使用系统平台上的样板，并对MPSoC各部分重新配置，设计复杂的MPSoCs(Multi-Processor Systems on Chip)。设计过程将应用分成一些并行的工序，并将它们一一映射到平台部件上。然而，在KPN规格说明中FIFO信道为点对点原语，不能直接映射到总线中心的MPSoC平台上。因此，想要在MPSoC执行KPN应用，需要手动对应用重新编码，进行平台实现。这篇论文介绍了一种将KPN整合到MPSoC平台上的简单高效的方法。它分两步将KPN的Kahn信道通讯进行改变，使其与底层的MPSoC平台相对应。第一步用一个存储部件和两个点对点信道代替Kahn信道。第二步将存储部件映射到MPSoC平台的存储构件上，两个信道分别映射到MPSoC平台的总线构件里。1.相关工作随着MPSoCs变得越来越大，越来越复杂，在设计产业中，基于平台的建模方法变得越来越高效。METROPOLIS6是一种分成三步的基于平台的混合MPSoCs设计仿真建模。Kopetz 7,8为可靠的自动化的系统提出了一个构件模型。这两种方法都使用预定义的平台样板对系统进行建模，目标都是为了在混合MPSoC上达到更高的可靠性和可依赖性。然而，它们的设计流程要求输入的模型与提供的平台相兼容。Eclipse架构2提供了一个混合媒体处理系统的平台样板。它支持有片上共享存储通讯的总线中心样板，而我们的研究则支持有相同协议的通讯（通过存储器）和不匹配的总线协议通讯（通过转换器）。研究执行应用模型有好几种方法，比如将KPN映射到MPSoC平台上。ESPAM工具1输入为KPN应用模型，一个抽象的平台描述和一个平台应用映射，从而自动生成通讯部件和驱动。但是，它所支持的平台局限在拥有本地存储的处理器，这些存储器可执行本地写操作，并且能够被平台上所有其它处理器远程读取访问。此外，所有的处理器必须支持同样的通讯协议，这样才能够读取其它处理器的本地存储。而我们的方法则支持更多的MPSoC通用通讯架构。在3,9中，目标是在交易级上对系统建模，需要纯粹的功能性和预估时间进行性能评估。输入为应用，平台详述以及映射决策。在3中要求输入应用要与一个包含没有存储能力的点对点阻塞式信道的通讯架构相适应。我们的方法不仅支持阻塞式信道而且支持存储有限的FIFO信道。2.Kahn Process NetworksKahn Process Network (KPN)是一种高效的，高性能数据相关媒体处理的应用设计模型。KPN在信号处理和数据流中更为高效，因为KPN的功能行为只由输入数据决定，与Kahn过程执行后的输入命令没有关系。KPN程序在它们的私有状态矢量空间实时地执行它们的计算，通讯则通过单向的点对点FIFO信道完成。在理论模型中，FIFO信道拥有无限的容量，访问方式为阻塞式读取和非阻塞式写入。图1中我们展示了一个简单的KPN的例子，其中有3个处理过程(P1,P2,P3)，由两个大小为m和n（均大于1）的FIFO单元(f1,f2)连接。在P1-P2的通讯中，发送方P1调用非阻塞式write()函数将数据推入到FIFO f1，接收方P2调用read()函数将数据从相同的FIFO中拉出来。在P2-P3的通讯中，P2将数据写入FIFO f2，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.基于平台的设计实现systems on chip (SoC)传统意义上是在RT (register transfer)级上用诸如VHDL和Verilog这些硬件描述语言来描述。随着Multi-Processor SoCs (MPSoC)的发展和系统应用复杂性的提高，从抽象层次对系统进行详述已经优于RTL。新兴的基于平台的设计加速了设计过程，因为它支持模块复用，通讯模式隐含在管脚里面，各种细节由设计人员确定。它使得同时详述系统的HW和sw特征成为可能，它将应用代码分成多个并行的过程，并将它们分别映射到MPSoC平台上预定义的各个部件上。设计过程中输入系统定义(Spec)和应用所要映射到的MPSoC平台。输出为系统的功能性交易层模型(TlM)，可以用来通过对计算/通讯延时，缓冲/存储所需空间和总线利用率的分析，对系统进行评估。3.1.输入系统定义(Spec)是系统的功能性陈述，总线信道通讯与封装运算并行进行。信道调用含有通讯基本要素的send/recv/write/read/程序来实现路由选择，同步和数据传输。MPSoC 平台是各种平台部件的网表，这些部件分别用于执行计算，通讯和存储（存储器）。计算部件包含处理器核，ASIC单元和HW加速器，而通讯部件包含总线，桥和接口单元。3.2.输出TLM模型计算过程包含在模块内，而总线通讯按Universal Bus Channels(UBCs)的方式建模。UBC表示系统总线，执行发送/接收程序和共享内存访问。4.问题定义KPN的通讯是通过执行单向FIFO信道的读写来实现。然而FIFO信道为点对点基本元语，因此不能直接映射到平台上。也因为MPSoC平台内的各部件的连接基于共享系统总线而不是点对点的连接。图2.ESE设计流中的KPN因此，在实现KPN系统过程中，设计者还需要根据选择的MPSoC平台手动分割映射应用的工作。图2中说明了这一问题。5.解决方案我们提出了一个简单的两步法，让KPN的FIFO通讯与MPSoC平台相适应。第一步，每个FIFO Kahn信道根据对应的Kahn过程，分解为一个存储段和两个访问它的点对点信道。发送方通过第一个信道的写入原语访问存储段，接收方通过第二个信道读取这段存储的内容。第二步将每个存储段映射到MPSoC平台的存储构件上，而每个信道映射到MPSoC平台的UBC构建里。KPN过程直接映射到平台的模块上（模块可以包含不止一个过程）。我们的方法在图3中展示。图3.将KPN修正为支持基于平台设计的方法6.步骤1：Kahn信道映射为Spec信道+存储元素在我们的两步法中，每个Kahn信道首先由两个double-handshake Spec信道和一个存储元素（存储，桥）代替。Kahn信道会被转换成下面这些对象：1. 两个Spec信道+共享内存段a) 共享内存段在两个过程中都是局部的b) 共享内存段在两个过程中都是全局的2. 两个Spec信道+共享TX单元本地共享内存段仅在两个过程都在同一处理器/模块时能被用作通讯缓冲区（处理器内通讯）。如果处理过程都是远程的，但支持同样的通讯协议，可以用全局共享内存段作为通讯缓冲区（处理器交互式通讯）。当一个处理过程所在的模块与其它过程所属的总线不同（支持其它通讯协议）时，则需要TX 单元进行协议转换。无论通讯缓冲的类型是什么（存储段或TX），都由信道C1和C2执行读/写访问。Kahn信道的非阻塞式写操作特性是受保护的，发送方(P1)可以在写入存储区之后继续执行，而不受接收方(P2)的状态影响。而在KPN中，接收方在数据读取完成之前是不会继续执行的（阻塞式读取特性）。图4.Kahn FIFO映射到间接通讯示例：通过共享内存或 (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单元n1的的复杂系统中，FIFO映射到mn存储模块可以有不同的选择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.对于n1的FIFO单元，FIFO映射到mn TX单元有不同的选择2.通讯需要多余的代码：在实际数据传输之前需要对TX发送请求3. 对现有的UBC不需要改动3.在处理数据传输时需要额外的开销，因为TX表3.Kahn信道共享TX单元实现特性7.KPN与ESE建模工具（前端）整合图7将ESE建模工具用黑框标识了出来，它输入系统的Spec模型，输出它的功能性TLM（没有时间标识）和带有预估时间的TLM。这个工具允许系统设计者通过交互式GUI定义MPSoC平台，然后在System Capture内将应用源代码映射到平台上。获得的系统输入到TLM generator产生SystemC TLM，其中有三个主要的文件：1. tlm.cpp-定义映射到SystemC的平台和应用2. ubc.sc-定义总线模型和系统通讯3. tx.sc-定义桥模型（当系统内存在桥模型时）图7.ESE建模工具为了将KPN整合到Embedded System Environment(ESE)工具内，我们需要将下列内容归入到ESE内：7.1. GUI/System的扩展设计者定义Spec模型的系统需求，使其能够创建一个Kahn信道。卡恩信道为单向信道，有缓冲功能，支持非阻塞式写入特性。它的完全定义为：1. 程序发送方ID/接口：例如send_P_ID_Sender_P_ID_Receiver2. 程序接收方ID/接口：例如recv_P_ID_Receiver_P_ID_Sender3. 共享内存段或一个TX单元，以及：a) 每个程序到存储段/TX对应的路径b) FIFO尺寸（即存储段或TX FIFO的地址范围）因此，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归入到TLM generation(TLMgen)内，不需要对已有的TX模型做任何改动（tx.sc不改动）。但是，为了将Kahn信道映射到两个信道+共享内存段时，TLM发生器需要一个环形FIFO的结构和方法实现一个存储段。如同6.2部分中的规定，一个FIFO由一个存储阵列和三个无符号整数标识：fifoValue，fifoHead和fifoTail（第一个包括FIFO当前存储数据的字节数，后两个为FIFO的开头和结尾私有指针）定义。每次对存储进行读写操作时都会更新这些指针。typedef struct flag_structure 2.unsigned int Value;3. unsigned int fifoHead;4.unsigned int fifoTail;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 void read_mem_flag(unsigned int ProcID, unsigned int MemFlagAddr,2. FlagStruct *Flag, unsigned int MsgSize, unsigned int TransferType) 3. switch(ProcID)4. case P_ID_Process1:5. P_ID_Process1 *p1 = (P_Process1 *) ptr_Process1;6. p1-Bus0busport-read(ProcID,MemFlagAddr,(void*)Flag,sizeof(FlagStruct);7. break;8. case P_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. / the memory is empty15. if (Flag-Value MEMORY_M0_EMPTY + MsgSize)16. coutValue + MsgSize MEMORY_M0_CAP)20. coutfifoTail += MsgSize;6. if(Flag-fifoTail = MEMORY_M0_CAP)7. / circular FIFO completed one cycle; back to init value8. Flag-fifoTail = MEMORY_M0_EMPTY;9. / update memory status10. Flag-Value -= MsgSize;11. else if (TransferType = UBC_WRITE) 12. / update pointers for write13. Flag-fifoHead += MsgSize;14. if(Flag-fifoHead = MEMORY_M0_CAP)15. / circular FIFO completed one cycle; back to init value16. Flag-fifoHead = MEMORY_M0_EMPTY;17. / update memory status18. Flag-Value += MsgSize;19. 20. switch(ProcID)21.case P_ID_Process1:22. P_Process1 *p1 = (P_Process1 *) ptr_Process1;23.p1-Bus0busport-write(ProcID,MemFlagAddr,(void*)Flag,sizeof(FlagStruct);24. break;25. case P_ID_Process2:26. P_Process2 *p2 = (P_Process2 *) ptr_Process2;27. p2-Bus0busport-write(ProcID, MemFlagAddr, (void*)Flag, sizeof(FlagStruct);28. break;29. 图11. write_mem_flag实现（在ubc.sc文件内）#define MEMORY_M0_EMPTY (unsigned int) sizeof(FlagStruct)#define MEMORY_M0_CAP (unsigned int) 10000#define MEMORY_M0_FULL (unsigned int) MEMORY_M0_EMPTY+MEMORY_M0_FULL1. class M_MEMORY_M0: public sc_module2. public:3. SC_HAS_PROCESS(M_MEMORY_M0);4. M_MEMORY_M0(sc_module_name name):sc_module(name)5. MEMORY_M00 = MEMORY_M04 = MEMORY_M08 = MEMORY_M0_EMPTY;6. for(i = MEMORY_M0_EMPTY; i MEMORY_M0_CAP)8. wait(10, SC_NS); / wait 10 ns before polling again9. else10. break;11. 12. /write data13. p-port-write(P1, MEMORY_M0_LOW+flag.fifoHead, ptr, size);14. / set flag15. write_mem_flag(P1, MEMORY_M0_LOW, &flag, size, UBC_WRITE);16. 17.18. extern C void recv_P2_P1(void *ptr, int size)19. Process2 *p = (Process2 *) ptr_Process2; 21. FlagStruct *flag;22. / poll flag23. while(1) 24. read_mem_flag(P1, MEMORY_M0_LOW, &flag, size, UBC_READ);25. if(flag.Value size port-read(P1, MEMORY_M0_LOW+flag.fifoTail, ptr, size);32. / set flag33. write_mem_flag(P1, MEMORY_M0_LOW, &flag, size, UBC_READ);34. 图13.Send/Recv通讯方法（在tlm.cpp文件内）73.TLMest扩展KPN包括一系列的Kahn计算过程和一系列的Kahn信道。TLM评估可以以正规C语言的形式评估Kahn Processes。而TlMest需要提供Kahn信道访问总线所需的时间（仅在交互式处理器通讯内），通过中间缓冲同步每一个处理过程，传送数据。并且，每次检查FIFO段失败时，都要对下一个传送申请的等待周期进行定义。这可以利用如图14陈述的宏定义完成。#define REQ_OPB_BUS (unsigned int) 2 / in nsec#define ACK_OPB_BUS (unsigned int) 1 / in nsec#define READ_OPB_DELAY (unsigned int) 2 / in nsec#define WRITE_OPB_DELAY (unsigned int) 2 / in nsec#define POLLING_DELAY (unsigned int) 50 / in nsec图14.延时定义（在ubc.sc文件内）然后，等待申明会插入到通讯代码内（在ubc.sc和tx.sc内），反应已定义的延时。举个例子：在申请和释放总线之前，程序会执行wait(REQ_OPB_BUS,SC_NS)，相应地，仲裁程序会执行wait(ACK_OPB_BUS, SC_NS)指令。8步骤2：Spec模型映射到MPSoC平台内第二步骤在ESE内已经实现了，不需要增加其它的改动。设计者定义哪些Kahn信道生成的存储段要映射到哪些Memory Module，并且为每个段分配一段地址空间。相似的，映射到TX的段定义为TX FIFOs。而且，TLMgen按映射到UBC内的路径，分配所有生成的Spec Channels，并安排它们相继运行。方法在图15中概述。图15.Spec Channel映射到UBC对象。模块Module1和Module2分别包含并行进程P1,P2Pn和Pa,PbPm。程序通过点对点Spec Channels直接一一通讯（例如图15的P2PCh1和P2PCh2），或者间接地通讯（例如信道MemCh和.TxCh，分别对应存储和桥）。在间接通讯中，除了Spec Channels之外，每一对程序还包含一个专用存储段，映射到存储（M0,M1,M2）或者桥的内部存储（TX单元）。由于点对点Spec Channels同时执行，在映射到UBC对象时要按次序映射。对UBC的访问的判优也同时完成。每个程序在使用它之前都需要获得访问允许，在传送过程完成之后要释放访问。因此，UBC内的所有交易都是按次序的。UBC内的仲裁以先到先服务的互斥锁实现。9.试验性平台建立H.264编码器是视频数据帧压缩标准H.264 ITU-recognized的一部分。这个算法将每个数据帧划分为一个个子模块，然后对每一块进行变换。为了加快计算速度，此算法会尝试对附近已经运算完成的子模块变换再利用。这就是众所周知的帧内预测。它会预测相邻的数据帧的相似性，然后对下一帧再利用已经完成的计算（帧间预测）。H.264编码算法中主要的功能构建如下： 离散余弦变换 (DCT) 量化 逆量化 DCT逆变换 运动估计/预测计算(帧内和帧间预测) 预测方式选择(帧内和帧间预测)H.264的简化KPN展示如图16。Kahn过程由13个方框表示，Kahn信道由方框之间的单向箭头表示。多数Kahn信道被省略了（总共有43条）。图16.H.264应用详述程序ChromaIntra 和 LumaIntra是帧内预测的一部分，分别对应chroma（彩色的）和luma（非彩色的）。离散余弦变换和量化过程在ChromaDct 和 LumaDct程序（同样的，分别对应chroma和luma）内实现，而逆变换在ChromaIdct 和 LumaIdct内完成。最繁重的运算任务封装在MotionEst过程中，在其中执行运动估计和帧内、帧间预测的预测运算。WriteMB 和 WritePic过程将输出写进output文件内，Deblock 和 UpSample执行少量的辅助计算，比如将各模块合并进编码段（Deblock）和对它们进行采样（UpSample）。我们已经将H.264编码应用映射到一系列混杂的MPSoC平台内。以下为这些平台的详细描述。9.1平台1图17展示的第一个MPSoC平台包含三个处理器（模块1到模块3），两个总线（UBC1和UBC2）和一个2-port桥（TX）。支持的通讯范型如下：处理器交互式通讯：通过共享内存段或TX 处理器内部通讯：通过处理器本地内存。共享内存（通过UBC1信道）的通讯在程序Module1和Module2间实现。Module3的程序则支持另一个不同的通讯协议，通过TX和两个信道（UBC1和UBC2）与其它程序通讯。最后，多重任务处理和处理器内部通讯由Module1和Module2承载（如图17，连个RTOS模型，用绿色标记）：Module1包含8个过程，Module包含4个。图17.MPSoC平台19.2.平台2H.264编码器第二个MPSoC平台包含五个处理器（Module1到Module5），三条总线（UBC1，UBC2和UBC3），如图18所有的处理器通过一个3-port桥单元（TX）通讯。处理器Module1和Module3承担多重任务处理和处理器内通讯（用绿色标记的RTOS模型）：Module1含有7个程序，Module3含有4个。图18.MPSoC平台29.3.平台3第三个也是最后一个H.264编码器MPSoC平台的映射方式与之前介绍的平台相同（见图18）。但是，在这个平台中，Module3和Module4的程序没有用桥单元（TX）进行相互间的通讯，而是通过全局共享内存完成。图19.MPSoC平台39.4.H264编码器通讯分布这个应用包含它们本身之间通讯的13个程序。有43个通讯sender-receiver对，每个数据帧总共交易998条信息。信息的平均尺寸为6.626KB，信息尺寸的变化范围为4到945KB。应用映射到已经描述了的MPSoC平台上。在平台1（3个处理器，表4第1行）中，每个处理器中只有24对程序通讯（通过本地内存，表4的第2列），其中19个与总线相连。13个用的是全局共享内存（表4第3列），6个用的是桥TX进行协议转换（表4第4列）。在平台2（5个处理器，表4第2行）中，有18个程序对通过本地共享内存通讯，25个申请桥元素（TX）的服务。最后，在平台3（5个处理器，表4第2行）中，KPN-to-platform映射和平台2是一样的。但是在平台3中，有一对程序通过共享内存进行通讯（第3列第3行）。所以，与平台2的TX交易量相比，在这个平台中通过TX单元的交易就少了一个（从25对变为24对，第4列的第2、3行）。表4.H264编码映射到平台1到平台2的通讯简介9.5.结果：这三个平台生成的TLMs可以分为两种类型： 单纯的功能性模型，没有时间注释，或称为untimed TLMs， 带有通讯和计算评估时间的TLM，或称为timed TLMs对这两组模型，我们测量了它们在主频3GHz，内存为1GB的4核奔腾处理器上的仿真时间。其结果按untimed和timed放在了表5第3和4列中。另外，timed模型对在FPGA板 模块映射到SW PEs由 Microblaze soft-core处理器实现；总线在芯片总线上OPT；TX单元有HW IP单元实现。上实现这个特殊的系统所需要的运行时间进行了评估。三个平台的timed TlMs评估时间的结果放在表5的第5行中。表5.H264编码器映射到平台1到3的TLM模型仿真时间平台1的untimed TLM（表5的第3、4列）的仿真速度最快，因为在单个的处理器中进行了更多的数据交易，本地内存的访问速度也非常快（平台1中有24个P2P信道，而平台2中有18个）。随着平台的复杂度增加，处理器间的交互处理的总线访问次数增加。因为总线交易需要串行化，所以它们需要更多的时间完成。最后，由于程序必须等待TX状态为ready，并且对平台的访问请求要有足够的缓冲空间，桥单元还会增加额外的延时。10.结论：我们介绍了将KPN应用变换为一个反应MPSoC平台的TL模型的简单且自动的两步法。第一步，KPN信道转换为一个存储段，通过点对点阻塞式信道访问。设计者将这段映射为(a)一个全局存储单元，或者(b)处理器的本地存储，或者(c)一个桥单元的缓冲区，信道则自动分配为相应的总线模型。第二步包含平台内总线模型的信道访问的串行化。TLMs生成的仿真结果证实了我们方法的优越性。多核平台的仿真时间增加了一点点（与单核平台相比较），它为用户提供了一个系统快速功能性验证，准确地反映了底层的MPSoC平台。关于今后的工作，我们的研究主要集中于生成带有系统计算通讯时间注释的TLMs。我们还在研究通讯范例输入的邮箱和信号量扩展。最后，我们今后的研究将会支持更多的复杂的MPSoC和NoC架构平台样板。参考文献1 T. Stefanov, C. Zissulescu, A. Turjan, B. Kienhuis, E. Deprettere, System Design using KahnProcess Networks: The Compaan/Laura Approach, In Proceedings of 7th InternationalConference Design, Automation and Test in Europe (DATE04), pp. 340-345, Paris, France, Feb.16-20, 2004.2 L. Yu, S. Abdi, D. Gajski: “Transaction Level Platform Modeling in SystemC for