EEPW论坛

 
  通常，如果某家公司通过某种独有的或特别的方式取得商业成功的话，这种“独有的或特别的方式”往往会被定义为“商业模式”。如果嵌入式软件公司定义好目标市场，芯片规格，寄存器描述，启动代码等等后再交由硬件设计公司去完成芯片和系统并且取得了商业上的成功呢，这种模式是否同样可以用“商业模式”来定义？

　　任何“商业模式”都是一种获利手段，其目的在于“创造效益最大化”这一结果。没有一种“商业模式”是这样的：不知道何时能够产生效益直到它开始产生效益。从国内首家也是目前唯一一家上述做法的公司“吉芯”（详见本刊3月期《吉芯模式：由软件厂商定义芯片功能》文）的情况来看，在同Spansion和方舟科技达成合作之前，他们已经整整两年没有任何业绩回报。如果要把这种模式定义为“商业模式”，那这个结果显然是不合常理。

　　事实上，软件主导硬件设计的过程从根本上改变了设计流程，以及设计公司产业链的角色分工。它绝不仅仅是某个公司的个体现象，而是预示着一种全新的设计形态正在形成，并由此对整个上游设计生态圈产生深远的影响。

　　传统上，嵌入式软件设计一直由硬件系统主导，软件工程师根据硬件系统进行功能开发。主流的系统设计流程包 
括“瀑布模式”和“V模式”。前者的流程是：需求分析-硬件设计-硬件调试-软件设计/编程-软件调试-最终产品。这种模式较适合小系统以及开发周期要求不高的情况，对人力和物力资源的要求不高，但要求开发人员熟悉软、硬件设计和制作，而且整个开发周期长，其中任何一个环节出问题都会影响整个开发进程。“V模式”将软硬件设计环节调整为同时进行，软硬件调试也同时进行，在缩短开发周期的同时降低了软硬件开发过程中单个环节出现问题对整个系统开发的影响，显然，这种模式可以满足大系统的开发。虽然“V模式”解决了“瀑布模式”存在的问题，但它自身也有一些问题，比如设备驱动程序的可移植性不高，同硬件和OS存在密切的相关性；软件测试需要等硬件完成后才能进行；对每个设备驱动程序设计人员的软硬件知识都有较高要求，以及难以判断测试中的问题属于硬件还是软件等。有些公司为了解决这些问题，在硬件平台和驱动程序之间增加硬件抽象层将软硬件隔离，通过这种方式提高系统软件的可移植性，并提高软硬件调试的可靠性和灵活性。

　　不难看出，基于系统硬件进行系统软件开发的系统开发流程始终都在面临开发周期和可靠性的问题。对于系统开发人员而言，那些面向硬件的，只有少部分软件内容并且大多是基本汇编语言的单片机系统开发还好对付，但高性能嵌入式CPU的开发就要复杂很多。嵌入式CPU要求其上面运行的软件能够实现更复杂的功能，需要OS对CPU及其外围设备进行管理，支持多任务、多线程的设计模式等。事实上，在传统开发流程下，软件工程师也一直面临着硬件平台的不断升级、软件功能复杂程度大幅增加和开发周期的不断缩短的多重压力。

　　从系统开发的可靠性和周期出发，我相信基于完整系统软件进行硬件系统设计的开发模式即使不是唯一也是少数能够解决问题的方式之一。当32位嵌入式CPU逐渐向某几类架构集中时，由软件来定义硬件系统变得越来越切实可行，嵌入式软件开发公司应该看到这样的机遇。

　　当然，我并不想把这个设计流程上的变革视为软件公司和硬件公司话语权的转变，硬件设计公司是否会沦为“设计代工者”？这问题可能永远属于那些资源有限的硬件公司。象TI这样的公司不正在把他们公司的定义从“系统芯片供应商”向“系统平台供应商”转移吗？也许MediaTek和Sigmatel的人力资源经理会告诉你，作为硬件供应商，他们的开发人员中，软件工程师早已过半。从客户端出发的理念正在把“平台化”和“新的软硬件设计流程”统一起来。当我们关注“软件主导硬件设计改变了什么”时，答案也许不是“主从关系”，而是“新的价值体系”。