Partial reconfiguration, Special kind of bus macro

There is not enough information here to base any judgment on. You could improve your odds by focusing on the system description without assuming so much in advance about the optimum implementation details.

Or maybe you could restrict the topic to research into partial reconfiguration, since this seems to be your overriding interest.

There are no real tri-state buses current FPGAs.

-- Mike Treseler

mike_treseler schrieb:

I implemented some partial reconfiguration designs already. Just now, I focus mainly on persistent working logic within a slot under reconfiguration. The communication system connects all slots of my FPGA and shall even work if a slot is under reconfiguration. However, if the CS signal is active of a Xilinx FPGA, the complete logic works. Logic under reconfiguration produces trashy signals, and therefore the C/S has to be suspended if any slot is reconfigured. But IMHO trashy signals are only produced by changing logic, therefore I want to fix the related logic (only one CLB) within each module's type, to avoid suspending of the C/S. And my question is, is this assumption true?

You haven't understand my question. Real tri-state behavior wasn't a matter. Xilinx approach needs TBUFs and long lines to provide fixed points within a slot to connect signals of all types of a module properly, since logic is changing. But now I have some fixed logic, do I still need fixed communication points?

Bye Tom

And those FPGAs without tbufs are not supported by the partial reconfiguration design software. You can only use this with the Xilinx parts prior to Spartan III. So be prepared to pay the higher prices for parts that let you reconfigure on the fly which is supposed to save you money by using smaller parts... sort of counter intuitive isn't it?

I have been told more than once that partial reconfiguration is not a good thing to try to use in a commercial product. I would hazzard a guess that it is not a technolgy that is used enough (or requested enough) to have been fully developed. I believe they even put in an app note that you should limit your designs to just two modules, one fixed and one replacable. I think that was in the context of active partial reconfiguration.

I understand what you are saying. I know that the Virtex parts support this, but I don't know if the software makes it very easy to do in practice. You should contact Xilinx support about it. I assume you have checked for an app note or similar.

Actually, the current software requires you to use a true long line and tbufs for each signal in the bus macro. So again, the Virtext parts (not the Spartan parts which don't support active reconfiguration) might support using non-tbuf signals between modules, but I don't think the software does.

But Xilinx is working on this for the new Virtex 4 and Spartan 3 parts which do not have tbufs. So the new software may have a way to do this without long lines.

I asked Xilinx support already concerning partial reconf several times, usually I told them more then they me.

A little bit, but I may haven't the right keywords. One goal of this thread is to point me in the right direction, I have to look for.

Do you mean the module's types can only connect to tbufs and long lines? The xap290 says:"Each time partial reconfiguration is performed, the bus macros is used to establish unchaging routing channels between modules, guaranteeing correct connections." Furterhmore in my first partial reconf design I assumpted reset uses a dedicated net similiar to clock and didn't use a bus macros for the reset signal. The initial configuration (using TI) worked but not the reloaded different type (TII). If a reloaded the TI again it worked again. Ofcourse, the routing was broken for TII.

I plan to implement my communication system alone in a first step, completely fixed, not using the partial reconfiguration design flow. This design shall be transformed in a macro. In a second step I want to apply it in kind of a bus macro. And now I'm looking for an app note how to build my communication system as a macro.

Bye Tom

Therefore we do research in this field to provide solutions for commercial products :-).

You are right. But did you always do what your parrents said :-)?

Bye Tom