NIOS: Running code from flash

Is it possible to run nios code from flash memory directly (assuming I'm running at only 10MHz)? Or do I need a small bootstrap in local rom to jump to the flash address?

Most existing designs I've seen have use an external ram and bootstrap by copying code from the flash to the ram prior to branching to the start address.

I tried a quick simulation. The only inputs I have to the nios cpu is clock and reset. I don't see that it's trying to put the flash address out on the bus.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
 Click to see the full signature
Reply to
Petter Gustad
Loading thread data ...

Petter, when you generate the core I'm 95% sure one of the advanced cpu config options is the reset address. If you change this to your flash address it might work.

Nial

------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design Cyclone PCI development/eval board

formatting link

Reply to
Nial Stewart

I *did* set the reset address to the flash base. The nios supplied flash ip has an 8-bit interface only. However, I was hoping to see that it would try to do a read at address 0 (the flash base address and reset location) to fetch the first instruction. My plan was to try to make a new ptf file for a 16-bit flash interface and run a 16-bit nios directly from this.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
 Click to see the full signature
Reply to
Petter Gustad

That seems odd, I would have thought that the program counter would reset to whatever value you set it to, and that this is the first address it would try to access.

Let us know what's happening if you suss this out.

Nial

------------------------------------------------ Nial Stewart Developments Ltd FPGA and High Speed Digital Design Cyclone PCI development/eval board

formatting link

Reply to
Nial Stewart

Hi Petter,

I just tried this with my Nios Stratix (1S10ES) board and was able to boot out of flash using a slightly modified "standard_32" design. The steps I took were to:

  1. In SOPC Builder's software settings for my Nios CPU: Modified the boot & program memory to be flash, and the data memory I left in SRAM (obviously, data memory must be volatile and writable by the CPU!).

2 Re-generated the system in SOPC Builder & re-compiled in Quartus.

  1. For flash memory contents, I compiled a simple program (hello_world.c) and used the srec2flash utility to get a flash programming file suitable for the GERMS monitor to write into flash. However, I had to modify this file slightly, as srec2flash normally has a flash copier routine to support users who want to boot up, copy their program to SRAM/SDRAM, and then execute from the faster memory. Basically I just removed the first part of the file and left the GERMS erase & relocate commands before the S-record data for my hello_world application.

  1. Loaded a design that boots with the GERMS monitor, and loaded the above .flash file to get my code in place.

  2. Downloaded the new .sof file that has Nios booting from flash -- success.

On your simulation problem: My guess here would be that you don't have a simulation model for flash memory. This is an optional step in SOPC Builder when you add flash to your system -- in the GUI where the flash is instantiated, there is a simulation contents page which you can use to create memory contents for simulation. By default I believe this is left to 'do not create simulation model'.

If you would like I'd be happy to email you the design I used in the above steps.

Jesse Kempa Altera Corp. jkempa at altera dot com

Reply to
Jesse Kempa

I just finished a NIOS project that had a loader locates at one memory location and application code located at another location. When you define the CPU you set restart and flash locations. THat produces excalubur.h and excalibur.s files which are used in the building process to defince startup locations.

I build both examples in the NIOS CPU definitions and then looked at the differences. I now just edit the excalibur.s,h files (with a batch file) for the different start up locations.

The loader is executed on power up. Then is no activity takes place in 5-10 seconds the application start location is called. This proceedure violates a lot of C conventions but it works.

Goerge

Reply to
George

Hi Jessa, thank you for your reply.

My explanation was probably a little unclear: I would like to set the reset vector to point to a flash location and run the code directly from the flash. In order to save some money and board space I wanted to run a flash in 16-bit mode and use a 16-bit NIOS CPU and feed the instruction stream directly from the flash. In other words I don't want to boot out of the flash, I want to execute code from it directly.

I just can't see how you can do this on the NIOS Development Kit Stratix Edition since it only has an eight bit datapath to the flash (if we're talking about the same board). Take a look at page 6 of:

$NIOS_DIR/documents/nios_stratix_1s10/nios_1s10_board_schematic.pdf

Hence you'll have to read the flash contents into either a pipeline register, on-chip ram, the sram or the rdram on the board prior to execution. Some flash memories (not the one on the in the development kit) have an optional pin (xbyte) which selects byte or 16-bit mode.

I do. I downloaded a flash model from AMD. I've also written my own testbench which instantiate the design and the flash (so there's room for errors here). The thing is since the *only* inputs to the design are clk and reset I expected to see that it would at least output the flash address on the bus shortly after reset. The next step would have been to convert the srec file for the flash to commands to write the flash before I release reset to the nios cpu (the flash model does not have readmem to init the flash for simulation).

However, I haven't spent very much time debugging this. I posted the message to see if anybody had done this already. Most likely there is a bug in my testbench etc. It could also be that I'll have to write my own ptf file for a 16-bit flash in order to make this work since the flash ip provided is an 8-bit part only.

BTW:

1) Is it possible to run the plugs library on a 16-bit nios cpu? 2) Is it possible to use the plugs library without an uart? see news:

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
 Click to see the full signature
Reply to
Petter Gustad

Hi Petter,

Send me an email and I'll send you my design -- it is just that, the reset vector points to flash (8-bit flash at that). Once the FPGA is configured (.sof file download or configuration controller loads the bit stream), Nios boots with the reset vector pointing to flash (containing program memory). This memory is read and my program executes, entirely out of flash.

The business of the flash being 8 bits wide and Nios (instruction master) being 16-bits wide is solved by something called "dynamic bus sizing". This is a feature of the Avalon bus which has been present in Nios since it was introduced a few years ago. The idea is that a bus master may request access to a 'narrow' slave -- the bus logic converts the single request for a 16-bit instruction fetch from Nios into two back-to-back 8-bit reads from the 8-bit bus to flash. The two reads are then concatenated into the 16-bit Nios instruction bus, and the read is declared valid (wait signal drops), allowing Nios to read

16 bits. This operation is transparent to the bus master, so a 32-bit Nios (or any other master) may do the same operation.

There is even "reverse" dynamic bus sizing implemented for narrow masters accessing wide slaves, allowing (for example), a 16-bit master to use a 32-bit memory without throwing half of it away. This feature was originally implemented to allow users to save IO (or cost) in their external memory choice.

One suggestion here for debugging where the simulation problem is: Take a look at the Nios instruction master address, coming out of the CPU (before any of the bus logic) -- this should show you what Nios is asking for to get data into the program counter, and it should match your flash address.

Also, one other suggestion I can give you would be to use the standard_32 design (with our 8-bit flash), and create the memory model for it in SOPC Builder, and then try the simulation booting from flash. Then, look at the top-level HDL file generated by SOPC Builder. Near the very end of the file is non-synthesizable HDL code that acts as a simulation test bench. Here you will see wiring from the top-level to the simple memory model that we create... I suggest this because it might assist in troubleshooting your test bench & flash memory model instantiation.

(1) I have not tried plugs in 16-bit mode but I am told it will work; there is a 16-bit Nios with Plugs example design included in the suite of examples for the older Nios Apex board.

(2) Yes, but Plugs does use stdout via printf.. so some modifications to your software will be necessary unless you wish to modify the plugs source code. I presume that your system without a UART also lacks an OCI debug core (for printf communication), and therefore has no stdout. You could (as one way of doing this), #define printf to go to some subroutine which does nothing in excalibur.h

Jesse Kempa Altera Corp. jkempa at altera dot com

Reply to
Jesse Kempa

Hi Jesse,

Thank you for your reply.

That would be great. You'll find my e-mail address at:

formatting link

I'm familiar with dynamic bus sizing from other arcitechrues, but I was not aware of that it was implemented in NIOS/Avalon. I'll have to spend some time debugging my simulation...

Again, thank you for your extensive reply.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
 Click to see the full signature
Reply to
Petter Gustad

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.