Greetings!I posted a while back about a digital image processing platform that demonstrates a jpeg compression algorithm to process the image. The JPEG encoding is an option that a user can apply to their images taken by a CMOS camera that came with the DE2 development board. I got plenty of help from the community in determining the following: 1. Implement a controller using NIOSII to service user interface commands (eg. capture, save, compress) 2. That same NIOSII controller will also serve as a reconfiguration device to reconfigure the image processing part of the system - the block that implements the JPEG compression. 3. That block needs to be reconfigured because besides the assumption that the Logic Elements that the JPEG module will occupy will overwhelm the 33,000 LEs the FPGA chip in the DE2 can accommodate, new algorithms such as BMP compression, etc. may be made in future developments. (This is a platform after all). 4. daniel.kho suggested the use of a scan chain to load the bitstream of a new algorithm to reconfigure the processing block. He stated that I don't have to reconfigure the whole system. My concerns now are: 1. The cyclone II device does not support partial reconfiguration according to Altera http://www.altera.com/support/kdb/solutions/rd11192009_959.html 2. If this is so, then how do i implement the reconfiguration of a certain part of the fgpa chip using the scan chain? Does the scan chain fall under the partial reconfiguration? 3. daniel.kho also stated that I won't be loading an SOF/POF file into the FGPA to reconfigure with just a new compression algorithm like BMP during run time. so what would i be loading? Basically, daniel.kho helped me in making this conclusion before: I will load the system into the FPGA using QuartusII. The system involves the reconfiguration controller that is a scan chain. After that Quartus can be disconneted totally and when a new algorithm is developed, it will be accessed in a memory (SD card) and this bitstream will be scanned by the scan chain to reconfigure the processing block. The system is now configured with the new compression algorithm. Can this be done in the Cyclone II? Thank you in advance.
It's not to me clear, what your exactly asking for. No Altera FPGA supports partial reconfiguaration up to now. Altera has has announced it as a feature to come, see Altera.com.In so far it's clear, that total reconfiguration is the only option at present. What do you want to achieve with Cyclone II? Use it as a reconfiguration controller or is it the device to be reconfigured?
I see, so the Stratix V that will support the partial reconfiguration is not yet in the market. Okay, thanks.--- Quote Start --- In so far it's clear, that total reconfiguration is the only option at present. What do you want to achieve with Cyclone II? Use it as a reconfiguration controller or is it the device to be reconfigured? --- Quote End --- Well, I only have one board and one Cyclone II and the system needs an FPGA implementation (HDL) of JPEG compression that will compress image data and controller for the user interface, peripherals and memory that is implemented in NIOSII + Avalon Bus. There are 2 problems encoutnered: 1. The Cyclone II of the DE2 board only has 33,000 LEs available and the JPEG implementation we have compiled to 45,000 LEs. (Not including the NIOSII controller, interfaces to peripherals) 2. Since the system is an image processing platform, JPEG compression will not be the only algorithm used therefore if the user wanted to use another algorithm say bmp compression then the JPEG compression should be replaced by bmp compression at run time. This means that the NIOSII controller + interfaces + memory modules will not be changed, only the compression block. This is why partial reconfiguration was discussed, but since it is not yet a feature in Altera devices, I need a way to implement this. I am considering the following: 1. PC to DE2 Board interface: A software will configure the whole FGPA everytime a different compression is chosen 2. Scan chain: as suggested by daniel.kho, implement a scan chain that will load the bit stream to a part of the FGPA to change the configuration of that part. is this considered as partial, if yes, can it be done? 3. Use 2 boards: 1 for the controller, 1 for the image processing. basically, what other ways are there in doing this kind of system? I hope I was able to make it clearer :) Thank you for your help.
Additional:First it is the device to be reconfigured because of the image compression part. Second, if no PC interface will be done, then it is also the reconfiguring device. Thanks :)
Unfortunately, I'm not able to refer the suggestion of daniel.kho to a documented Altera FPGA feature. If the scan chain used for JTAG device configuration would effectively allow a partial (re)configuration, it's at least undocumented. I wonder, how you should be able to use it?
I see... Well, if that's the case, that its undocumented, how can I implement my system without using partial reconfiguration then?What would be my best bet? Thank you.
Altera provides the remote update Megafunction, that allows to choose between multiple configuration images from a flash memory. Unfortunately, it's not supported for Cyclone II. With Cyclone II, an external configuration controller (e.g. MAX II) would be required for a similar functionality. But I don't think, that it's possible with the existing DE2 hardware.
Okay, so the system I want to implement can't be done in the DE2?How about if I interface the board to my PC and control it from there, and make a software that will change the configuration of the FPGA chip without using the programmer in Quartus? Thank you.
Hi Mark, sorry I can't find back the original post. So I'll post here instead.The idea of having partial reconfiguration on any FPGA device is actually to simply design your own "soft" Partial Reconfiguration Block... or whatever you'd like to call it. It is something like having the whole scan chain designed yourself, instead of using Altera's partial reconfiguration hard circuitry on silicon. Only some devices support it, as FvM mentioned. I personally do not know the details of this new partial reconfiguration feature that Altera is offering. But what I know is, there are people who designed their own "soft" reconfiguration circuitry to "program" or "change some settings" of some parts of their design. So, if you would like to have parts of your circuit change to a different user setting, you can design an interface that hooks up to your own Partial Reconfiguration Block. The interface can be any interface - RS232, USB, Ethernet, whatever... but the idea is to use the interface to send your user configuration data into your scan chain (this is your own Partial Reconfig Block). The partial reconfig block design should be as simple as having some logic to shift the data stream (from the interface) to some registers, or internal memory blocks. You can then have logic to read from this memory (or registers) and decide how the other parts of your design should behave (depending on the settings stored in memory). Hope this helps, Daniel
Hi Mark,To make things clearer, the "scan chain" you mentioned in your earlier posts refers to the JTAG chain, while the one I was referring to (dubbed "soft" Partial Reconfiguration Block - designed yourself) does not refer to the JTAG chain. This of course, has to be a separate interface from the JTAG interface, and you can use any standard interfaces like RS232, USB, etc. or even use your own non-standard interface with your own header. Hope this explanation is clear for you. Regards, Daniel
Sorry this had to come in multiple posts.But well, after more reading, I came to the conclusion that you're getting the idea... well, almost! --- Quote Start --- How about if I interface the board to my PC and control it from there, and make a software that will change the configuration of the FPGA chip without using the programmer in Quartus? --- Quote End --- Oh yes, this is the whole point... your software that you make would have to communicate with said interface (RS232, USB, etc.). Your software would send your user configuration data (new settings) via this interface to your FPGA. Then, your "soft" Partial Reconfiguration Block receives these new settings and stores them in memory. After that, you have some custom logic that reads from this memory and decides how your other blocks would behave based on these new settings! Well, you don't need the JTAG port anymore after you've configured the FPGA the first time... you only need the said interface that connects to your PC (and of course, you can unplug it if you don't need to send new settings). Anyway, using the PC is just one example... this can be any other circuit board, or chip, etc. that sends the settings... Btw, well done...brava! Regards, Daniel
In my opinion, talking about "soft" partial reconfiguration tends to confuse the discussion. Please notice, that the original poster asked for reconfiguration because the full application functionality doesn't fit the FPGA resources. In this case "soft reconfiguration" isn't an option, because it can't but switch between blocks that have been compiled to the FPGA image before.I would prefer the term configurable design for the feature. But because alternative logic functionality most be provided and configuration registers in addition, it has an increased resource demand compared to fixed application specific designs.
I apologise for not being clear at first, but that "soft reconfiguration" idea was my original intent for the post. Sorry if the idea was perceived differently.Well, I don't know how you'd like to call it, so I just dubbed it "soft partial reconfiguration", but you can give that block your own name as well... It's the basic idea that I wished to explain. Perhaps the term "configurable design" is less confusing. Yes, logic resources is a concern. You have to figure out if you have enough resources to implement this block. This depends on how "big" your user configuration file is... if it's just a few bytes, you can simple use the device's registers, otherwise if it's a few kB (or even 1kB), you can consider using internal RAM blocks. I'm not sure which Cyclone II device you're using... but I assumed you have enough resources to implement this sort of thing (my assumption could be wrong, so it's better to check if you have enough resources). I'm not too sure, but maybe you may need about <3 kLEs (this is pessimistic, you can make it much less than that), with some memory (memory depends on how big your user settings file is). You can try to optimise your HDL for space, so it uses the least LEs as possible, and more memory instead (here, I'm assuming you have a lot of memory). But anyway, FvM's concerns are valid, you need to think about those as well.
--- Quote Start --- it can't but switch between blocks that have been compiled to the FPGA image before. --- Quote End --- This is mostly true, but we can think of how to make some of our blocks highly reconfigurable. We can have an input bus as a generic parameter (similar to generics, but can be changed at runtime). The input bus receives some user-configured bits from the "soft reconfiguration" block (or if you want, directly from the registers). This input bus defines the "settings" (or "modes") for which the block would behave, and the block behaves differently (or enters into different modes) based on different values on this bus.
Hi!First of all, thank you so much for your replies. I have a few questions :) 1. --- Quote Start --- It is something like having the whole scan chain designed yourself, instead of using Altera's partial reconfiguration hard circuitry on silicon. --- Quote End --- Regarding the quote above, Does this mean I can't implement the JPEG algorithm in HDL because I'm not actually going to reconfigure the hardware? 2. If I am not going to reconfigure hardware then from what I understand, I will implement a design that will behave in multiple ways according to a configuration that it is set to, pretty much like a microcontroller? 3. My JPEG algorithm is about 40k LEs if it is implemented in HDL, my NIOSII controller is aroudn 9k and I will have other peripherals implemented. This means that I have to limit the JPEG block (which is the configurable design block). Then the HDL I will load into this block is a set of logic blocks that the whole JPEG algorithm needs but not in a way that the whole algorithm is implemented. To explain further: The JPEG algorithm has 4 main blocks, DCT, Quantization, Entropy, and Huffman Coding. These cannot fit in the FPGA as they are thus the need for the configurable design. So, from what I understand, I will implement a design that have elements that cater to all of these blocks but does not act as the JPEG algorithm right away. Then the configuration bits or "settings" will choose how the circuit will behave, first as the DCT, then after change the settings as the other blocks. Is this right? 4. --- Quote Start --- Please notice, that the original poster asked for reconfiguration because the full application functionality doesn't fit the FPGA resources. In this case "soft reconfiguration" isn't an option, because it can't but switch between blocks that have been compiled to the FPGA image before. --- Quote End --- Does my question# 3 pertains to this issue? Is switching between blocks different from reconfiguring the behaviour of the circuitry, like how I described the system in question# 3? 5. --- Quote Start --- I would prefer the term configurable design for the feature. But because alternative logic functionality most be provided and configuration registers in addition, it has an increased resource demand compared to fixed application specific designs. --- Quote End --- I don't quite understand the alternative logic funcionality and configuration registers here... How do they work? Thanks again :)
--- Quote Start --- The JPEG algorithm has 4 main blocks, DCT, Quantization, Entropy, and Huffman Coding. --- Quote End --- First of all, you need to be sure which parts of your design is fixed, and which parts you want them to be reconfigurable. --- Quote Start --- 1. Does this mean I can't implement the JPEG algorithm in HDL because I'm not actually going to reconfigure the hardware? 2. If I am not going to reconfigure hardware then from what I understand, I will implement a design that will behave in multiple ways according to a configuration that it is set to, pretty much like a microcontroller? --- Quote End --- Next, for the reconfigurable parts of your design, try to determine a "language" or "syntax" of the configuration bits in general. Yes. it is very pretty much like a microcontroller (you can have your own simple assembly language or something, or define your own protocol). Try to make the configurable parts of your design to follow some "sequence" (like assembly coding), and you can "change the sequence" however you like (similar to assembly, where you can also change the sequence). You can then "scan in" this sequence through the said interface (I'll call this interface "PC Interface" from now on - can be USB, RS232, etc.), and let your "soft reconfiguration controller" decide how to process that new sequence - probably turn off some blocks, or set some blocks to high-speed mode, or change the buswidths of some blocks to a smaller value (this of course you'd need to define a maximum buswidth in your HDL), or whatever you need. I'm not too sure of the details of your image processing project. But let's say you have 2 different implementations (different algorithms) for DCT, and 3 different algorithms for Quantization, and the other two blocks (entropy and Huffman Coding) are fixed. Then I'd suggest that you find out the differences between your different algorithms. Use these differences to determine which of the two implementations you want to run at any one time (these are your settings). Here is one simple example (does not use the "sequence" method earlier), but uses multiplexers to choose between algorithms (already compiled as separate blocks into the FPGA): Say, between DCT1 and DCT2, you have 1 term that's different, and the other terms are the same between the 2 algorithms. You can have a setting, maybe "DCT1" to choose the DCT1 algorithm, and "DCT2" to choose DCT2. You scan this (either "DCT1" or "DCT2") from your PC interface into your "soft reconfiguration controller". For example, after scanning "DCT1", your soft controller tells your DCT block to take the result using the term specifically meant for the DCT1 algorithm. Another way using the "sequence method" (this is probably harder, but could save you a lot of logic resources - this behaves a bit like a microcontroller): Write a generic DCT equation that can cater for both DCT1 and DCT2 algorithms in HDL. Similarly write a generic equation for the Quantization block that is able to support all your quantization techniques. Scan in the detailed equations from the PC interface and let your logic implement those equations. I've never done this before, but I believe this can be done... you just need some time to think. Tip: what I can think of now is implement multipliers, adders, comparators, and dividers, but your HDL doesn't know the exact algorithm yet until it receives the detailed equation. It doesn't know 'what multiplies what', or 'what adds to what', etc. After it receives your detailed algorithm, will it decide how to properly use those blocks. Sounds like making your own scientific calculator, no? Here of course, you need to reserve a "maximum" number of multipliers/adders/etc. for your implementation. Well, just my thoughts... not perfect though.