从Multicore到Many-Core：体系结构和经验

在这一环境中，预测带宽需求、处理负载甚至是功耗都会成为很复杂的任务。

　　一家经验丰富的many-core系统开发公司内部人士评论说："出于这一原因，发售的很多系统性能都不是太好。开发人员能够对系统平均带宽需求进行建模，但是，他们低估了峰值需求，遇到了无法预测的瓶颈问题。使其能够正常工作的唯一方法是降低系统性能。"

　　他继续解释说："很难预测这些系统中的总线竞争或者峰值带宽。设计人员一般甚至都不会进行尝试；他们只是尽量做好总线和外部存储器配置。他们设计，测试，并不断重复。"

　　这种不确定性意味着，在工程开始时，如果缺少工作参考设计，则无法知道某一many-coreSoC是否能够满足一些特殊的要求。解决的唯一方法是为系统提供过多的资源，使得资源竞争不会超出能够使用的资源范围。

　　这样做必然的结果就是增大了功耗。如果不能提前预测哪些处理器会全速运行，哪些会降速工作，哪些会在某些时刻关断，那么，很难估算SoC和DRAM的功耗或者温度。Thieret认为："很难预测功耗。总功耗等数据指标几乎与系统中的实际功耗不相干。您最好的做法是借鉴以前工程的经验，进行大量的测试。在FPGA行业以外，还没有很好的工具来进行早期功耗估算。"

　　谁在控制？

　　如果理解了many-coreSoC的性能和功耗是很大的挑战，那么，也就知道这些芯片的系统控制同样是棘手的问题。与前两个问题不同，对于异构、静态映射的系统，系统控制并不那么简单。也不能通过过度设计来解决这一问题。Thieret提醒说："系统控制是一个基本问题，随着处理器数量的增加，会越来越复杂。但是，您必须解决这一问题。"

　　最基本的难点在于将不同处理器中的任务与外部异步事件同步，例如，中断、调试信号或者掉电等。即使是以清晰数据流模型为主的静态系统，如果需要对某一处理器中的任务进行中断，以响应某一事件，那么，也很难弄清楚应该启动、暂停或者重新同步哪些任务。

　　在同构虚拟系统中，只有系统管理程序知道某一任务所在的位置，几乎不可能在正确的地方及时执行中断，在嵌入式操作系统中，会很难完成这一过程。系统设计人员可能要考虑中断的替代方案，例如，让一个处理器专门用于轮询外部事件，或者使用中断信号来启动新服务线程，而不是中断现有线程。这些方法都不能很好的解决SoC内部和外部之间复杂的仲裁问题。

　　初始化和关断是同样的难题。只是停止所有处理器上的所有线程，并不是一种好选择，这可能会破坏数据结构，或者使得受控机处于危险状态中。在出现电源完全失效等情况时，也会很难理解系统是怎样工作的。一开始就会很难。一些设计团队已经证实，能够设计无法初始化的芯片。一些设计支持有序启动，但是不在系统要求的时间范围内。Thieret看到："不同的应用有不同的需求。有时候，您有一个小时的重新启动时间，而有时候，只有四秒的时间。" Many-core计算的前景很直观：这是摩尔定律向前发展的唯一途径。而采用many-core SoC来实际实现系统时，在系统理解、估算、配置和控制等方面会带来很多新问题。SoC设计人员和系统设计人员一般通过参考设计来互相理解，这样才能够推动向前发展。