I do not own a Nexys II board, but a quick look at the user guide and the schematic from the Digilent website and I can see that all the signals needed for programming the flash ROM device are available at the Spartan 3E pins. This is as I would have expected.
To program this device, you can do one of two thing:
1) The first option is a two step process in iteself. You first create the VHDL code for a Flash Programmer, that erases a block and writes your new data to the ROM. You'll need the datasheet for the Intel Flash ROM to do this. Then assign the ROM pins in the UCF file according to the table in the Digilent user guide and upload this .bit file to the platform flash. When it starts, it will execute the flash programmer code and write the ROM for you. The data you want to program is in the VHDL and thus also in the .bit file so the programmer can access the data to write to flash; or
2) the Flash ROM device does not have a JTAG interface and is thus not part of the JTAG chain. However, with a bit of work, you can use a BSDL file (Boundary Scan Description Language), available from Xilinx for FPGA on your board, and using OpenJTAG you can flip bits on the FPGA to program the device.
This "Boundary Scan Programming" of the flash device is quite common in production, however if you don't have a good Boundary Scan flash programmer it an be tedious to do it by hand using OpenJTAG commands.
I recommed option (1) since it's likely the quickest for you to accomplish. You'll need the Intel Datasheet for the StrataFlash ROM and basically send the commands to the the ROM to do an erase cycle and a write cycle for your data.
For the 20 bytes or so you want to program into ROM I'd consider a simple 20 byte flash programmer in VHDL.
However, for something more complete, there is an app note from Xilinx NOR FLASH Programmer for Spartan-3E Starter Kit. That is for another board but can be easily modified for your own board by changing the pin assignments. That appnote presents a design that programs the FPGA with a UART and a Picoblaze MCU to act as a full featured flash ROM programmer.
This depends on the device.
RAM can be built faster than Flash; this starts to become important in about the 100MHz range.
Simple microcontrollers
Small slow microcontrollers execute directly out of Flash. These systems usually have more Flash than SRAM too.
Midrange systems
Once your device gets faster then the situation is a little different. Midrange ARM systems may do that as well, or they may have a mask ROM bootloader that does something smarter: perhaps downloading code from USB or external EEPROMs into internal SRAM.
Large systems
Larger, faster systems will have external DRAM and external Flash. This is typical of a mobile phone architecture. At this point, there is plenty of RAM available and it's faster than the Flash, so the bootloader will copy and execute it. This may involve shovelling it through the CPU registers or it may involve a DMA transfer if a DMA unit is available.
Harvard architectures are typically small so don't bother with the copying phase. I've seen an ARM with "hybrid harvard", which is a single address space containing various memories but two different fetch units. Code and data can be fetched in parallel, as long as they are not from the same memory. So you could fetch code from Flash and data from SRAM, or code from SRAM and data from DRAM etc.
Best Answer
To put a function in a section with GCC, use a function attribute
Then, declare a section called
bar
in your linker script. Eg.