what is the difference between "configuring" and "programming"?

Perhaps "configuring" means after "configuring" data can be lost after power down, programming means NOT.

The main difference between the words is the spelling! In this context they mean the same thing, i.e. loading a bitstream into a device. The writer may be trying to convey some difference between a volatile configuration memory device and a non-volatile one. I would suggest "configuring" is the better choice for both sets of devices. To most engineers, "Programming" can also mean the act of writing code that is subsequently to be compiled into a bitstream, cf. "Computer programming". The problem with English is that it has too many words. Inevitably some of them have to mean nearly the same thing. Good for English poetry, bad for English students! Cheers, Syms. p.s. Rather than "echoisme" I would choose "iamecho". ;-)

For historical reasons only, Xilinx has referred to the process by which configuration data is loaded into FPGAs as "configuring". Xilinx has similarly referred to the process by which configuration data is loaded into a PROM or a CPLD as "programming". The typical rationale given was that because one is a volatile medium (FPGA) and the other a non-volatile medium (PROM and CPLD) and their programmed behavior different in that one loses its memory after power off and the other doesn't; so the "action" describing the programming operation should be different, too.

Most people do not make that linguistic distinction and still lead full and complete lives.

thanks, everybody then what is difference between "reconfigurable" and "programmable"? i am really confused with them for a long time!

In the context we're discussing, "reconfigurable" implies the device can be programmed more than once. "Programmable" implies it can be configured at least once. Cheers, Syms.

p.s. So, "configurable" means the same as "programmable". Adding "re" at the beginning of either word means you can do it more than once!

All,

'Reconfigurable' has now been extended to imply that while the device is operating, a section of it may be re-configured (changed to perform a new or different function) and then seemlessly used.

The meaning is broader that the original.

The ICAP (internal configuration access port) means you can perform this re-configuration from internal control sources, while performing other functions. I believe both of these capabilties are unique to Xilinx, starting with Virtex II.

Spartan does not provide this ICAP feature. To them, re-configure, really means to configure the entire device, again. This is he original pre-Virtex II definition. Although, any new design may be loaded at the user's direction given there is more than one design to load, and a means to control which one gets loaded.

I also know that internal partial reconfiguration is seldom used, as there is very little tool support to enable designers to take advantage of it. The software defined radio (SDR) application appears to be the market driver here, with new tools being built right now to allow designers to use one small FPGA in a SDR that is able to modulate and demodulate dozens of over the air channel standards (SSB AM, NB FM, QAM, GMSK, etc etc etc...) merely by recognizing the senders format (using microblaze or the 405PPC), followed by a partial reconfiguration of mod and demod functions, all in time to listen to who called you, and answer back.

Exciting.

Austin

Sym>

Hi Austin, Exciting indeed. At last a proper application that the rest of us can leverage for our lower volume designs. Can you tell us which device(s) these tools will be targetted at? (If the SDR app really takes off, I bet Xilinx will soon add ICAP to Spartan devices!) And how far along the development is? I guess I'll need to talk to my FAE under NDA. Cheers, Syms.

Symon,

Virtex 4 is the target family for support. Although it is backward compatible to V2, if and when they do it.

The DSp group here at Xilinx is doing this, and they have press releases, articles, etc. planned to go out, so I won't steal their thunder.

Contact your FAE for details. I believe they are preparing to beta trials with early access customers (maybe you will be late!).

Austin

Sym>

"Meeting Software Defined Radio cost and power targets: Making SDR feasible"

By Manuel Uhm, Xilinx and Jean Belzile, ISR

The vision of software reconfigurable radios is finally a reality, but implementations are not as efficient as they could be. Although the radio itself can be programmed to realize multiple waveforms for joint service interoperability, current implementations require redundant hardware for multiple channels.

A better approach is to use higher performing programmable logic that can be partially reconfigured in-system. This shared resources method allows not only the radio to implement multiple waveforms, but eliminates redundant per- channel hardware. Partially reconfigurable FPGAs will save space, weight, power, and cost.

-- end excerpt --

-or-

speaking of ICAP, i don't know how to write the code to control the readback operation of configuration frame to BRAM. can you give me some suggestion?

now, i am planning to implemente partial reconfiguration by SystemACE CF,

i can obtain the partial bitstream through modular-based design flow introduced in XAPP290, then produce system .ACE file, and load the partial bitstream from CF in run-time.

do you think this way is viable?

Will do Austin, thanks for the heads up. Syms.