过去，逻辑验证是大多数SoC研发业者所遇到的瓶颈。因为SoC电路设计的快速攀升，让硬件验证工作的复杂度呈现急速激增的现象。

现在，嵌入式软件研发则是SoC研发业者在开发流程中所面临的最大挑战。目前SoC有超过五成的成本是使用在开发趋动程序、开机程序代码、与硬件相关的通讯协议堆栈、DSP算法及其他嵌入式软件。随着软件在新世代的设计中扮演愈来愈重要的角色，业者花在软件上的成本也会愈来愈多，如(图一)所示。

《图一 业者花在软件上的成本愈来愈多》

SoC所面临的难题，主要是实际芯片的开发与相关软件设计两者之间所存在的时间差问题。传统的SoC软件研发业者，必须等到硬件研发团队设计出实体的原型组件后，才有可供参考的硬件环境。因此，软件研发必须等到硬件工程师设计出完美的组件后才能动工。随着市场上产品生命周期的缩短，以及激烈的竞争压力，研发流程延迟不仅只是成本增加，更会影响产品获利。

SoC研发业者需要的是能减低这种在软、硬件设计上循序式进行的全新研发策略。这个策略可让SoC研发业者能快速的将通过验证的硬件IP整合到可量产的硬件核心系统。此外，它必须能建构在开放式架构上，让SoC研发业者能很容易的将这些不同的IP供货商所推出最顶级的IP组件紧密整合到其设计中。最后，藉由同步的软、硬件设计，能让SoC研发业者在硬件设计完成之前，提早进行软件撰写与除错作业，进而大幅减少研发成本与缩短上市时程。

平台式的设计流程

SoC与嵌入式系统的平台式设计方法，广获SoC研发业者与用户的支持，平台式的方法提供许多吸引人的优势。IC设计日趋复杂，加上65奈米以下微米制程衍生的许多物理效应，设计生产力逐渐落后，SoC设计的难度变得愈来愈高，导致SoC的设计成本大幅攀升。现在，设计大多使用可合成CPU核心，备有超过50万个逻辑闸，并采用可撰写数十万行程序代码的Linux嵌入式系统。SoC研发业者迫切需要一个可协助他们在最短的周期内，研发出第一次就成功的理想设计开发环境。

以平台为基础的设计方式提供高度整合的共享架构，让研发人员轻易且迅速开发SoC，并加入各项常见功能。此外，与其使用各种客制化的设计方法，不如运用预先设计与规划的组件。藉此能加快设计流程，排除持续攀升的上市时程压力。重复使用现有的IP模块，让组件成本可由多个SoC项目中均分，协助降低开发成本。

平台化模式也协助SoC设计业者应付越来越复杂的设计趋势，满足市场需求。平台化的架构让研发业者仅须加入或取代少量的IP组件，就能快速开发各种衍生产品。此外，预先整合的架构能减少在验证上可能会大幅增加研发团队工作量及不确定因素的风险。最后，在设计中运用其他已完成的模块，让研发人员能将资源投入在自己的核心技术上，专心发展与众不同的独特功能。

隔离硬件

加速软件开发的其中一项关键，是使用基本硬件接口，或硬件抽象层（HAL），让软件兼容性不影响的情况下能在任意更换底层的硬件。在理想状态下，也可以延伸至外部厂商提供的任何IP模块。目前多数的平台式设计方法采用HAL，将硬件与操作系统合作加以隔离，并提供一致的硬件平台，让应用软件不论在何种硬件组态下都能顺利运作。

在这个平台化模式中，HAL在软、硬件间提供一个抽象层。抽象层组件都有基本硬件核心，并内建各项关键功能可提高系统效能。这些组件包括内存子系统、中断、以及芯片内建互连接口。于硬件核心的最里层，含有一个采用交叉交换总线架构的系统控制器。这系统控制器能针对低延迟与高带宽应用进行优化调校。也为SDR与DDR/DDR2系统内存提供一个能以内存控制器链接到互连架构的高效能接口。此外，再搭配一个高度优化的L2快取控制器，能降低内存传输延迟并降低系统成本，如(图二)所示。

《图二 互连架构的高效能接口》

HAL也支持大多数嵌入式系统使用的常见周边组件，像实时频率（RTC）、串行端口（UART）、以及各种通用型I/O（GPIO）。能让设计人员选用不同厂商的周边组件，却还维持软件的兼容性。重要的是，硬件核心与HAL都是开放式架构，并为软件提供稳定的移植平台。

这种设计方法与其他平台式开发策略最大的不同，就是能简化趋动程序的开发流程。大多数的HAL都能弥补系统CPU差异。在此平台中，经过优化设计的HAL，还能弥补周边组件的差异。

以以太网络控制器为例，在高阶驱动程序的部份，都极类似。在低阶驱动程序的部份，为让特定的控制器能支持所需要的功能或达到最高的速度，程序撰写的方法就有明显的差异。在此新平台模式中，驱动程序的低层部份归属在HAL内。驱动程序被整合到平台的IP模块中，软件只需将上层部份的驱动程序移植到API，由API与低层的驱动程序组件进行互动，如(图三)所示。

《图三 API与低层驱动程序组件进行互动》

此开发策略大幅简化驱动程序的开发流程。由于软件移植平台在HAL API方面都一致，只要控制器支持相同的作业环境，不论研发人员为了避免修改驱动程序而选择何种以太网络控制器，就不会有任何问题。针对每个支持的运作环境，研发人员仅须开发一个驱动程序即可。这不仅简化驱动程序的开发流程，也藉此缩短产品上市时程，更确保硬件组件维持兼容。

降低效能的下降幅度

SoC研发业者在运用整合不同厂商IP组件的平台化设计方法时，所面临的一项重要问题就是在重复使用功能组件时，为了享受弹性与便利性，必须牺牲多少效能。在大多数平台式设计方法中，研发人员常得为了享受通用API所带来的便利性与弹性，而牺牲可观的效能。此新设计方法将针对不同种类的组件使用不同的API，藉此大幅减少效能下滑的幅度。例如，使用针对因特网控制器进行优化设计的API，以及另一种针对DSP控制器进行优化的API，让平台能透过一个特性化的模块来满足这些特殊功能的效能需求，并同时维持使用同一个API所带来的便利性及加快研发流程的利益。在这项情况中，研发人员可将高阶的组件驱动程序移植到HAL API中成为特定类型驱动程序。如此，针对每个作业环境，每个驱动程序仅须撰写一次。自此之后，即可任意更换硬件，而不必修改任何软件。

此法与其他设计模式间的重要差异，就是让设计人员有机会运用一个SoC设计开发出多个衍生产品。以往，较高抽象层的软件模型，都无法提供足够的效能，来支持真正软硬件共同设计的模式。但近来ESL技术的演进，让业界克服这项限制。

有别于其他模式，这项平台能从设计流程的初期，一直到完成RTL的设计开发，全程支持虚拟系统模型的设计工作。同时，它也让设计人员在各个研发阶段，能将平台视为一个虚拟系统模型、仿真机板、或是实际的SoC。平台由可合成的RTL模式实现，或由SystemC模型仿真抽象层中不同种类的组件。这些模型也兼容于市面上常见的电子系统层级（ESL）工具。

能在不同抽象层级中存取相同IP模块的内容，加上确保软件不必修改就能继续运作，是胜过现有平台设计方法的重要优势。这让硬件平台能在不同的研发阶段中，提供稳定的软件移植环境。更重要的是，将平台汇入到一个虚拟系统原型ESL模型中，让研发人员能在软件检验流程的初期就开始工作。透过这些模型，研发人员可检验系统模型的链接状况，相较于传统的设计方法，能提早在设计周期阶段就展开软件的设计工作，而且早在硬件完成设计之前就开始撰写程序。

结论

透过这些模型，研发人员可检验系统模型的链接状况，相较于传统的设计方法，能提早在设计周期阶段就展开软件的设计工作，而且早在硬件完成设计之前就开始撰写程序。

这样的平台式设计方法，让设计业者朝这个目标迈进一大步。尽早发展出代表整体设计的原型方案，能早在硬件完成设计之前，就展开费时的软件设计程序。此平台运用创新的模式来隔离软、硬件的设计，并简化不同厂商IP的整合工作，大幅加快软件设计流程。

---作者为MIPS Technologies技术长---