在使用Nios II SDK Shell试运行./restore_my_flash时，发现restore_my_flash会区分目录名的大小写，因此使用Nios II SDKShell时最好注意大小写一致。

　　restore_my_flash.pl为perl脚本，可以直接修改后直接执行。

　　restore_my_flash不能正常取得命令行参数，但这不影响恢复出厂设置的操作，因为restore_my_flash可以不依靠命令行参数来 执行。

　　最好不要移动NiosII的安装目录，例如restore_my_flash就会从目录名中提取内容生成需要的文件名。

　　恢复出厂设置需 要.sof和.flash两个文件，估计.sof用于生成最小的nios系统，以便将.flash文件下载到Flash中。 (restore_my_flash提示使用J24 JTAG连接器，该连接器是用于配置StratixII器件的。)

Creating Multiprocessor NiosII Systems Tutorial

在standard设计的基础上修改了Nios II系统，又添加了两个Nios II处理器及各自的定时器、共享互斥锁、消息缓冲区。编译、运行和调试了hello_world_multi程序。

　　SOPC Builder中设置的NiosII的Reset和Exception地址很重要;

　　QuartusII生成的编程文件中包含有NiosII处理器的 复位地址;

　　NiosII IDE的编译会生成绝对地址的代码和数据;

　　NiosII IDE通过NiosII处理器中的jtag_debug_module重定向程序的执行地址;

　　上电或复位后，NiosII处理器从复位地址(通常指 向Flash)处执行Boot Loader，将程序拷贝到Ram中并在Ram中执行;

　　Exception地址确定了程序拷贝到Ram中的位置，Exception地址的低位总是 0x20，NiosII处理器跳转到Ram执行时先执行低位地址为0x00的指令(用于初始化指令cache)，之后执行低位地址为0x20处的系统启动代码。

　　Nios II多处理器设计的注意点：

　　不支持SMP(对称多处理)，只支持不对称的(每个处理器执行不同的程序);

　　处理器之间可以不共享资源;

　　同一程序存储器中的各处理器的代码空间不能重合(通过Reset和Exception地址实现);

　　共享数据存储器最好用硬件共享互斥锁 结合软件操作的方式来实现，不支持纯硬件的共享方式(如果软件不使用硬件互斥锁，仍然会有访问冲突)，纯软件的共享方式有使用限制并且较复杂;

　　软件 共享互斥锁只适用于同一处理器的不同进程之间共享资源;

　　Nios II HAL library不支持共享外设(涉及中断处理、外设输入数据的处理等)，Altera建议由固定的处理器管理相应的外设，其他处理器要使用该外设可以通过 消息缓冲区的方式;

　　不同于单处理器设计，多处理器设计一定要明确规定每个组件的总线连接点;

　　只要由不同的处理器访问，两个组件可以有相同的地址;

　　由设计人员保证各处理器使用的代码空间是足够的、不发生覆盖的;

　　多处理器的软件的运行、调试可以一起或分别启动、终止，NiosII 5.0暂不支持一起暂停、再继续，“一起”不是“同时”。

Quartus II的Programmer只支持FPGA和配置器件;

　　Flash Programmer只支持CFI接口的Flash或EPCS配置器件，但可烧入配置文件、软件代码和任意数据;

　　使用Flash Programmer需要生成Target Board及生成Flash Programmer可编程逻辑设计，并在实际项目SOPC Builder流程中指定该Target Board;

　　Boot-Copier Program是Nios II IDE自带的，当软件代码位于Flash或EPCS中时由Flash Programmer自行使用，不同的是对Flash而言Boot-Copier Program放在Flash中，对EPCS而言Boot-Copier Program放在EPCS serial flash controller包含的on-chip ROM中;

　　上电或复位时，Nios II从Boot-Copier Program开始执行(不论是Flash或EPCS)，这要求SOPC Builder流程中指定复位地址为Flash或EPCS serial flash controller。

Simulating Nios II Embedded Processor Designs

仿真NiosII设计包括三种方式：“NiosII IDE Debugger + Signal Tap II + 物理板”的软硬件联调方式;“NiosII IDE Debugger +指令集仿真器ISS”的软件调试方式(ISS可对部分组件建模);使用ModelSim-Altera进行的RTL级的功能仿真方式(可以调试处理器及其 外设之间的交互情况)。本文针对RTL级仿真方式。

　　存储器的初始化：含有软件代码的存储器都应被初始化，不论是片上还是片外存储器;软件代码相关的存储器初始化文件由NiosII IDE编译软件时生成。

　　JTAG UART和PIO在SOPC Builder中都可设置仿真选项，ModelSim-Altera还可根据仿真选项调出UART交互终端窗口。

　　需要在SOPC Builder中设置ModelSim的路径和使能Simulation，之后SOPC Builder会生成仿真用的ModelSim项目文件、ModelSim宏命令、UART等组件的初始化文件。

　　需要在Nios II IDE中为System Library属性打开“ModelSim only,no hardware support”开关，这样在编译软件时才会生成代码相关的存储器初始化文件，但生成的代码不含启动代码(指令和数据Cache没有初始化、BSS段也不清除)，以便加速仿真。因此，如果要下载代码到硬件板，必须关掉“ModelSim only,no hardware support”开关并且重编译，以便生成完整的代码。

　　在Nios II IDE中以NiosII ModelSim方式运行(需设置ModelSim的路径)，将使ModelSim编译setup_sim.do并接管后续的仿真运行工作。

　　较重要的ModelSim宏(SOPC Builder生成)：s、w、jtag_uart_drive。

　　一定要从Nios II IDE运行ModelSim，jtag_uart_drive宏才能正常运行。其他仿真步骤都可单独使用ModelSim打开该项目，在执行完setup_sim.do后运行。

　　应该可以在SOPC Builder生成TestBench文件后修改该文件，以便进行Nios II和片上其他逻辑的联合仿真。(因为是SOPC Builder生成的TestBench文件，并没有在Quartus II中生成，所以不一定是完整的片上设计的TestBench文件。)

NIOS和NIOS II都使用了Avalon总线，这是一种交换式架构的片内总线;

　　该总线形式和PCI、ISA等板间互连总线的最大区别在于：主从设备之间有紧密耦合关系。Avalon总线架构中，由硬件设计人员通过SOPC Builder规定互连的主从设备(包括数据、控制信号、片选、地址的互连)，不连接的设备之间是互相看不到的。

　　每个Avalon主设备端有多路复用器，用来从多个从设备的数据总线中选择当前要访问的数据——这也是“交换”的含义所在。可见多路复用器的接口引 线相当多，这只能在连线资源丰富的FPGA内实现。所以说，Avalon总线架构是适用FPGA设计的。片外的交换式总线也有，但都是串行接口的，主要是 为了降低PCB布线难度，如：PCI Express、以太网等。由于，Avalon总线架构中所有设备没有实现全互连，也就不存在“全交换”。但即使这样，不同的主设备访问不同的从设备也是 可以同时的、并发的。

　　每个Avalon从设备都有仲裁器，仲裁各主设备的访问，确保访问周期的完整性和正确性。我们可以认为访问周期是“原子”的，即不被其他主设备破坏的。

　　软件对共享资源的访问，通常要求一个序列的多个访问不能被其他CPU打断，这不是“原子”级的访问周期设计能保证的，这也是SOPC Builder中提供了硬件共享互斥锁的由来。

　　各CPU上运行的软件都可对某个硬件共享互斥锁进行SET和TEST操作，以争取对资源的占用能力。由于对硬件共享互斥锁的访问周期是“原子”，所以硬件共享互斥锁能保证多CPU设计中软件级别的共享资源互斥访问。

　　NIOS II设计的灵活性是我感兴趣的主要原因。只要有足够的逻辑资源余量，NIOS II的设计是可以不断更新的，设计人员不用为自己的设计能力、CPU版本的升级担心，这放开了我们的“思维”约束。