基于可配置处理器的嵌入式系统ESL设计需求

　　* 算法设计与实现

　　* 行为级综合

　　* SoC架构设计、仿真及分析

　　* 构建虚拟系统原型

　　* 功能-架构协同设计

　　算法设计工具允许用户对算法进行描述、仿真，并且可以生成算法实现流程的代码描述。比如Mathworks的Matlab和Simlink就是这种工具。目前大部分的工具是使用面向数据流或数据密集型算法进行建模，但是也有一些工具，如Mathworks的StateFlow，允许用户使用有限状态机对控制逻辑进行描述，并可实现自动生成C代码。

　　行为级综合工具是新一代基于C/C++或SystemC开发的工具，专门为满足算法和软件工程师而非硬件工程师的设计需要而开发的。由于使用C /C++，因此仿真速度比使用传统的RTL方法有了10~1000倍的显著提高。这也为系统硬件、软件和算法的联合仿真开辟了一条新道路。

　　用户通过SoC的架构设计工具使用传统总线，标准嵌入式处理器库(如MIPS或ARM)，以及其他的一些组件(如存储器，特殊的硬件模块和外设等)来构建SoC系统。之后便可以对整个设计进行仿真，通常使用SystemC或C/C++描述的指令集仿真器(ISS)和外围硬件模块联合仿真。这样便可分析得到一些系统级的特性，如总线负荷、竞争，内存访问，处理器负荷等。这些工具可以从CoWare，ARM，Synopsys等公司得到。

　　虚拟系统原型工具提供单核或多核SoC平台的仿真模型，可以以数十MHz的速度仿真实际系统。系统架构师需要在这样的平台上运行大量的测试序列，并得到系统性能分析的结果，软件开发人员也可在接近实际的仿真模型中测试他们的嵌入式软件。

　　但现今提供的商业ESL工具没有一种可以在更早的阶段帮助工程师决定系统的基础架构，例如决定整个系统需要使用处理器的数量和种类；需要设计专门的通信机制还是使用传统的分级总线；如何将应用程序划分成多个任务，并分配到不同的处理器上运行；如何有效的探索各种可能的设计方案等。现在的SoC架构设计工具和ISS要在体系架构确定后才有用武之地。

　　今天的设计要比上世纪90年代末处理器加硬件模块的结构复杂许多。从最小、最简单的手持无线设备到标准的、带有语音视频处理功能的蜂窝电话，直至非常复杂的电子设备，当今的技术已经可以把多颗处理器、多片存储器、复杂的片上通信总线网络，以及由相当可观的硬件模块组成的协同工作子系统集成到一颗 SoC中。同时应用软件也愈加复杂，数百万行代码组成的系统软件已是司空见惯了。因此，使用传统方法进行体系结构设计变得日益困难，这一切都使得ESL设计方法学变得越来越必要。尤其是当可配置处理器代替传统的固定指令集处理器，可能的设计方案越来越多时更是如此。

　　定制指令集处理器(ASIP)

　　基于特定应用定制指令集处理器(ASIP)，这一概念在嵌入式系统设计中变得越来越重要。ASIP的设计方法学和开发工具也在学术界和IP设计领域被提及，并且许多商业的ESL工具已经提供了类似的处理器和协处理器综合工具。处理器的指令集大都采用一种中间形式进行描述。Tensilica提供的XPRES工具也提供这样的功能，由Tensilica定义的TIE语言描述的，并且工程师可以应用这种语言，进一步手动优化处理器的特定配置。

　　如果SoC的设计是要通过单颗CPU实现，也许再增加一些硬件加速器来提升性能，那么现在的这些工具和设计方??就已经足够了。但事情并非如此简单，如今已有很多的SoC设计使用了至少两颗处理器(一颗是做控制的RISC，另一颗是进行数据处理的DSP)，并且下一代SoC设计正朝着6~10颗处理器这一方向前进。在这种情况下，目前显然缺乏设计方??和工具来支持这样的设计。

　　使用可配置处理器搭建MPSoC系统

　　当使用多颗处理器尤其是使用可配置处理器来设计SoC时，将会遇到一些关键问题，包括：

　　* 一个或一组应用需要使用多少颗处理器

　　* 应如何配置、扩展这些处理器

　　* 处理器采用同构方式还是异构方式

　　* 处理器之间如何通信？采用标准总线，还是片上网络(NoC)，采用点到点方式，或是多种方式的组合。

　　* 如何选择正确的并行模式，是流水线还是多线程？

　　* 工程师如何从应用程序中提取可并行执行的任务？又怎样分解他们？

　　* 在可配置处理器，多处理器，新的通信架构以及内存选择等多种可供选择的技术下，如何能得到多种设计方案并进行对比？

　　* 在90nm以下的工艺流程上，如何从10个处理器的设计扩展到100个，甚至1000个处理器？

　　如今EDA供应商所提供的ESL工具还不足以解决这些问题。可配置处理器IP厂商的工具提供了以下流程帮助工程师进行设计：从已有的应用程序或算法的软件代码开始；分解成多个同步处理进程；将各个进程分别映射到已经优化过的处理器上，这些处理器之间有着理想的通信网络；迭代处理器定义和进程映射；分析处理器间通信网络的需求；设计并行控制和调度模块；涉及通信网络(包括存储器、总线、队列等)；分析结果并且迭代其他可能的配置；反复迭代优化直至实现满足设计需求的MPSoC系统；实现软件/硬件的具体设计。

　　这种自上至下、以应用需求为驱动的设计流程，在一些MPSoC子系统的应用设计中是非常适合的。尤其是当需要一个全新的功能，或者之前的系统设计方案不足以支持新标准应用程序的开发时，这种从设计需求和应用程序的特征出发进行设计的方法，往往可以得到最优的解决方案。使用这种方法定义系统的体系架构时，通过模拟、分析，并迭代得出使用处理器的种类和数量，内存的层次结构以及通信子系统等等是非常有效的。

　　MPSoC ESL设计方法需要提供很多功能，这些需要包含在集成开发环境(IDE)中，如系统建模，程序映射，各种设计方案对比，以及对可配置处理器的配置修改。

　　IDE是最引人注目的部分。Eclipsez作为一个开源软件，对扩展已有的软件工具、器件、调试软件都有很好的支持，而这些功能可以使得 MPSoC ESL设计在更抽象的层次上进行。比如可以在Eclipse中加入处理器创建、扩展的用户配置界面，将用户的配置转化成基于某种特定语言描述的指令扩展，之后交给外部的特定编译器进行编译。因为这一扩展被编译成RTL级的描述，在这种意义下可以使用IDE定制和实现一个软硬件系统。

　　IDE软件提供的项目编辑功能可以支持设计输入、修改、映射到特定处理器等操作。同时还要能够配置处理器、内存、通信接口、总线以及外设等设备，用以搭建一个完整的系统。IDE还需要支持系统级仿真，可以装载处理器的ISS，能够装载整个系统的仿真模型，静态或动态的追踪系统级上发生的事件，能统计处理器的执行状况并记录数据，并通过图形界面向用户显示。并需提供分析工具，使得用户可以方便得到传输延迟、资源竞争、处理器等待、内存的使用状况，以及处理器数据读取的平衡状况等系统级信息。

　　IP的参数(meta-data)和一些临时信息需要使用标准的格式来存储。近来XML格式被广泛的使用到工具中，如Mentor Graphics的Platform. Express等等。基于XML格式排版的文件很容易被扩展，解析和生成，所以是一种描述存储系统架构和参数的极具吸引力的方法。

　　有了系统架构的信息，也有了标准格式的ISS模型，便可以生成系统仿真模型用于系统测试。许多已有的ISS支持在SystemC环境中运行，这样便可以和总线模型、内存模型、硬件模块模型、外设模型等其他系统模型在事务级上进行互联、仿真。TLM在ESL方??中是一个非常重要的概念，但到目前为止还没有为TLM上的互操作定义标准。由于没有一个可用的OSCI TLM标准，考虑到OSCI工作的不透明性质和其缺乏一个发展的路线图，ESL世界里的系统仿真必须继续依赖于IP提供商提供的可供互联的适配器和用户自己对“事务”这一概念的理解。

　　快速功能仿真，有时也被称为“虚拟系统原型”，是对周期精确型的TLM模型的重要补充。周期精确型的TLM模型允许对系统运行时的细节进行分析，每秒钟只能运行数千个周期或再多一些，而快速功能仿真则可以数百万个周期每秒的速度运行，这对软件的开发有着特别的意义。

　　可配置处理器是高性能MPSoC系统的核心，通过扩展指令的自动生成技术使得在设计的最后阶段仍可修改系统配置。通过在设计的早期阶段自动生成的配置和扩展ISA，可将最初的任务映射到这个处理器上，当处理器发生变化，任务需要重新被映射时，该过程可以快速反复迭代进行。通过手动对设计进行改善，最终可以通过提高进程效率，从而降低处理器频率，达到设计目标。自动生成的软件工具链(包括编译器、ISS、调试器和IDE扩展功能模块)允许对处理器的每一个修改都可以反映到整体系统中。

　　本文小结

　　复杂的多颗可配置处理器组成的嵌入式系统设计对现今的ESL工具提出了更高的要求，这些需求似乎更像是应该由IP供应商来提供，而不是EDA工具厂商。虽然仍可以使用通用的ESL工具，但具体的流程和特定工具都将是与所使用的IP直接相关的。