Xilinx Virtex 4 question

Andreas,

Yes, the configuration is in frames now that cover (I am pretty sure) 16 CLB's in height (if I'm wrong about the height, I am sure someone will throw something at me -- I've switched from being on the DCM team to the config team!).

The new FARME_ECC primitive has a 12 bit ECC word as part of the thousand some odd bit long frame, which is written at the time of configuration with the ECC syndrome. If later, an upset occurs, the syndrome will not match, and the offending bit is pointed to by the syndrome (so it can be corrected).

Each CLB has 22 frames to configure it. All frames are equivalent as fas as interconnect, but the remaining frames are individualized for the tile they are in.

So yes, you may reconfigure any, or part, of the part while it is operating, and the frame boundries form a better "fence."

The whole issue of reconfiguring while operating (which we have allowed in all the Virtex parts) is more one of finding the boundaries, than a functional issue (how to not disturb something while changing something else by ripping up and redoing the interconnect).

A config bit that was a 1, and is programmed to be a 1 (or the other way around) will not cause a glitch on the resulting resource.

For more information, contact your local FAE.

Aust> Hello!

I expect you are opening a serious can of worms. The concept is great, but the hard part is not the hardware, but the design software. Xilinx has supported modular design for partial reconfiguration (MDPR) for quite a while. But they have never represented that it works well and in fact caution users to tread carefully and to not get too ambitious. With the frame oriented MDPR being new, I would not expect it to be a simple thing to use for quite a while.

I am still waiting for MDPR support for the Spartan 3, even without the rest of the chip running (which the Spartan 3 won't do). I just want to make my designs truely modular at configuration time to match the hardware configuration rather than to have to produce thousands of different configurations. I am now being told they will get right on that *after* they have done the Virtex 4 MDPR.

For quite long i am coming across the concept of dynamic configuration. On papers it seems very attractive but i have never used it in my designs or i never felt the need of this feature. IMO it is just a theoritical concept or its a totaly gray area for me and i am not the right person to comment on it :-)

Hi Austin,

thanks for your quick answer! Since I am involved in an research project covering runtime reconfiguration this was just what I liked to read :)

Greetings from northern Germany! Andreas

I am involved in a research project in a related area. The question here is how to design for such a target device, that means, to simplify the task for the designer. Of course we need reliable vendors tools to implement the designs but so far the situation was even worse: There was no device family on the market which 100% met our assumptions. From Austins answer I expect that this has changed now with the Virtex 4.

This is interesting. What general type of application are you doing? What are the parts you need to exchange? I'm interested in such things since we have a discussion on a somewhat regular basis wether reconfiguration (runtime or not) makes sense for what applications.

Andreas

Starting with a XAPP would be more effective, but I didn't find anything. Particular interesting are an ucf example and something like a "bus macro". AFAIK V4 has no TBUFs, how to establish inter module connections, which survive reconfiguration?

Bye Tom

Tom,

There is a SDR project that uses partial reconfiguration to load the differing modulation/demodulation formats. They use a form of file system to represent the FPGA (I have seen it, it is realy neat -- you can look at the FPGA using a browser, and it looks like a file system).

Connections to and from the reloadable modules are simply hard loc'd interconnect paths (each modem uses the same inputs and outputs).

Switching modems is easy, because there is nothing to do while you switch from one to another, except wait until data starts coming out of the modem.

The 405PPC (or microblaze) is used to recognize the modem that is needed (what format are they talking in? or what format do I want to transmit with? and supervise the loading).

I won't say this is an easy design task, because the tools are all still experimental, and they are just not 'all there' yet.

But, it does appear as if this will be used at least for the software defined radio case (is being used right now).

How this may be extended, and what other applications may benefit is yet to be determined.

My favorite example of reconfiguration is one where when you turn a knob on the front panel of the instrument, it then figures out what partial bistream to load to do what you just selected (a real application as well). Again, nothing needs to be done while the bitstream is loading.

Contacting the FAE is the only way one can gain access to this work, as it is still specialized, and half in Xilinx Labs (the research arm of Xilinx), and half in the field.

Aust> Aust>

I have looked into this and both the Spartan 3 and Virtex 4 devices have no tbufs, therefore are not currently supported in the design software for partial reconfiguration. I was told that the Virtex 4 would be supported first with the next major release of the tools in Q1 of next year and the Spartan 3 would be added when feasible. But then I was told that Xilinx was working toward supporting the Spartan 3 nearly a year ago. :)

MDPR is very important for my application, so much that I am designing in the Spartan 3 in spite of the fact that I have no firm commitment from Xilinx that the Spartan 3 devices will ever be supported for MDPR. I am working on a board which accepts hardware modules as user configurable plug ins. Each of these modules can have a unique interface. The module type can be identified at boot time. At that time the FPGA needs to be loaded with design modules to provide the appropriate interface. With four module sites and potentially a dozen different module types, you can see that the number of combinations are enormous. Even trying to pare this down by limiting the combinations does not reduce the complexity to an acceptable level.

My plan is to support this configuration problem by modularizing the design and loading the appropriate interface in the same way that drivers are loaded by an operating system at boot time. I don't need for the FPGA to be running, I just need to be able to select the modules from a store and load them to match the hardware. This will let me create a fixed number of designs for each module type and combine them at load time to create the large number of configurations that need to be supported.

I have already found some limitations with the approach. A big one is that the columns in the Xilinx FPGAs are not equivalent, but have special configuration bits near the edges. But this only requires that each module have 4 varieties to fit the 4 slots. Still nowhere near the problem of the number of designs required without MDPR.

Using a Virtex chip which is supported for MDPR is not an option due to the high price relative to the application.

I assume that this is not requested more for the low cost devices because modularity is typically handled with standard interfaces. But in this case the standard interface is inside the FPGA to avoid needing additional logic on the module. The cost of the interface is absorbed into the FPGA keeping the recurring module cost to a minimum. Kindof the ultimate low cost use of a low cost FPGA.

But without MDPR the cost of generating the FPGA bitstreams required will be much higher and any one flash load will only be able to host a small fraction of the total number of combinations.

If someone is interested in using this as an example for research, I am happy to cooperate.

Do you have any idea of where the Spartan 3 fits into the plans for partial reconfiguration? Is it seriously being developed or is it still very back burner?

Rick,

TBUFs are not required for partial reconfiguration. That was just one approach. We do not have real TBUFs anyway (they were really gates fooling everyone into thinking they are tristate busses).

As far as the tools supporting it, you are correct: the tools do not support it.

However, using the tools, and hand placements, one can do it (although painfully) using any interconnect you like with great care (and time).

The key to this is a set of new tools that allow for replaceable modular design, and fixed communication pipes to be built.

Austin

Rick,

Frankly, the Spartan team is not all that concerned about the (partial) reconfiguration feature. I understand your situation, and I can sympathize, but the "low cost" FPGA is diverging from the "high feature" FPGA.

We see more and more decisions being made that begin to seriously differentiate the two product lines.

Spartan 3 may be the last part that looks in large part very similar to a 'Virtex' part.

Is this good? Well, all I can say is that they seem to be selling a hell of a lot of parts (some joke that the 'Spartan products group' is now the second largest FPGA vendor - by number of parts shipped - in the world!).

I would ask your contact at the factory about their plans in their new family. They may decide to support it, or not.

Austin

rickman wrote:

I guess I don't understand how this is an issue. The current parts support partial reconfiguration in hardware. Even if it is not supported in hardware, a bitstream can be "modular" which would suffice to meet my needs. But it has to be supported in software. That is the issue for the Spartan 3 parts, not the hardware.

I did, but just like a year ago, I got an answer that says it is in the plan, but no dates are given.

Frankly I don't see why this is an issue for the Virtex but not the Spartan devices. Using the modular reconfiguration capability of an FPGA can provide temendous compression of bitstream data if the design is truely modular. One of the big marketing/selling points of FPGAs is that the same hardware can be used to do different tasks at different times by reconfiguring them. The idea of modular configuration is just an extension of that to allow greater saving in hardware costs.

If Sirius wanted to use an FPGA as an SDR with modular reconfiguration, do you think they would want to pay $50 for a Virtex or

Rick,

I will forward this thread to my buddy in Spartan land.

I'm on your side here.

But the XC4VLX15 is not going to be a $50 part, and at 13,824 logic cells, 864 Kb of BRAM, 32 DSP48's, and four DCM's, that might be just the right choice for a SDR design. I think that a Spartan part that could do the same thing would be much larger, and probably more costly just due to the lack of the hard IP?

But, you are right: whatever solves the problem is going to win, and if Spartan could have had the socket if they had made some other decisions, maybe that would be a good thing.

I'll let you know what kind of response I get.

Aust> Aust>