Load custom-data to On-Chip memory

[Altera_Forum]

Folks, 

what would be the best way to load custom data to the on-chip memory of a Cyclone IV FPGA, preferably at start up.  Eventually a NIOS II application reads data from a flash device and stores it to the on-chip memory, where an custom logic (outside NIOS II) accesses this data.   For the time being I only wish to initialize part of the on-chip memory with some static data in order to test the custom logic.    Thanks in advance for your help!

[Altera_Forum]

If the data is truly static: Just make it a ROM in the custom logic side of the design (FPGA fabric). Then it will be there at startup. 

 Even if it isn't static, but can be modified by the NIOS, having the ram defined as a two port ram where the NIOS can read/write to it and the custom logic can read from it, can still have a INITIALIZATION FILE defined that it starts up in a known state.   Of course it could just be a two port ram that the NIOS just initializes everytime as well.  Pete

[Altera_Forum]

Thanks for the response. 

Is there such a thing as a template Memory Initialization file, or how can I create it?

[Altera_Forum]

The MIF and Intel HEX files are standards that you can find definitions for on-line, but they are not simple to just create using an editor. 

 There's several ways to do it.   I typically use a program designed for converting formats that I wrote myself that converts verilog readmemh files to intel-hex format, or depending on the format there's a great tool set that was originally created for converting srecords that can be used that can be found at http://srecord.sourceforge.net/  If you target is specifically just for FPGA only (No ASIC in your future) you can also use the $readmemb/$readmemh formats which are much simpler, but are not recognized by all synthesis tools.  I found a discussion on this at:  http://stackoverflow.com/questions/4321067/is-readmem-synthesizable-in-verilog  Pete

[Altera_Forum]

My recommendations: 

 1) Static data - If you plan on pre-initalizing the memory so that it is ready to go after the device is configured then I would use the Qsys on-chip RAM component and make sure the memory initialization feature is on. I typically change the initialization file name from the default when I parameterize the on-chip memory component. Unfortunately that component doesn't support the .mif file format which is much easier to work with using text editors or spreadsheets (if you generate data in a spreadsheet for example) but Quartus can convert between the file formats if I remember correctly. Either way, Quartus has an initialization editor that you can use which provides a graphical interface to type in values or copy and paste.  2) Dynamic data - If you want to re-use the same hardware and change the contents of the memory (much faster than recompiling the hardware with new contents) they you can use the same on-chip memory component in Qsys and just update it dynamically. You can enable the in-system memory editor feature of the on-chip RAM and use the in-system memory editor tool to update the RAM contents dynamically. Alternatively you could connect the JTAG to Avalon bridge to this memory and use System Console to repopulate the RAM with new contents.  So there are many ways to accomplish memory initialization. If you pick a method we can give you more advice on how to use it. I personally think the dynamic updating would be a better approach since you plan on having Nios II updating the memory as an end goal.

[Altera_Forum]

Thanks Pete for the input.  

 I believe there is another option to do this. I followed the instructions in the NIOS II software development handbook and used the NIOS shell in Eclipse to generate the memory initialization file make mem_init_generate This command also generate a .qip file, which is used to point the quartus II to the mif.  Before programming the device I modified some entries of the mif according to my test-data.  How can I now debug/monitor the data in the on-chip memory?  Using the NIOS debugger in Eclipse, there is a Memory monitor and memory browser functionality but I am not sure if these are the correct tools. Couldn't find my data so far.  How can I prevent NIOS II from writing application code/ instruction data into memory I dedicated to be my custom data. In other words where can I determine which addresses of the on-chip memory are reserved for the NIOS II application? Would it be feasible to add a 2nd on-chip component in qsys which would be solely dedicated for the custom data?  Thanks dom

[Altera_Forum]

--- Quote Start ---  My recommendations:  1) Static data - If you plan on pre-initalizing the memory so that it is ready to go after the device is configured then I would use the Qsys on-chip RAM component and make sure the memory initialization feature is on. I typically change the initialization file name from the default when I parameterize the on-chip memory component. Unfortunately that component doesn't support the .mif file format which is much easier to work with using text editors or spreadsheets (if you generate data in a spreadsheet for example) but Quartus can convert between the file formats if I remember correctly. Either way, Quartus has an initialization editor that you can use which provides a graphical interface to type in values or copy and paste.  2) Dynamic data - If you want to re-use the same hardware and change the contents of the memory (much faster than recompiling the hardware with new contents) they you can use the same on-chip memory component in Qsys and just update it dynamically. You can enable the in-system memory editor feature of the on-chip RAM and use the in-system memory editor tool to update the RAM contents dynamically. Alternatively you could connect the JTAG to Avalon bridge to this memory and use System Console to repopulate the RAM with new contents.  So there are many ways to accomplish memory initialization. If you pick a method we can give you more advice on how to use it. I personally think the dynamic updating would be a better approach since you plan on having Nios II updating the memory as an end goal.  --- Quote End ---    Eventually I will write a NIOS II program which reads from an SPI FLASH and populates the dedicated on-chip memory. The on-chip memory is configured in Dual port mode, the 2nd interface is exported outside NIOS II in order to be accessible via my custom FPGA logic. I recall that in-system memory editor does not support that configuration.  Btw, The data I am providing to the custom fpga logic is the feedforward-solution of a control problem. So basically I am updating a LUT, stored in the on-chip memory.

[Altera_Forum]

--- Quote Start ---  The on-chip memory is configured in Dual port mode, the 2nd interface is exported outside NIOS II in order to be accessible via my custom FPGA logic.   --- Quote End ---   Are You using QSYS? What exactly signals are exported from the 2nd interface of on-chip memory in dual-port mode? I see the following: https://www.alteraforum.com/forum/attachment.php?attachmentid=7952  What is a Write2 signal? Is it WriteEnable? And why the Read2 is missing?  How then to read from on-chip memory via my custom FPGA logic?  Where can I find the detailed description of all exported signals for Altera On-chip memory IP?

[Altera_Forum]

I think using system console would probably be your best bet then if you don't already have a Nios II processor already in your design. System consoles is scriptable so you should be able to take a text file and dump it to any memory location you like. This method will be quicker than recompiling the hardware changing the on-chip memory contents. I think there is a system console example that shows how to read/write an onchip memory so that would be a good starting point.