Because hardware can always be faster than software ?

Here is a concrete example of where reconfigurable FPGAs were indispensable, and performed in a manner impossible for ASICs to reproduce.

The BaBar particle physics experiment ran at the SLAC B-Factory from 1999 to 2008. During that time the accelerator increased its performance (delivered collisions) by two orders of magnitude, ultimately exceeding its original design by a factor of eight. The extremely high event rate led to increased deadtime in some of the detector readout systems (a system would still be processing one event when a trigger to read out the next event arrived).

I managed the main drift chamber of BaBar, a system to read out coordinates of trajectories followed by particles produced in the events. The readout system had over 7,000 channels, which were read on each event in the form of a 32-bin digitized waveform (1 ns time resolution). The digitization was done with a custom ASIC chip, and the data from all non-empty channels was shipped over GHz optical fibers to single-board computers for processing. The waveforms were "feature extracted", and the leading edge time, pulse height, and zero-subtracted integral from each waveform (~6.5 bytes per waveform), for each event, were recorded and shipped to a Linux farm for recording and analysis.

In 2004, we were experiencing routine periods of 2-3% deadtime, and occasionally periods above 20%. We decided to upgrade the front end electronics so that the feature extraction could be performed there, and only the extracted parameters from the waveforms shipped up to the SBCs. That would reduce the data volume, and hence increase the maximum event rate, by a factor of five.

The readout board was designed around the Xilinx Spartan 3 FPGA, and included SRAM for the firmware which could be loaded via the command path on the optical fiber connection from the SBCs. Since the detector was installed on the accelerator behind radiation shielding, it would be impossible to use a common "JTAG" interface to do the uploading by hand. This system allowed us to fix software bugs, and upgrade the feature extraction software, without requiring physical access to the detector components (a major engineering issue).

In a hard radiation environment, single-event upsets (SEUs, caused by charge particles impacting the electronics and depleting a gate randomly) can be significant. The Spartan 3 was large enough that we could install and run two parallel copies of the firmware, implementing a primitive form of majority logic: a small comparator block would check the output of the two firmware copies, and if they were not identical, it would raise a hardware error condition and disable the readout.

When that error was detected, the SBC would automatically transfer a new copy of the firmware to the readout board's SRAM, and direct the FPGA to reconfigure itself. This allowed our system to recover from SEUs smoothly, with a pause to the data acquisition system of about 15 seconds.

ASICs are as prone to SEUs as FPGAs are. The difference is that ASICs can't be "reset" the same way. Once damaged, they are damaged forever. ASICs used in space or in high-radiation environments must be built both with multiply-redundant circuits, and with very large feature sizes (SEUs affect small features much more than large ones).

ASICs require a long lead time. The project I describe was completed, from initial design review through to deployment on the SLAC beamline, in six months. After deployment, we upgraded the firmware three times, without requiring any access to the detector. ASICs probably would have required at least a year of effort, including delivering and testing prototypes before the final fabrication run. Any bugs found after deployment could not be fixed, but would require a new fab and substantial downtime to remove and replace all of the faulty chips.

I'm not sure I understand your questions. Why don't you provide references to whatever it is you're asking about?

All FPGA's are "reconfigurable" -- you can always upload a new program, usually through a JTAG interface on the board.

Why do you think that being able to upload new firmware (e.g., to fix bugs) would NOT be an improvement?

If you want to know how to upload firmware to an FPGA, then you will probably need to study the specifications and manuals from the manufacturer of the FPGA you are interested in using for your application.