Nios Development Board Reference Manual, Stratix II Edition
在使用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暂不支持一起暂停、再继续,“一起”不是“同时”。
Nios II Flash Programmer User Guide
关键点在于:
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文件。)
Avalon总线
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版本的升级担心,这放开了我们的“思维”约束。
温馨提示:内容为网友见解,仅供参考