在二○世纪九十年度末，可编程逻辑器件（PLD）的复杂度已经能够在单个可编程器件内实现整个系统。完整的单芯片系统（SOC）概念是指在一个芯片中实现用户定义的系统，它通常暗指包括片内存储器和外设的微处理器。最初宣称真正的SOC――或可编程单芯片系统（SOPC）――能够提供基于PLD的处理器。在2000年，Altera发布了Nios处理器，这是Altera Excalibur嵌入处理器计划中第一个产品，它成为业界第一款为可编程逻辑优化的可配置处理器。本文阐述开发Nios处理器设计环境的过程和涉及的决策，以及它如何演化为一种SOPC工具。
Altera很清楚地意识到，如果我们把可编程逻辑的固有的优势集成到嵌入处理器的开发流程中，我们就会拥有非常成功的产品。基于PLD的处理器恰恰具有应用所需的特性。一旦定义了处理器之后，设计者就“具备”了体系结构，可放心使用。因为PLD和嵌入处理器随即就生效了，可以马上开始设计软件原型。CPU周边的专用硬件逻辑可以慢慢地集成进去，在每个阶段软件都能够进行测试，解决遇到的问题。另外，软件组可以对结构方面提出一些建议，改善代码效率和/或处理器性能，这些软件/硬件权衡可以在硬件设计过程中间完成。
处理器体系和开发流程
Altera很早就认为创建基于Nios处理器的系统和处理器本身一样很重要。随着新生产品逐渐成熟，Altera必须让嵌入设计者信服地接受新的处理器和新的设计流程。我们最无法确定的是嵌入设计者是否接受新的指令集。随着C成为嵌入设计的事实标准，这一问题也迎刃而解。Altera和Cygnus（现归RedHat所有）密切合作定义指令集体系，这样Cygnus可以很容易地导入和优化他们的GNUPro Toolkit，这是绝大部分设计者非常熟悉的标准GNU环境。
设计流程成为最大的问题。现成的微控制器提供了定义明确的外设组，由制造商集成处理器和外设。可配置处理器让设计者自行创建总线体系，定义存储器映射和分配中断优先级，非常自由地完成更多的工作。Altera相信SOPC的优势会吸引嵌入设计者，但是条件是其它的需求最小，风险很低。
进入SOPC Builder
我们认为减轻设计者负担的最佳途径是把所有和处理器子系统相关的底层详细资料集中到单个工具中。我们设计这样的工具叫做SOPC Builder，有两方面的考虑：第一，它必须具有直观的图形用户接口（GUI），便于设计者准确地添加和配置系统所需的外设――包括存储器，定制外设和IP模块。第二，它必须自动完成系统集成工作，这样设计者不必拘泥于定义存储器映射，中断控制和总线控制这样的“制造商工作”。
GUI是更大的问题。它必须是直观的，允许设计者配置复杂的系统。除了提供软件和集成的OS之外，这还包括定义具有多总线主设备，总线仲裁和DMA控制的系统。我们幽默地称之为“库－表接口”，它能自动地把部件添加到系统中。用户从有效外设库中来选择，这个库在SOPC Builder窗口的左边（见图1）。然后，外设出现在当前系统的部件表中，这个表在SOPC Builder窗口的右边。每个外设可能会启动一个配置向导，指导用户为这个系统配置外设的功能。
部件表GUI允许用户输入每个外设基地址和中断优先级（SOPC Builder也可以自动进行分配）。最后，我们需要直观地连接总线体系，分配从设备端的仲裁优先级。我们的解决方案成为“接插板”，见窗口的中部。垂直线代表主设备;水平线代表从设备。接插板让用户制定主设备和从外设之间的连接，还可以外不同的主设备分配权重。这些权重定义了每个竞争主设备如何访问从设备。
自动生成和集成软件和硬件
当用户点击“Generate”按钮时，SOPC Builder会生成每个硬件部件以及连接部件的片内总线结构，仲裁和中断逻辑。SOPC Builder也会产生系统可仿真的RTL描述，以及为特定硬件配置设计的测试平台，能够（可选）把硬件系统综合到单个网表中。
拥有了这些合适的部件，我们觉得自动硬件生成过程基本满意，但是我们还需要满足软件设计者的要求。利用设计过程中采集的信息，我们设计的SOPC Builder能够生成C和汇编头文件，这些头文件定义了存储器映射，中断优先级和每个外设寄存器空间的数据结构。这样的自动生成过程帮助软件设计者处理硬件潜在的变化性。如果硬件改变了，SOPC Builder会自动更新这些头文件。SOPC Builder也会为系统中现有的每个外设生成定制的C和汇编函数库 。例如，如果系统包括一个UART，然后SOPC Builder就会访问UART的寄存器定义一个C结构，生成通过UART发送和接收数据的C和汇编例程。
系统扩展
在对Nios处理器客户进行支持的第一年中，我们更深刻地理解了我们在SOPC Builder中所创建功能的特性。我们发现一些设计者――尤其是提供Nios相关产品的产商――想把他们自己的部件添加到SOPC Builder列表中。他们想把SOPC Builder作为集成和重用他们自己专用模块的设计工具，而不是把处理器简介到SOPC Builder提供的标准外设。 为了满足这种要求，我们开放了SOPC Builder流程的硬件和软件接口，允许第三方象Altera一样有效地管理SOPC部件。
我们围绕着开放可扩展标准重新设计SOPC Builder，这个标准能够生成和连接定制模块，我们称之为“部件”。在这个标准下，我们定义了系统配置文件格式叫做System PTF文件。该文件是系统的配方，它定义了SOPC Builder生成完整系统必需的详细信息 。我们还定义了部件专用信息的文件格式，叫做Class PTF文件。Class PTF包含SOPC Builder配置和生成部件所需的详细信息。
图2是SOPC Builder利用Component PTF文件和System PTF文件配置和生成系统的流程。SOPC Builder设计流程有两个阶段：配置――框图左边所示，和生成――框图右边所示。SOPC Builder GUI引导用户完成两部分的配置：分别配置每个部件，整体配置系统。部件配置需要汇总参数，所以Class PTF文件标准包括了为这一要求定义GUI的格式。 当需要时，SOPC Builder读取该格式，产生相应的部件向导（Component Wizard）收集所需的用户数据。SOPC Builder然后把收集的参数值存放在System PTF文件中。
配置的另一部分是系统配置，用户提供的有关处理器配置，外设连接等数据写入System PTF中。当这两部分配置都完成后，SOPC Builder进入到生成阶段，生成设计的输出文件。SOPC Builder查阅每个Class PTF文件，允许相关的部件生成程序，它们会正确地输出特定系统配置的硬件和/或软件文件。
简单的部件生成程序可能每次都会输出相同的文件;更多的可配置部件根据用户输入会生成完全不同的结构。例如，Nios处理器中包括的UART可以配置为软件控制波特率，以更多门换取更大的灵活性。这种配置选项由用户在部件配置阶段进行设置，根据这个设计，UART生成程序产生所需UART的硬件描述。在生成阶段的最后一步，SOPC Builder创建适合于系统部件的总线结构，把所有的部件连接在一起。
SOPC Builder：现在和未来
在开发和完善我们基于PLD处理器的工具的过程中，我们发现更令人感兴趣的最终结果并不完全是处理器。例如，让IP制作者制定有关IP应该如何连接的细节――这样能够减轻用户为每个设计项目重新再设计（或总线结构）的工作量――SOPC Builder让传统硬件IP具有意料之外的价值。而且，通过追踪整个系统的配方，我们就能够用SOPC Builder透明地调整相应的系统软件反映硬件配置的变化。
在SOPC Builder下，软件也认为是一个部件，支持便捷地添加OS。例如，如果你把RTOS作为一个部件添加到你的系统中，RTOS部件的生成程序会检测系统中硬件以太网接口，包括TPC/IP软件库。同样地，它会检测IDE接口，包括文件系统库和IDE器件相应的驱动。最后生成器为你编译RTOS内核。
虽然我们是从新的处理器和相应的开发流程开始切入，但是SOPC Builder的概念和客户期望远远超过了新的处理器。这触及到数字系统设计每一方面，从定义独立的硬件部件，到把它们自动地智能地连接起来，到处理器上运行的软件。在PLD设计发展过程中，在PLD内实现CPU是必由之路，但是让基于PLD处理器可视化的工具流程也促进了可编程单芯片系统的设计。
结论
SOPC已经成为现实，然而SOPC能否存活下列更多地取决于设计流程而不是单独的部件或处理器。象SOPC Builder这样的自动集成工具已经具备了为主流PLD用户提供芯片系统设计的能力。Altera推出SOPC Builder工具，提出了PLD的最高度设计抽象，弥补了软件和硬件同时集成的空白。我们正处于SOPC即插即用时代前沿，其间处理器，IP模块和软件能够一起“工作”。
