5 ms·
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
by burntrelish1273 9y ago
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.
- throwaway4590 9y agoThere 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 https://www.google.com/patents/US20170153892
- mankash666 9y agoJust 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
- chaosite 9y agoSure, but this way his main account is not linked to his name.
- amelius 9y agoOtoh, he could have just written "I've found this patent" and nobody would have known he was the author.
- BoorishBears 9y agoBut no one would know the author was referencing his own patent and thus knowledgable about the subject if one wanted to conversate on it
- justinjlynn 9y agoIt'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'.
- BoorishBears 9y agoWhat does it have to do with opsec?
- burntrelish1273 9y agoTransmeta code-morphing? VLIW?
- fulafel 9y agoI thought FPGAs had a limited number of updates, enough to preclude this level of dynamism?
- sannee 9y agoNot 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.
- blackguardx 9y agoThe 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.
- rightos 9y agoMost 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.
- psykotic 9y ago> 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.
- rjsw 9y agoIntel 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.
- Gracana 9y agoWould anyone use it? I wouldn't. Intel's embedded offerings are weak and tend to get cancelled.
- burntrelish1273 9y agoYes, 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.
- rjsw 9y agoI 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.