> Add a million LUTs and several thousand special-purpose blocks (ALUs, CAM, SRAM, DSPs, etc.) on CPU die that can be reconfigured within a few 10k cycles

LUTs are implemented as a cascade of muxes that are controlled by local latches that are set at configuration time through a scan chain. Scan chains are key to letting you configure all these LUT control latches across the whole chip in an area-efficient manner, but there's a severe time vs area trade-off since you're essentially configuring one LUT control bit (a vanilla 6-LUT has 2^6 = 64 control bits) per scan chain cycle per scan chain. FPGAs already suffer ~30x area overhead for LUT logic compared to equivalent ASICs, so adding a lot of additional area to enable much faster reconfiguration seems like a tough sell. Matrix addressing as used in DRAMs and LED/LCD displays is another sweet spot on the time vs area trade-off curve. Not sure if anyone's ever done an FPGA using that as the configuration topology, but it'd probably make a fun dissertation topic.

There needs to be a marrying of software and hardware -- and processor instructions to support that. This is hierarchical reconfigurable cache-based architecture I designed a while ago at Intel; I doubt they have touched it but they do own it.

https://www.google.com/patents/US20170153892

Just a thought - I suppose you wanted to post with a throwaway account, but claiming to be the inventor of the patent gives your identity away

Sure, but this way his main account is not linked to his name.

Otoh, he could have just written "I've found this patent" and nobody would have known he was the author.

But no one would know the author was referencing his own patent and thus knowledgable about the subject if one wanted to conversate on it

It's still terrible opsec. Of course, as always, it depends on the threat model. Still, linkage and contamination are deadly - why give up more information than absolutely necessary for your adversar[y|ies] to use against you in the future. All it takes is one mistake or a few 'almost mistakes'.

What does it have to do with opsec?

Transmeta code-morphing? VLIW?

Intel do have ARM+FPGA products already from Altera, as do Xilinx.

It will be interesting to see if Intel replaces the ARM CPU with a variant of x86.

Would anyone use it? I wouldn't. Intel's embedded offerings are weak and tend to get cancelled.

Yes, I've evaluated some of them too (great for some projects that need like a RPi but with custom digital / DSP logic), they're just not exactly mainstream as Xeon processors.

I have only used the original Xilinx one but ARM is pretty mainstream, the newest ones even have Mali GPUs.

I would expect a Xeon+FPGA to be at a very different price point from the ARM+FPGA devices, it will be interesting to see whether Intel carry on selling ARM ones or also produce an Atom+FPGA equivalent.

I thought FPGAs had a limited number of updates, enough to preclude this level of dynamism?

Not really. FPGAs tend to be accompanied by a flash memory storing the firmware, which of course has limited erase cycles, but you can also upload the firmware through other means.

The configuration is held in SRAM cells in most FPGAs. Like the other commentor states, the SRAM can be loaded in different ways, some of which have write cycle limitations.

Most are loaded from SRAM or similar, but it could be fairly simple to make it load from your main RAM and then there wouldn't be any issue there.