Honored Contributor
Honored ContributorHi 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
