Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

NIOS + DE2 + Flash Memory + Errors

I created a new project with a SOPC builder system with the following modules:

  • NIOS II/e

  • JTAG UART

  • Avalon Tristate Bridge

  • Flash Memory Interface (CFI)

The CFI is connected to the Tristate Bridge master connection. I auto-generated base addresses and IRQs, set the CPU reset and exception vectors to use the flash memory, then generated the system, added it to the project and created the following top-level module in Quartus: 


module sopc_flash_mem(
	input CLOCK_50,
	input  KEY,
	output  FL_ADDR,
	output FL_CE_N,
	output FL_OE_N,
	output FL_RST_N,
	output FL_WE_N,
	inout  FL_DQ
);
wire  in;
nios_system nios_system_inst(
      .address_to_the_flash       (FL_ADDR),
      .clk_0                      (CLOCK_50),
      .data_to_and_from_the_flash (FL_DQ),
      .in_port_to_the_pio_0       (in),
      .read_n_to_the_flash        (FL_OE_N),
      .reset_n                    (FL_RST_N),
      .select_n_to_the_flash      (FL_CE_N),
      .write_n_to_the_flash       (FL_WE_N)
);
	 
endmodule

When I try to create a new project in the NIOS IDE (Hello World template), I get the following error: 


Project cannot be created
Reason: The SOPC Builder System does not have a writable memory device mastered by the specified CPU's data master

I went into the .ptf file and manually changed "Is_Writeable = 0" to 1 in the data_master section but that didn't help.

Any ideas?

7 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Never mind the exception vector, what about the program data areas and stack!

    Indeed, although it is probably technically possible to execute code directly from flash, the normal boot procedures copy the code from flash into RAM (internal memory or external SRAM/SDRAM/DDR).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    --- Quote Start ---

    Never mind the exception vector, what about the program data areas and stack!

    Indeed, although it is probably technically possible to execute code directly from flash, the normal boot procedures copy the code from flash into RAM (internal memory or external SRAM/SDRAM/DDR).

    --- Quote End ---

    My goal is to use the Flash memory to store the program. I need to sample a large amount of data on the DE2 board and display that data on a PC. I'm using Nios and the JTAG UART to do this but the performance is quite bad using the basic "Hello World Small" template. Instead I intend to use the full template but it requires a large amount of program memory and using on-chip memory isn't feasible so I want to move this to the Flash memory. Is this even possible?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    The 'full template' code is larger and will be slower.

    It is possible that you are just limited by the speed of the JTAG interface - so nothing you do on the fpga will help.

    To get nios code running as fast as possible you need to run with both code and data in tightly coupled memory areas. If you need to boot from JTAG (or flash) you'll need the instruction master interface and minimal instruction cache.

    If you code is slow, then make sure you are compiling everything with the optimiser enabled (-O3 is reasonable).

    It is also possibly to speed up code considerably by fine tuning the C source to avoid cycle stalls and mis-predicted branches (I got over 20% on the worst case path).

    You might even find you can do a better job of writing data to the JTAG uart than the Altera supplied drivers - particularly if you have very specific requirements.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    The JTAG UART Core documentation states:

    --- Quote Start ---

    The small driver is a polled implementation that waits for the JTAG

    UART hardware before sending and receiving each character. The

    performance of the small driver is poor if you are sending large amounts

    of data.

    --- Quote End ---

    Which is why I want to switch to the fast/standard/full driver but it uses a lot of program memory that I can't spare in on-chip memory.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    The polled implementation will be sending characters through the JTAG uart as fast as it is possible to do so - spinning waiting for transmit space.

    The larger driver will copy data into a memory buffer and take an interrupt when there is transmit space, this allows you main program to continue execution while waiting for transmit space.

    So unless you have code to execute while waiting for data to transmit it won't make any difference. Since you seem to want to write a lot of data, I suspect you have no other work - so the 'full' driver won't help.

    Actually, since the JTAG uart is really a debug console, provided it has a small fifo, synchronous operation is exactly what you need - then you see all the output the code generates before it crashes and locks solid!

    Implementing a large fifo is software (which is what the 'full' driver will be doing) is probably often pointless - just add an M9K (or M4K) memory block as a hardware fifo instead (probably shared with the rx side).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    14 years ago

    Ok, so it seems like external memory to store the program is unnecessary because the large JTAG driver won't help. Do I add a hardware FIFO (using the megafunction wizard) between the ADC and NIOS system? 

    
audio signal ----> ADC ---samples---> FIFO ----> NIOS|JTAG UART ----> PC