1. Home
  2. Field-Programmable Gate Arrays
  3. reconfigurable, modular design and clock signals - Question

reconfigurable, modular design and clock signals - Question

Hello,

I have a question about the modular design flow for partial reconfiguration.

I created a small pr demo using xilinx modular design flow for a virtex2pro fpga.

It consists of 2 static parts with 1 reconfigurable area between. The logic functions of the modules are kept simple stupid. ;-)

Intermodule communication happens over a bus macro.

All i/o-pads (including the external clock) are located inside the area of the static module on the right side.

The one and only clock signal is shared by the reconfigurable module in the middle and the right static module.

Following XAPP290 and all pursuing papers I've read, clock signals aren't routed explicitly over bus macros. Thus they are distributed over the global clocking network resources, right?

But while active module phase, I encountered the suspicious warning, that PAR has noticed one unrouted signal. Taking a look at the partial netlist inside the FPGA_EDITOR - e.g. the one for the reconfigurable module in the middle - this could be verified. The clock signal was an unrouted net.

Is this normal or what am I doing wrong? Shouldn't the clock signal for the reconfigurable module be routed inside its area to an global clock resource connection?

I can't imagine, that the obtained partial bitstream from the netlist of the reconfigurable module is going to configure correctly, when the clock signal isn't somehow routed.

Could this problem be caused by missing LOC-constraints for the IBUFG and BUFG in the constraint file? Is this necessary at all. Should all I/O-BUFs be LOC-constrainted for partial reconfiguration based on modular design flow?

Any suggestions, experiences or in-depth explanations are appreciated. *thx*

Reply to
l.s.rockfan
Loading thread data ...

'rock'

The flow described in XAPP290 assumes that you have two working bitstreams, and you have taken their difference to create a partial, which may then be used to go from a working design 1, to a working design 2.

I am presuming that since you are complaining about a bitstream that is not working, that it is this "partial" stream modification of the first working design which has the unconnected global clock in FPGA Editor.

If design 1 and design 2 had two different global clock resources used (for whatever reason) then this would make sense.

The partial bitstream has to way to connect to anything, so loading a partial into FGPGA Editor would leave a lot unconnected...

To the extent that the design 2 has a region where it must use the same clock as design 1, somehow the second working design has to "know" how to do this (the LOC constraints you suggest are probably a good way to do that).

There is a much newer flow, supported by the new PlanAhead(tm) software tool, that automates this process more gracefully, and leads to a better result. The manual creation of partial bitstreams (original Virtex flow) was difficult, and cumbersome, and was only tolerated by universities and researchers (IMHO). It took the release of PlanAhead to enable the general adoption for the software defined radio partial reconfiguration development to be successful in the marketplace.

In spite of the date on this app note, it is actually very old (05/17/02) and may not be the best way to do partial reconfiguration (in light of newer tools).

Austin

Reply to
austin

Hi Austin,

this style of reconfiguration you mentioned in the quode above and talking in your answer is called small bit manipulation flow. this is the second flow described in xapp290. the first one is module-based partial reconfiguration flow. this is the one I refere to.

Yeah, I know there is already a newer flow. But I don't have the possibility to use the required tool (PlanAhead) you've mentioned for this new flow. In university we only have the latest EDK and ISE. That's why I'm constrained to apply, experiment and extend the old flow.

Tomorrow, I'm going to try to constrain all I/O-BUFs, IBUFG and BUFGs. Maybe this will help.

I don't know if the generated partial and full-design bitstreams work. But I would guess the partial ones don't, because the partial netlist generated for the reconfigurable module in active module phase of the flow (2nd phase) has an unrouted clock at the moment. The bitstream generated from this netlist shouldn't work, or do I mess up something?

The start configuration (and initial bitstream) for the fpga is generated in the 3rd phase called final assembly in this flow.

Anyway, thanks Austin for your effort.

Reply to
L. Schreiber

L. Schreiber,

The module flow was removed from this app note (no longer supported).

PlanAhead is available to universities through the XUP (Xilinx University Program). Ask your professor to request a copy and a license.

Austin

Reply to
austin

austin schrieb:

Now it's working and thus the flow, too.

It's not necessary to LOC-constraint. For clock signals you should add the global clocking network ressources in toplevel by hand. Otherwise an ibuf could mistakenly be added to the clock net by xst instead and so the routing of clock isn't possible for the reconfigurable module.

Greetings, Lars

Reply to
L. Schreiber

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.