Comment by burntrelish1273 | Hacker News Reader

Comment by burntrelish1273 | Hacker News Reader

burntrelish1273

The biggest problem with reconfigurable computing is it's either an afterthought, tools are too narrow/proprietary or an extra add-in card.

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 (ie process context), and then future AI-enabled optimizing compilers could incrementally profile and accelerate applications with reconfigurable resources in new, creative and interesting ways. IRAM and similar zillion core approaches are another approach to solve traditional performance locality bottlenecks: distribute processing, interconnect and RAM amongst each other. It makes the most sense to co-evolve such a radical undertaking gradually with compiler vendors and large customers so that support and usability is working from launch, rather than just throwing silicon over the wall and using the "hail mary" method of product (non)design.

PS: Intel could push almost any new on-die CPU technology service/product into the mainstream right now on the server side because of their de-facto monopoly oligopoly dominance. I don't think they will as there is immense organizational pressure to not innovate too much.

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

Reply on news.ycombinator.com