NIOS II嵌入式处理器经常与其他嵌入式处理器一起配合使用。如果NIOS II处理器程序比较小，可以将NIOS II处理器程序存放在FPGA内部的ROM/RAM中。但是FPGA内部的存储器资源通常都很宝贵，不能用来存放应用程序。在这种情况下，要为NIOS II处理器和外置处理器都配置Flash闪存，这种设计符合常规，但是增加系统成本，还增加单板面积。

本文介绍一种更好的设计方案，可以省掉NIOS II处理器系统的闪存，从而降低系统成本。这种方案把NIOS II处理器和外置处理器通过某种通信端口连接，如串口、I2C等；然后在FPGA内部存放一个很小的系统引导模块；NIOS II处理器系统启动后执行引导模块；引导模块再通过通信端口，从外置处理器取得应用程序代码；应用程序加载完成后，NIOS II处理器再执行应用程序。系统引导模块专门针对大小做了优化，占用的ROM空间很小，只有2KB左右，所以基本不会浪费FPGA的资源。对应地，外置处理器也要运行一段代码，将NIOS II处理器的代码从自己的存储空间读出，传送给NIOS II处理器，一般称这段代码为加载服务器。

图1  无闪存的NIOS II处理器系统示意图

嵌入式系统中，最常用的低成本通信端口是串口，所以先用串口实现了无闪存的NIOS II处理器系统。在设计中，兼顾了代码在不同类型通信端口上的可移植性，保证片上系统引导模块和加载服务器可以容易地移植到其他类型的通信端口，如I2C等。

设计时，为了使片上系统引导模块最小，尽量简化片上系统引导模块。如果可能，在加载服务器中实现尽量多的功能。

片上系统引导模块和加载服务器之间使用简单、可靠的握手协议。先由加载服务器向NIOS II嵌入式处理器发送引导开始(Boot Start)标志，NIOS II处理器收到开始标志后，发送确认消息。加载服务器接着就将NIOS II处理器的应用程序分成帧发送。NIOS II处理器收到应用程序的数据帧后，也发送确认消息，再将数据存放到对应的内存位置。应用程序一般分成多个帧发送，所以加载服务器和NIOS II处理器片上系统引导模块在处理应用程序数据帧时可能需要循环多次。发送完应用程序后，加载服务器再引导结束(Boot Completion)标志；NIOS II处理器接收到引导结束(Boot Completion)标志后，发送确认，然后跳转到应用程序入口处开始执行应用程序。如果加载服务器不能及时收到NIOS II处理器引导模块的确认消息，将重发数据；NIOS II处理器引导模块也可以主动发送重传消息，以节省加载服务器的等待时间。如果有必要，加载服务器还可以发送命令，重新启动整个加载流程。引导模块和加载服务器的握手协议的处理过程如图2所示。

图2  引导模块的加载服务器的握手协议

不同的应用程序可能放在地址不同的内存区域；在同一个应用程序中，不同的代码和数据段也可能放在地址不同的内存区域。所以应用程序的数据帧中应该含有数据的存放位置。不同的应用程序，入口地址可能不一样，所以引导模块需要从加载服务器得到应用程序的入口地址。为了简化设计，规定第一个数据帧的地址就是应用程序的入口地址，即第一个数据帧必须是应用程序的起始代码。

为了保证数据的可靠性，还要校验数据的正确性。所以每帧的最后两个字节，是数据的校验和。综合考虑，NIOS II处理器片上引导模块采用了如下的数据帧格式。

为了提高效率，应用程序的数据使用了二进制数据传输。如果采用S-Record中的字符传送，二进制的64B数据需要128B来编码。加上标志、目标地址等数据，需要在串口中传输的数据总共有140B，效率只有46%。而采用二进制数据传输，需要在串口中传输的数据只有76B，效率达到84%。考虑到串口等通信接口传输速率本来就偏低，所以NIOS II处理器片上加载模块在数据帧中使用了二进制格式的数据。为了提高效率，可以增加数据帧中应用程序数据的长度。如果应用程序数据的长度是256B，效率可以达到95.5%。

加载服务器到引导模块方向的数据量很大。为了使NIOS II处理器从巨大的数据流中正确识别出各种标志，使用32位的标志。引导模块到加载服务器方向只要确认信息或者重传消息，所以用8位的标志即可。发送时，所有数据都是高位字节先发送，低位字节后发送。如果某个数据帧中的目标地址是0x00102030，则在串口上依次发送的是00、10、20、30。

为了提高可移植性，加载服务器和引导模块的代码中都使用接口无关的通信接口。加载服务器和引导模块都使用的接口有loader_comm_init、loader_comm_rxchar、loader_comm_txchar。另外，加载服务器还多两个接口loader_comm_flush、loader_comm_rxchar_timeout。其中，loader_comm_flush用于清空通信端口的缓冲区中的数据，加载服务器发送任何一帧数据前都要清空接收缓冲区，避免旧确认消息被误认为是后续帧的确认消息。有了缓冲区清空机制，确认消息中就不用含有帧的序号，简化了设计。loader_comm_rxchar_timeout提供了超时退出机制，用于接收从NIOS II处理器系统返回的确认消息。这些接口都是为了提高可移植性而增加的中间层。为了提高效率，都把它们设置成了inline类型。系统中可能使用I2C等通信端口，只要在通信端口的驱动程序中实现同样功能的接口，再在上述匹配接口中调用，就可以实现在不同类型的通信端口间的移植。

加载服务器侧需要存储NIOS II处理器系统的可执行文件，GCC编译器输出的文件是ELF格式。为了简化加载服务器设计，可以将ELF文件转换成S-Record格式；甚至直接转换成在通信通道上传的帧格式，以节省加载服务器侧的存储空间。目前的加载服务器只支持S-Record格式。S-Record中有S1、S2、S3类型的record含有数据，区别在与地址字段的长度。

NIOS II处理器及其外设非常灵活，串口不仅支持标准波特率，还支持各种非标准波特率。如果外置处理器也支持非标准的串口波特率，就可以大大提升软件的加载速度。

在NIOS II处理器的开发板上实现了无闪存的NIOS II处理器系统。在FPGA中，实现了两个NIOS II处理器。第一个处理器的外设只有片上ROM、DRAM和IO接口，运行片上加载模块。第二个处理器的外设有Flash闪存、SRAM和IO接口，运行加载服务器，并存放第一个NIOS II处理器的应用程序的S-Record文件。系统启动后，第一个NIOS II处理器成功地从第二个NIOS II处理器获得了应用程序，执行应用程序也正常。

通过从外部CPU加载NIOS II嵌入式处理器的应用程序，可以大大降低系统成本，也可以减小单板面积，这样能够扩展NIOS II处理器的应用范围。