Xilinx Virtex 4 question

Hello!

From the Virtex 4 documentation (Configuration Guide,
Users Guide) I learned that this family can be
configured during runtime in the granularity of single
frames. The frames which have a fixed size for all
members of this family.
Additionally the documents state that there is a tiled
placement of those frames.

For Virtex II the frames started at the topmost CLB
and ended at the bottom of the FPGA. This does not
seem to be the case with Virtex 4 devices.

This brings me to the question if it is now possible
to configure a part of the FPGA which looks like
e.g. a rectangle consisting of whole frames.
Having neighbour frames at all four sides of
that rectangle which are operating during that
reconfiguration process.

I'm having a picture of a matrix-style arrangement
of all the frames in mind where I can select a set
of them which are to be reconfigured.
Unfortunately I didn't find any figure in the docs
which gives me a hint on that.

Could anyone comment on this?

Greetings,
Andreas

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.

Austin

Andreas Schallenberg wrote:

> Hello!
> 
> From the Virtex 4 documentation (Configuration Guide,
> Users Guide) I learned that this family can be
> configured during runtime in the granularity of single
> frames. The frames which have a fixed size for all
> members of this family.
> Additionally the documents state that there is a tiled
> placement of those frames.
> 
> For Virtex II the frames started at the topmost CLB
> and ended at the bottom of the FPGA. This does not
> seem to be the case with Virtex 4 devices.
> 
> This brings me to the question if it is now possible
> to configure a part of the FPGA which looks like
> e.g. a rectangle consisting of whole frames.
> Having neighbour frames at all four sides of
> that rectangle which are operating during that
> reconfiguration process.
> 
> I'm having a picture of a matrix-style arrangement
> of all the frames in mind where I can select a set
> of them which are to be reconfigured.
> Unfortunately I didn't find any figure in the docs
> which gives me a hint on that.
> 
> Could anyone comment on this?
> 
> Greetings,
> Andreas
> 

Andreas Schallenberg wrote:
> 
> Hello!
> 
> From the Virtex 4 documentation (Configuration Guide,
> Users Guide) I learned that this family can be
> configured during runtime in the granularity of single
> frames. The frames which have a fixed size for all
> members of this family.
> Additionally the documents state that there is a tiled
> placement of those frames.
> 
> For Virtex II the frames started at the topmost CLB
> and ended at the bottom of the FPGA. This does not
> seem to be the case with Virtex 4 devices.
> 
> This brings me to the question if it is now possible
> to configure a part of the FPGA which looks like
> e.g. a rectangle consisting of whole frames.
> Having neighbour frames at all four sides of
> that rectangle which are operating during that
> reconfiguration process.
> 
> I'm having a picture of a matrix-style arrangement
> of all the frames in mind where I can select a set
> of them which are to be reconfigured.
> Unfortunately I didn't find any figure in the docs
> which gives me a hint on that.
> 
> Could anyone comment on this?

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.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

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 :-)



rickman <spamgoeshere4@yahoo.com> wrote in message news:<41ACAFEF.D9E16284@yahoo.com>...
> Andreas Schallenberg wrote:
> > 
> > Hello!
> > 
> > From the Virtex 4 documentation (Configuration Guide,
> > Users Guide) I learned that this family can be
> > configured during runtime in the granularity of single
> > frames. The frames which have a fixed size for all
> > members of this family.
> > Additionally the documents state that there is a tiled
> > placement of those frames.
> > 
> > For Virtex II the frames started at the topmost CLB
> > and ended at the bottom of the FPGA. This does not
> > seem to be the case with Virtex 4 devices.
> > 
> > This brings me to the question if it is now possible
> > to configure a part of the FPGA which looks like
> > e.g. a rectangle consisting of whole frames.
> > Having neighbour frames at all four sides of
> > that rectangle which are operating during that
> > reconfiguration process.
> > 
> > I'm having a picture of a matrix-style arrangement
> > of all the frames in mind where I can select a set
> > of them which are to be reconfigured.
> > Unfortunately I didn't find any figure in the docs
> > which gives me a hint on that.
> > 
> > Could anyone comment on this?
> 
> 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.  
> 
> -- 
> 
> Rick "rickman" Collins
> 
> rick.collins@XYarius.com
> Ignore the reply address. To email me use the above address with the XY
> removed.
> 
> Arius - A Signal Processing Solutions Company
> Specializing in DSP and FPGA design      URL http://www.arius.com
> 4 King Ave                               301-682-7772 Voice
> Frederick, MD 21701-3110                 301-682-7666 FAX

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

Hi!

rickman wrote:
> ...
> 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 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.

> 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.
> 
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

Austin Lesea wrote:

> For more information, contact your local FAE.

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.

Austin

Thomas Reinemann wrote:
> Austin Lesea wrote:
> 
> 
>>For more information, contact your local FAE.
> 
> 
> 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

Thomas Reinemann wrote:
> 
> Austin Lesea wrote:
> 
> > For more information, contact your local FAE.
> 
> 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?

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.  :)

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX

Andreas Schallenberg wrote:
> 
> Hi!
> 
> rickman wrote:
> > 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.
> >
> 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.

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.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX