Nios® V/II Embedded Design Suite (EDS)
Support for Embedded Development Tools, Processors (SoCs and Nios® V/II processor), Embedded Development Suites (EDSs), Boot and Configuration, Operating Systems, C and C++
12596 Discussions

Qsys CFI (Common Flash memory Interface) is missing connections

Honored Contributor II

Having a problem with the Qsys CFI memory interface: when a CFI interface is added to a Qsys Nios system, there are very important memory control lines that are not "brought out" of the system, specifically the lines shown in the Cyclone III Device Handbook page 9-26 (DCLK, Reset_L, Wait, and ADV_L).  


How does one get Qsys to present these control lines? 


To demonstrate the problem create a simple Qsys embedded system with a Nios II CPU, a FLASH and a RAM. Instructions below are for the Quartus II 13.1 Web Edition: 


  1. Start a new Quartus II project using the new project wizard. Choose a Cyclone III EP3C40F780I7. 

  2. Open Qsys under the Tools menu 

  3. Add a Nios II processor (Economy version) 

  4. Add a JTAG UART (as always), connect it's clock, and connect it to the Nios instruction-master and data_master. Also, wire in the JTAG UART's interrupt to the Nios processor 

  5. Add a System ID (as always), connect it's clock and connect it to the Nios data-master. 

  6. Add a Generic Tri-State Controller for a FLASH memory and select and apply the "Preset" for the Flash Memory Interface (CFI) and press "Finish" to accept the default parameters. 

  7. Add a Tri-State Conduit (to bring the address, data, and memory control lines out of the cpu system) and export the signals by entering a name "flash" in the export column 

  8. Connect the Tri-State controller and bridge together (connect the tcm to tcs). 

  9. Connect the Flash Tri-State Controller to the data_master and instruction_master of the Nios processor 

  10. Connect the clocks of the controller and bridge to the system clock. 

  11. Connect the reset lines of the controller and bridge by having Qsys Create Global Reset Network (under the System menu item). 

  12. Add a second Tri-State Controller for an SRAM, select the Preset for the IDT71V416 SRAM and press the Apply button, press finish to accept the defaults. 

  13. Add a second Tri-State Bridge for the SRAM & "wire" up the SRAM controller to the bridge 

  14. Connect the Tri-State Controller to the Nios data-Master and instruction-master 

  15. Wire in clocks, again. 

  16. Wire in the resets by using System - Create Global Reset Network 

  17. Assign the base addresses for all the components added above by letting Qsys assign base addresses. Select "Assign Base Addresses" under the System menu. 

  18. Generate the system. When asked, give it a name like "CPU_1". 



At this point Qsys has a very simple embedded system with a flash for FPGA configuration (and an application) and a SRAM for scratchpad or even running the system out of. This is about as simple as it gets. 


After generating the system above, close Qsys and go back to the Quartus software. Add a new Block Diagram/Schematic File and immediately save it with a file name like "Top_System". 

Add the Qsys designed processor. Unfortunately, the Qsys designed system will show up without those very important memory control lines.  


It seems important to have the normal memory lines (address, data, read, write, etc.) brought out to the top level design and it is also important to bring out the key control lines of ADV_L, CLK, RESET_L, and WAIT so they can be assigned to pins on the part. 


Anyone have any suggestions? 


There may be a related problem: if the address and data buses that are brought of of the Qsys system are assigned to the pins on the actual part (such as DATA0....DATA15), there will be errors that say two signals are being assigned to a single pin. It looks like Quartus somehow already has the FLASH memory assigned to the appropriate pins. 


The big goal here is to design an FPGA with a Nios processor based system that configures both the FPGA and boots the Nios application (written from within the Exclipse environment of Altera's Software Build Tools) from a parallel CFI flash in the AP (Active Parallel) mode. 


Thanks in advance!
0 Kudos
1 Reply
Honored Contributor II

Found the problem: 


Altera does not support synchronous operations with FLASH memory. Apparently, FLASH memory access is all done asynchronously even during FPGA configuration memory access. So, to make it work, hold the memory's four synchronous control lines (DCLK, RESET_L, WAIT, and ADV_L) in their un-asserted states on the board. A quick review of the Nios Embedded Evaluation Kit (NEEK) will show this being done, with the appropriate pull up resistors.  


Regarding the errors with the pin assignments, the problem was with the configuration setting for this particular project. To configure an FPGA using a parallel flash with the Cylcone III device, Quartus must be told to use the Active Parallel configuration scheme which is done from the Quartus Assignments menu. So select Assignments - Device, then press the "Device and Pin Options...." button. A new window will appear - choose the "Configuration" category then set the configuration scheme to active parallel. The problem with the project above is that it was set to active serial which made a conflict with the same pins that connect to a parallel flash. 


We can close the book on this post. 


0 Kudos