AS Configuration of NiosII hardware & software images

[Altera_Forum]

Hi, 

I have a requirement that I want to program my serial configuration device - EPCS16 with the hardware and software images of the NiosII system that I am building. Upon power-up, I want the FPGA to be configured by the hardware image, and simultaneously I want the software image also to get loaded into some area in the on-chip memory. This means that I want to generate a single .pof file for both the images. I want to know whether it is possible to do this. If not, how does one run a software code on the NiosII system.  thanks and regards, rajesh

[Altera_Forum]

Sure it's possible. 

There are usually two ways to run Nios code from configuration device (i.e. not booting with jtag) The first one is what you are asking for. The code resides in onchip ram and is loaded together with fpga configuration. To do this you must convert the Nios software elf output into a hex file which is then assigned to onchip ram as memory initialization file. The disadvantage of this method is that it requires a Quartus recompilation (actually only a MIF update is needed) whenever you change the Nios program. Usually you may want to store Nios software separately into the epcs, so you can update it without changing the fpga image file. In this case you need a bootloader which loads program data from epcs into onchip ram (or sram, or sdram or whatever) just after fpga configuration has been loaded and activated. The standard epcs controller core already provides a boot-loader feature.

[Altera_Forum]

If your nios code has access to the outside world then you can also include code to update the epcs via software - and also only update the code part. 

If your code fits in internal memory you might have a space problem doing that though. However you might be able to request the individual bus cycles from the external system with minimal (or no) software support.  Getting non-jtag programming working is useful - especially if the software is being written outside the hardware team (which I'd have thought was more normal than the Altera build scheme implies).

[Altera_Forum]

Hi Cris, 

Thank you for the response. I want to know one more thing. The include files, and drivers (for LCD display which I am using) might need quite a bit of space. All this will be part of the executable software code. Will there be sufficient space in the on-chip RAM for accomodating all this. My system is pretty small - just the most basic NiosII core, an LCD display and on-chip memory. Do you have any white paper / application note for generating a single .pof file for both the hardware and software images.  One more doubt: upon power up, once the hardware and software images are loaded, what is that "thing" which makes the NiosII processor execute the code residing in on-chip memory.  thanks and regards, rajesh    --- Quote Start ---  Sure it's possible. There are usually two ways to run Nios code from configuration device (i.e. not booting with jtag) The first one is what you are asking for. The code resides in onchip ram and is loaded together with fpga configuration. To do this you must convert the Nios software elf output into a hex file which is then assigned to onchip ram as memory initialization file. The disadvantage of this method is that it requires a Quartus recompilation (actually only a MIF update is needed) whenever you change the Nios program. Usually you may want to store Nios software separately into the epcs, so you can update it without changing the fpga image file. In this case you need a bootloader which loads program data from epcs into onchip ram (or sram, or sdram or whatever) just after fpga configuration has been loaded and activated. The standard epcs controller core already provides a boot-loader feature.  --- Quote End ---  

[Altera_Forum]

--- Quote Start ---   Do you have any white paper / application note for generating a single .pof file for both the hardware and software images.    --- Quote End ---   I had an application note but I can't remember where it is right now. I'd have to search for it. Try browsing the Altera documentation.  You basically only need the steps I mentioned before: - generate the hex memory initialization file for your Nios software. I think the Nios tools have an option to generate this hex file in addition to the standard elf file. - assign the hex file as initialization file for the onchip memory in Qsys/sopc-builder - rebuild Quartus project and generate pof file    --- Quote Start ---   One more doubt: upon power up, once the hardware and software images are loaded, what is that "thing" which makes the NiosII processor execute the code residing in on-chip memory.    --- Quote End ---   You must open the Nios properties in sopc/Qsys and set the reset vector to point to onchip ram base address

[Altera_Forum]

The secret to making the code small is to make sure that you avoid large library functions - especially things like printf() and malloc(). 

You might find that the Altera drivers for the LCD display are over-engineered for your purpose - especially if they try to give you a stdio (or Unix) file interface rather than exposing a small number of functions.  You can get much smaller than the small Altera BSP builds.

[Altera_Forum]

Hi Cris, 

Thank you very much for your valuable inputs. I will try this out, and let you know.  thanks and regards, rajesh    --- Quote Start ---  I had an application note but I can't remember where it is right now. I'd have to search for it. Try browsing the Altera documentation.  You basically only need the steps I mentioned before: - generate the hex memory initialization file for your Nios software. I think the Nios tools have an option to generate this hex file in addition to the standard elf file. - assign the hex file as initialization file for the onchip memory in Qsys/sopc-builder - rebuild Quartus project and generate pof file   You must open the Nios properties in sopc/Qsys and set the reset vector to point to onchip ram base address  --- Quote End ---  

[Altera_Forum]

Hi DSL, 

This is a very valuable suggestion! Can you elaborate on how I can "get much smaller than the small Altera BSP builds". How do I get rid of the "over-engineering". I want just the bare minimum functionality for the LCD driver. By the way, I am just using a simple 2 line character LCD display. regards, rajesh     --- Quote Start ---  The secret to making the code small is to make sure that you avoid large library functions - especially things like printf() and malloc(). You might find that the Altera drivers for the LCD display are over-engineered for your purpose - especially if they try to give you a stdio (or Unix) file interface rather than exposing a small number of functions.  You can get much smaller than the small Altera BSP builds.  --- Quote End ---