如何在硅芯片制作完成前进行软件开发

驱动程序代码使用宏readl和writel对寄存器进行读写。这些在linux内核中定义的驱动程序被作为一种访问硬件的方式。但假如启动了一个新的驱动程序，你就可以在本地进行重新定义，以得到所需的响应。例如:

你无需访问实际硬件，便能开始进行软件开发。当然，你也可以采取极端的做法，使用这种方法来建模一个完整的外围设备，但无论如何请不要尝试最简单的外围设备，因为那样很容易产生故障。一旦出现握手失败而采样仍然在进行，系统可能会丢失某些返回值。

假如处于虚拟环境，如QEMU或ARM快速模型(AFM)——基础模型的付费版本，你可以引进更加复杂的模型。AFM连接了System-C，相比于存根代码(stub-code)，这是一种更适宜于建模硬件行为的环境。QEMU也可以扩展模型，但经验不是凭空而来的，需要经过多次实践。与许多开源项目一样，代码即是文档。若使用了QEMU，但又不想在一团糟的C代码中苦苦挣扎并尝试理出头绪，那么一旦你需要超越存根代码，你可能想要跳过这个阶段。

很多情况下，无法使用存根代码进行验证，甚至连你为软件运行所创建的更复杂的System-C模型也无能为力。例如，你无从得知硬件团队和软件团队在设备中使用的是否为同一个寄存器映射。通过一个不会做出任何意料之外的反应的寄存器，你根本无从验证其设置是否正确。如果你同时编写驱动程序和相应的外围设备模型，那么也只能证明你对二者的理解是相吻合的。

虚拟样机系统，如Mentor Graphics的Vista，可用于创建你所需的更复杂化的模型。一般情况下，这些模型的处理速度非常快，软件运行也很顺畅。如果硬件团队创建了虚拟样机模型，那么在该模型上运行软件时，便能验证软硬件团队的设计观点是否相符。通常情况下，二者的设计观点是存在差异的。若能尽早发现这些差异，则在设计周期的后期可避免不少麻烦，让你不至于抓狂。在一个软硬件都很容易调试的工具中，要实现这一点其实并不难。

虚拟样机有一个你所开发的软件外围设备的完整功能模型。你将能以创建终极目标系统同样的方式来创建自己的软件，还能访问外设的寄存器，就像在真实的硬件上运行一样。此外，通过虚拟样机可以直接查看这些外设寄存器，在无任何干扰的情况下，调试过程变得更容易。你将能充分地编写驱动程序并验证其运行是否正常。你甚至还可以粗略计算出总共所需要的时间。然而，精确的验证时间的计算，还需等到与硬件更匹配的软件问世。

需要记住的是，虚拟样机并不是真正的硬件，而只是一个模型。模型(以程序的形式)需要由设计师来编写，但设计师所编写的程序偶尔会出现错误。还需要注意的是，硬件在一个很抽象的层面上建模，这可以引发实际硬件的微妙、却又至关重要的差异。因此，即使驱动程序完全验证了虚拟样机，你的工作仍然没有结束，还需要在更详细的硬件环境中进行验证。