--- Quote Start ---
So I can implement the controller in a portion of the FPGA chip OR I can use the NIOS right? If I go for the first one then I would have to retain the circuitry of the controller while reconfiguring the other portion for the image processing. If I go for the NIOS then I would have to implement an interface to the FGPA. Which do you suggest?:)
--- Quote End ---
Yes, you can implement the controller in a portion of the FPGA. Actually, even if you use NIOS, it will also be in a portion of the FPGA (Nios will also get compiled to use the FPGA's logic resources). Either way, you have to implement an interface to the FPGA.
Think of it very simply, it's just your controller + interface. Controller is a block in FPGA (yes, you need to retain this circuitry while reconfiguring the other portion), and interface logic is another block in the same FPGA. Your controller implementation can be of your own choice, you can write your own HDL, or use Nios. Either way, it's still your controller. You have to hook this controller (Nios or HDL) up to an interface, maybe RS232/USB/etc. Again, it's Controller + Interface. :) Of course, in Nios, you can use any of the interfaces available, and build your Controller + Interface totally in Nios. It's really your own preference. I personally would like everything in VHDL.
--- Quote Start ---
Either choice of controller implementation I would have to use scan chain logic right? What would the memory be used for? I get the concept of scanning in bit stream to configure but I don't get why use a memory/shift register/RAM. Can't I use the controller to read the configuration bits from an external memory like an SD card and just load it to the FPGA? Is the memory you're referring to a memory that is holding the reconfiguration bits of the compression algorithm?
--- Quote End ---
Yes, you are right about the concept of scanning in the bitstream. And yes, the bitstream can be drawn from external memory like an SD card. The contents of your bitstream can be your new JPEG compression algorithm, or whatever. Or, you could write a generic JPEG compressor, and only change some parameters during runtime. So, in this case, your bitstream would be just the new parameters to scan into your algorithm. Whatever it is, it deals with some kind of memory. You need to scan in the bitstream (e.g. from your SD card), and store it somewhere (RAM). Now, it's up to you to define which memory to use (could be shift registers, M4K, external RAM, etc.). It's really up to you. Well, at least you got the concept right already :)
--- Quote Start ---
Oh yeah! regarding the reconfiguration of the FGPA, my HDL code would be compiled into a bit stream that would configure the chip right? I am in the assumption that I would always need the Quartus software to configure the chip. If that's the case then how can the chip be changed without the software?:)
--- Quote End ---
No, you don't *always* need Quartus to configure the chip, but it's good to start with that first. Later on, you can always use a configuration device (such as EPCS), or configuration controller (like a MAX-II CPLD) to do the auto-configuration during power up of your board. Here, you don't need to hook your board up to Quartus.
Regarding your question on how to "change the chip" configuration without Quartus, actually all you need to do is to scan in your new bitstream to your FPGA board, and you don't need Quartus (or even JTAG) to do the scanning for you. If you've implemented the RS232 interface (and of course, hooked it up to your bitstream controller) for example, then you can even connect your computer to your FPGA board via your RS232 port, and use some tool (or write your own) to do the bitstream scanning. Of course, you might as well use other interfaces such as Ethernet/USB/etc.
Honored Contributor
