Dynamic Partial Reconfiguration & Direct Bitstream File Manipulation

Jaraqui,

Both Stratix V and Cyclone V support partial reconfiguration. There may be others too.

I'm not sure I understand your other principle question. By 'bitstream' are you referring to the FPGA's configuration data bitstream? If so, then Altera's Quartus tool suit allows you to 'manipulate' the bitstream by way of modifying source code, device constraints and compilation. Quartus doesn't (and I don't know of any Altera or 3rd party tool that does) allow you to open the resulting FPGA configuration file (.sof) in order to 'manipulate' or change it.

There are several development boards built around Stratix V & Cyclone V devices. Refer to Altera's Development boards page for details:

http://www.altera.com/products/devkits/kit-dev_platforms.jsp (http://www.altera.com/products/devkits/kit-dev_platforms.jsp)

Regards,

Alex

Thank you Alex,

I will check Cyclone and Stratix for DPR.

and

Yes, I am reffering to the bitstream configuration file. In this case is the .sof file.

The reasons for that rely on a research area called Evolvable Hardware.

In a few words, we need to run the following loop:

1-.sof file generation;

2-download the bitstream file configuration to the development board;

3-circuit/system evalutation;

4-if termination condition reached go to step 1;

5-final circuit/system generated.

This loop needs to be executed in a "population" of circuit-candidates for each circuit, dozens of times, i.e., population# 1,# 2, ..., until final population.

In this scenario, the time spent is intractable if we need to synthesize, place and route and generate each .sof file (each circuit-candidate) for just one population.

Xilinx JBits, for example is a tool that allows direct bitstream manipulation, but there are some problems regarding opening documentation, other restriction problems regarding the type of FPGA device to be bitstream-file-edited, and the tool itself I suspect it is discontinued.

So, if I find an Altera or other vendor specific tool that allows me the processing of step "1" directly, it will accelerate my executions tremendously.

Regards

Jaraqui

Altera's tool chain will allow you to perform different parts of the compilation separately. You can ask it to perform the 'assembly' step, the step that creates the .sof file, independently. However, this will be of limited use on its own, assuming you're looking to change source code between iteration cycles.

Quartus II supports incremental compilation, allowing you to 'lock' portions of your design and only re-analyse, fit and assemble the bits that have changed. You don't mention what it is you're intending to change between iterations, but assuming it's source code then this will be the way to go.

Have a look at Altera's documentation on incremental compilation.

http://www.altera.com/support/software/incremental/sof-qts-increment-comp.html (http://www.altera.com/support/software/incremental/sof-qts-increment-comp.html)

Regards,

Alex

Hi Jaraqui,

1.

I'm doing some DPR projects too with both Cyclone V and Arria V (dev kit).

You should have Quartus II v13.0 or more to work with Arria V for DPR.

2.

I think that no bitstream "manipulation" is allowed with the PR flow (.SOF, .PMSF or .RBF).

Furthemore, bitstreams are likely encrypted to prevent manipulations.

Hope I understood your question.

AC.

Hi arriacinq,

I gave up the bitstream direct edition. Xilinx suspended the JBits tool. It is discontinued.

Excellent your recommendations (as well as the ones from a_x_h_75). The report of someone who could get practical results telling the combination of the appropriate pair of Quartus version and development kit, is definitely a strong help. Thank you!

Best regards

Jaraqui

For Cyclone V you need very recent versions of the silicon and a special software licence - at least for the PCIe reconfig stuff.

There is also a errata that means that fmax is reduced considerably - I suspect that the logic can end up short circuiting the power rails in the middle of the reconfiguration cycle.

Programming the periphery from EPCS and the rest of the device over PCIe might solve the PCIe reset time problems, but it likely to be an update nightmare.

You either need the EPCS write logic in the periphery or to guarantee to have the file that matches the configured periphery.

And, AFAICT, there is no way to have a 'factory' image - unless you use passive serial mode and have a jumper on the MAXX (or whatever) device that generates the EPCS read cycle.

--- Quote Start ---

I'm doing some DPR projects too with both Cyclone V and Arria V (dev kit).

--- Quote End ---

Hi arriacinq,

which Cyclone V kit are you using (DK-DEV-5CSXC6N - Altera Cyclone V SoC Development Kit with 5CSXFC6D6F31C6N), other one ?

--

regards,

icegreen