Is there a quicker way to flash new firmware on the Stratix GX 5 Dev kit board?

[Altera_Forum]

Greetings! 

 The Stratix GX 5 Dev Kit is my first time using any altera device or software (I'm more familiar with Xilinx). I am trying to program the FPGA with a new version of firmware and I'm finding the instructions/procedure listed in the documentation ridiculously cumbersome so I'm hoping there's a better way.  The documentation I have says to do the following to program the FPGA: Open the NIOS II Command Shell Navigate to my directory and type "sof2flash --input=<yourfile>_hw.sof --output=<yourfile>_hw.flash --offset=0x020C0000 --pfl --optionbit=0x00030000 --programmingmode=PS" (You've got to be kidding me!!) Wait a few minutes for the file to be generated Flip DIP switch SW5.3 to the OFF position (ok, reasonable) Back in the Command Shell, type "nios2-flash-programmer --base=0x0 <yourfile>_hw.flash" (somewhat reasonable, but a pain to type) Wait 20 minutes for the flashing to take effect. Flip the DIP switch back to On and restart the board. Takes about 30 minutes to flash a new file.  Please tell me there is a faster/better way to do this? In the Xilinx world, the programming of the FPGA is a GUI that takes less than 5 minutes to select the FGPA and PROM and 30 seconds to program.  Thanks a lot for any help/assistance!!  Jason

[Altera_Forum]

Hi Jason, 

 The board you have ...  http://www.altera.com/products/devkits/altera/kit-sv-gx-host.html  Has a USB-Blaster II interface. That interface uses a Cypress EZ-USB FX2 which is a USB 2.0 high-speed (480Mbps) device. The older USB-Blaster device was only high-speed (12Mbps), so way slower.  I have analyzed the performance of the USB-Blaster, but I do not have a board with a USB-Blaster II, so don't know its performance limits.  So, the obvious first question is, are you using the on-board USB-Blaster II?  The other thing to check, is to see if the Flash programming algorithm is dumb, eg. it might be erasing more Flash than it needs to. If the tools you are using output messages, read them, and see what Flash erase options are being used, i.e., sector or device?  The other general comment to make is "Why program the flash?". If you have to change the firmware, just program the FPGA directly via JTAG. Sure you have to warm-boot your PC, but you have to re-boot when programming the flash anyway. If USB-Blaster download is "fast enough", then it does not really matter that the flash programming is slower (though 30 minutes would be way too slow for me too).  Cheers, Dave

[Altera_Forum]

Hi Dave, 

 Thanks for the response. To answer your first question, I am using the USB-Blaster II and programming the FPGA directly is fairly quick. The issue I have is I'd have to keep programming the FPGA with the firmware every time I power off the device. Once I have a mature enough firmware, I'd rather program the flash so the board auto-loads the code on power up. I'm lazy...what can I say :)  I'm not currently in my lab to check for the flash programming algorithm's messages, but I will check it once I'm in the lab again. If I remember correctly, the flash files are fairly large, about 50-80 MB in size, but still for a USB interface I'd expect it should be able to transfer over the bus quicker than 20 minutes. I know that's not the only thing going on, but still I'd expect it to be a few minutes...not 20-30 minutes.  My main beef with the current programming the flash steps is having to use a command shell and having to type out those nasty commands. I would have thought Altera would have something like Xilinx's Impact program which is a GUI that's fairly intuitive. Nothing about the command shell is intuitive (at least to me). Is there another way to program the flash on the dev board besides using the command shell (like from the Quartus GUI)?  Thanks for the assist!  Jason

[Altera_Forum]

Hi Jason, 

  --- Quote Start ---   To answer your first question, I am using the USB-Blaster II and programming the FPGA directly is fairly quick.   --- Quote End ---   Ok.    --- Quote Start ---   The issue I have is I'd have to keep programming the FPGA with the firmware every time I power off the device. Once I have a mature enough firmware, I'd rather program the flash so the board auto-loads the code on power up. I'm lazy...what can I say :)   --- Quote End ---   I figured that was the case. But in the circumstance of having a slow programming interface, then using JTAG during development, and programming the flash infrequently might be a viable solution :)    --- Quote Start ---   I'm not currently in my lab to check for the flash programming algorithm's messages, but I will check it once I'm in the lab again. If I remember correctly, the flash files are fairly large, about 50-80 MB in size, but still for a USB interface I'd expect it should be able to transfer over the bus quicker than 20 minutes. I know that's not the only thing going on, but still I'd expect it to be a few minutes...not 20-30 minutes.   --- Quote End ---   It depends on how they have implemented the interface. The block diagram ....  http://www.altera.com/products/devkits/altera/kit-sv-gx-host.html  Shows that the board implementation is  a) EZ-USB with parallel output (GPIF interface) to MAX V b) MAX V parallel interface to the FPGA and to the JTAG pins c) FPGA interface to Flash (the block diagram shows parallel flash)  The highest performance flash programming interface would be for the MAX V to either communicate with the FPGA via the parallel interface, and the FPGA then program the flash (the FPGA would of course first have to be programmed with a "flash programmer" image).  However, because Altera is re-using existing tools, then I suspect the interface implementation is dumb, in that the USB-Blaster II is being used to serialized the flash contents over JTAG, and that serialized data is then being parallelized and programmed to the parallel flash. This interface may not actually be the limiting factor though, in that flash pages must be first erased, then written, and then programmed. Erase and programming takes a few milliseconds, so that may be the dominant factor. If the Altera command line tools are not monitoring the "ready/busy" on the flash, then they may be waiting longer than necessary for each erase/programming cycle.  Personally I'd just write my own Flash programmer. The SystemConsole debug interface should be using the 19-bit parallel interface, so that should be fast.  Cheers, Dave

[Altera_Forum]

Hi Jason, 

 The Quartus II Programmer GUI is pretty much like Impact, at least as far as I have used it anyway. Why not give that a try?  Cheers!  slacker

[Altera_Forum]

The quartus II programmer can only be used when you want to program a FPGA only file, to use it in combination with a NIOS II elf file can be a complex situation. 

 I'm wondering why the documentation uses the Nios command line and not the "nios II flash programmer" in the eclipse environment, it should do the same

[Altera_Forum]

I would expect the nios2-flash-programmer to be the fastest way to program flash. Normally this uses a Nios II processor in the FPGA to run the tight loop (the one where it waits for each flash program operation to complete). JTAG communications speeds have some impact, but most of the delay is waiting for the flash.  

 Can you try adding the --debug flag to n2fp to get it to display information about the exact modes it is using to do the programming operation.

[Altera_Forum]

--- Quote Start ---  I would expect the nios2-flash-programmer to be the fastest way to program flash. Normally this uses a Nios II processor in the FPGA to run the tight loop (the one where it waits for each flash program operation to complete). JTAG communications speeds have some impact, but most of the delay is waiting for the flash.   Can you try adding the --debug flag to n2fp to get it to display information about the exact modes it is using to do the programming operation.  --- Quote End ---    Sure, I can try that. Does it matter where I put the --debug flag, i.e. is "nios2-flash-programmer --base=0x0 --debug <yourfile>_hw.flash" an ok spot to put it?  Thanks, Jason