Partial Reconfiguration in DE2

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.

Ok

I will try to give you an advice