Would you ever have FPGA or PICs etc reconfigure them selves insitu for differe

[Beamin]

Different applictions?

Say you had a all in one product that maybe had to pick up different RF signals and you had to decode them in a small handheld unit. (just an example think of any thing where you have a fixed number of high level logic chips in one product that need to do very different things.) Instead of having a dedicated FPGAs or PIC to do each task you could just have one or two that would be reflashed as you were using the unit: Maybe the FPGA needs to act as GSM receiver then the next moment it has to act as GPS receiver etc etc. Is it practical to do this and have their info stored somewhere and the same chip would use the data it got from its last configured state to calculate something then shoot that into the memory buffer and have it transformed into its other role and process the data. Kind of confusing but might offer a way to make small low chip count devices do different things at the expense of time while the module goes into its different roles. Or maybe time wouldn't be an issue for tasks where one device would normally sit idle as the other chips do their thing. This must have some niche application. where a main but simple controller dictates who gets to be what, when needed, and sends and stores data as the modules change roles. If this could be done very fast it would make a simple low part count device instead of having a bunch of pricey FPGA all do just one dedicated task.

[hans]

It usually becomes impractical because reconfiguration times (on current gen devices) are quite long.

In software actually reconfiguration is not even necessary, as it's up to the programmer to decide what code gets executed when.

For FPGAs and similar devices, I know that reconfigurable computing is an active research area, but still very academic.

[nctnico]

My GW Instek GDS2000E oscilloscope does that. It does partial reconfiguration of the FPGA for the various trigger modes.

[Bassman59]

Different applictions?

Not actually different applications, but I had a design with an image sensor that could be run at a wide range of clock frequencies, from something like 180 MHz up to 300 MHz. The FPGA was a Virtex-4 and its PLL had different build-time set-up requirements based on whether it was running at 240 MHz and above or below 240 MHz. The solution was two different FPGA loads. The configuration was managed by a microcontroller, so I changed the SPI flash that held the configuration to one with doubled size, stored both binary configuration images, and upon command, one or the other would be loaded. It works well, and I think that managing FPGA firmware updates in this manner is straightforward, moreso than trying to work out how to manage an onboard micro programming a standard FPGA config EPROM that has a JTAG interface.

[TomS_]

A lot of microcontrollers these days have self programming capabilities - i.e. they can write "code" to their own flash during operation. Ive been working on a project which uses such a capability to enable "firmware upgrades" to be applied once the MCU is soldered to the board without requiring the use of ICSP - as many others have done before me. I also use some of the spare space to "emulate some EEPROM", since the MCU I use doesnt actually have any built in EEPROM.

So in theory, yes, you could do something like this, but the question becomes whether it is practical to do it, or to build a system that is better suited to the many tasks you want it to do. e.g. a small processor and some external memory and flash storage that can hold all of the code that might need to be executed for all of the required scenarios is not impractical to achieve. Re-programming the device on the fly just to switch between one mode or another just sounds like you should have chosen a device with more space for storing code really... What you save on internal flash you could easily spend, and then some, on external storage.

Side story: Ben Heck recently did a tear down of a small hand held arcade game which infact turned out to be 3-4 different games in one, with the game set to match the branding on the case via a jumper or some such on the PCB at the factory. He modded it with a switch so that you could select from any of the available games afterwards. So certainly it seems, "burning" some excess flash for a more universal product isnt out of the question even for low cost devices.

[NorthGuy]

The CPUs which can run code from RAM are very easy to re-program with whatever program you want to run at the moment, then you can unload the program and load a different one. PCs, tablets, phones - all work that way. They're constantly loading and unloading code very quickly. That's how a single PC can do practically any job.

The MCU which only can execute from flash (such as PIC) are hard to re-program - it takes time and the number of re-programmings is limited (usually 10-100k) by the flash wearing out. So, frequent re-programming is not practical.

FPGAs is a different story. FPGA can be re-configured fully or partially very quickly and such methods are widely used. However, it is not as easy to dynamically combine pieces in FPGA as it is to combine programs on CPU. Therefore, effective use of dynamic re-configuration requires considerable effort.

[rstofer]

In the FPGA world, it is possible to have multiple boot images in platform flash.

https://www.xilinx.com/support/documentation/application_notes/xapp483.pdf

Of course the external world of IO devices has to be the same under each configuration.

Reconfiguration while running is a special topic.  I suppose it is possible in theory but I haven't seen it done in practice.  Then there is the thought:  "What is computing?"  We can get into all kinds of fun with biological computing:

https://www.omicsonline.org/biological-computers-their-mechanism-2155-952X.1000122.php?aid=3200

[amyk]

That's how the PICkit works, if I remember correctly...