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.

Austin

rickman wrote:
> Austin Lesea wrote:
> 
>>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.
> 
> 
> 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 would ask your contact at the factory about their plans in their new
>>family.  They may decide to support it, or not.
> 
> 
> 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 <$20 for a
> Spartan part?  
> 

Austin Lesea wrote:
> 
> 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.

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 would ask your contact at the factory about their plans in their new
> family.  They may decide to support it, or not.

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 <$20 for a
Spartan part?  

-- 

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

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:
> Austin Lesea wrote:
> 
>>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).
> 
> 
> 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?  
> 

Austin Lesea wrote:
> 
> 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).

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

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

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

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

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

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

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