15 ms·

AMD Patent Reveals Hybrid CPU-FPGA Design That Could Be Enabled by Xilinx Tech

278 points by craigjb 6y ago

Traster 6y ago
I hate to be that bucket of cold water, but there's multiple reasons FPGAs haven't been successful in package with CPUs. Firstly, the costs of embedding the FPGA - FPGAs are relatively large and power hungry (for what they can do), if you're sticking one on a CPU die, you're seriously talking about trading that against other extremely useful logic. You really need to make a judgement at purchase time whether you want that dark piece of silicon instead of CPU cores for day to day use. Secondly, whilst they're reconfigurable, they're not reoconfigurable in the time scales it takes to spawn a thread, it's more like the same scale of time to compile a program (this is getting a little better over time). Which makes it a difficult system design problem to make sure your FPGA is programmed with the right image to run the software programme you want. If you're at that level of optimization, why not just design your system to use a PCI-E board, it'll give you more CPU, and way more FPGA compute and both will be cheaper because you get a stock CPU and stock FPGA, not some super custom FPGA-CPU hybrid chip. Thirdly the programming model for FPGAs are fundamentally very different to CPUs, it's dataflow, and generally the FPGA is completely deterministic. We really don't have a good answer for writing FPGA logic to handle the sort of cache hierarchy, out of order execution that CPUs do. So you're not getting the same sort of advantage that you'd expect from that data locality. It's very difficult to write CPU/FPGA programs that run concurrently, almost all solutions today run in parallel - you package up your work, send it off to the FPGA and wait for it to finish. Finally, as others have said - the tools are bad. That's relatively solvable. For me, it boils down to this, if you have an application that you think would be good on the same package as a CPU, it's probably worth hardening it into ASIC (see: error correction, Apple's AI stuff). If you have an application that isn't, then a PCI-E card is probably a better bet - you get more FPGA, more CPU and you're not trading the two off.
- jacoblambda 6y ago
  I definitely agree that a PCI-E card is preferable. Hell even if you have it in CPU, you probably want it sat on the PCI-E bus anyways so it can P2P DMA with other hardware. Also (not disagreeing but I'm curious), last time I checked FPGAs could pull off some level of partial reconfiguration in the millisecond and sub millisecond ranges. I may be a bit off on these times but I saw them in a research paper a few years back. What types of speed would be necessary for CPUs to actually be able to benefit from a small FPGA onboard (rather than on an expansion card) with all the context switching.
  - akiselev 6y ago
    High end FPGAs are theoretically capable of millisecond fast partial reconfigurations but doing so requires making a lot of tradeoffs that just highlight the impedance mismatch between the generic nature of CPUs and the purgatory that is FPGAs. The more of the FPGA you want to reconfigure, the longer it takes (stop the world, depending on which parts its touches) and unless the reconfigured portion is limited to a standard bus, the reconfiguration won't work (or you have to reconfigure more of the design to deal with different interfaces, timings, etc. blowing up reconfiguration time and defeating the purpose). All of the bitstreams have to be compiled ahead of time as well. Unless latency is so critical that the speed of light is the limiting factor, partial reconfiguration just replaces PCIe with a much harder to work with AXI interconnect (or similar, but it always end up being AXI...).
- imtringued 6y ago
  It's easier to provide "custom instructions" and only accelerate CPU bottlenecks if you don't have PCIe as a massive bottleneck. If you are using an accelerator behind a bus you always have to make sure there is enough work for the accelerator to justify a data transfer. GPUs are built around the idea of batching a lot of work and running it in parallel. You can make an FPGA work like that but you are throwing away the low latency benefits of FPGAs.
  - wtallis 6y ago
    Even the best-case scenarios for integrating a FPGA onto the same die as CPU cores would still have the FPGA separate from the CPU cores. It's really not possible to make an open-ended high bandwidth low latency interface to a huge chunk of FPGA silicon part of the regular CPU core's tightly-optimized pipeline, without drastically slowing down that CPU. The sane way to use an FPGA is as a coprocessor, not grafted onto the processor core itself. Then, you're interacting with the FPGA through interfaces like memory-mapped IO whether it's on-die, on-package, or on an add-in card.
    - Traster 6y ago
      Yeah, worth mentioning highly optimized FPGA designs run at up to 600MHz (or to put it another way, 400MHz lower than what Intel advertised 4 years ago). So at a minimum, you're going to clock cross, have a >10 cycle pipeline at CPU speeeds (variable clock) and clock cross back.
    - therealcamino 6y ago
      > It's really not possible to make an open-ended high bandwidth low latency interface to a huge chunk of FPGA silicon part of the regular CPU core's tightly-optimized pipeline That's what's interesting about the article, because that's what the patent is about: "implementing as part of a processor pipeline a reprogrammable execution unit capable of executing specialized instructions".
- pranavjoneja 6y ago
  ASICs only make sense if you have high volume. PCI-e takes a lot of resources/space. The sweet spot for FPGA-CPU hybrid chips are embedded devices that are latency sensitive. For example, time-of-flight sensors and specialty cameras.
  - dkersten 6y ago
    I guess to overcome the reconfiguration latency others have mentioned, the use case would be systems that configure their custom instructions once on boot and then the software just sees a cpu as normal, just with these custom instructions. Ie not intended for reconfiguration on context switch.
- phendrenad2 6y ago
  The downside of PCIe is PCIe is very complex. And the tools make interfacing with it bewildering. I really want a PCIe FPGA that looks to me like data magically appears on an AXI bus.
- bfrog 6y ago
  Replace pcie with AXI and that seems to be pretty close to what zynq/cycle v soc have today on the same package?
economusty 6y ago
Computronium
dhruvdh 6y ago
I can't help but think most commentators haven't actually read the article or the patent. This isn't about having an FPGA embedded into the CPU or near the CPU, it's about having a programmable FPGA like execution unit that can be programmed to be say a 4-bit floating point adder, or any other weird execution unit one might need. Why is this important? Have a program that does a lot of integer multiplications? Let's program all of these programmable execution units to multiply integers on the fly, etc. Now your integer multiply throughput is higher, as per the current program's needs. Have lots of weird old x86 instructions you are forced to support but no one actually uses? Don't waste transistors on them just program an execution unit to execute that instruction on the fly, etc. I think it's great, and that most people are missing the point.
- mhh__ 6y ago
  > Don't waste transistors on them just program an execution unit to execute that instruction on the fly, etc. Possible, but the "x86" part is already a big decoder in front of a murky processor underneath so this is already what the CPU does - if you removed the reference to an FPGA, rewriting old x86 instructions in terms of "new" ones is microcode.
- ajross 6y ago
  > Have lots of weird old x86 instructions you are forced to support but no one actually uses? Don't waste transistors on them That's been the role of microcode for like three decades now. Why does it matter if the instruction no one uses is implemented with FPGA gates or uops? No one uses them.
  - webmobdev 6y ago
    Theoretically, Now you can create "micro-codes" in the CPU for your specific needs - e.g. scientists do a lot of calulation and would like a processor optimised for that. Now they can use the FPGA to do it. You want a CPU instruction that is optimised for something else - you can program the FPGA for that.
    - 6y ago
GuB-42 6y ago
Everyone seems to be talking about accelerated instructions but how about I/O? FPGAs are awesome at asynchronous I/O and low latency. We could implement network stacks, sound and video processing, etc... It can start a TLS handshake as soon as the electrical signal hits the ethernet port, while the CPU is not even aware of it happening. It can timestamp MIDI input down to the microsecond and replay with the same precision. It can process position data from a VR headset at the very last moment in the graphics pipeline. Maybe even do something like a software defined radio. Basically every simple but latency-critical operations. Of course, embedded/realtime systems are a prime target.
- slimsag 6y ago
  A fair amount of enterprise NICs in data centers do exactly this, e.g. Intel FPGA smart NICs I don't know enough to know how this being on the CPU would affect performance in this scenario, but I'd love to learn more!
- AlotOfReading 6y ago
  That's pretty much what Xilinx's Zynq product lines are already targeting, including embedded. They're comparatively nice boards to work on, as long as you can swallow the BOM cost.
- andoriyu 6y ago
  Network example is wasteful. There are already NICs that have FPGA and a whole set of linux's kernel features. You wouldn't want that to be that far away from the NIC itself. PTP works just like that - timestamps incoming and outgoing packets right after/before packet hit the wire. There is eXpress Data Path that can offload eBPF programs to NICs and deal with packets without them even coming into even kernel at all. High Frequency Traders do exactly that IIRC today. As for video processing codecs today are way too complex to be run there. Well, no one will stop you from running something like an integer DCT part on FPGA. VR thing... Generally, aside from Nvidia companies don't want to ship entire FPGA to end customers (guess why Nvidia G-Sync monitors used to be so expensive). Something like Snapdragon XR2 "solves" VR. Also, in order to render a picture you need to know headset position early, not at the last moment. How would you know what to render? How useful is the subject depends entirely on FPGA capability, and it's size. I bet it will be more useful for things like implementing some hash function there or something like that. IMO this will be a very niche product inside already niche market.
AlphaSite 6y ago
This seems more appropriate for GPUs than for CPUs where it’s high throughput and you can eat the latency cost of reconfiguring the node.
ajb 6y ago
How patents happen: An alarm goes out: our company has fewer patents than company X! In fact, we have the smallest patent hoard of our competitor group. If they sue us we might not have enough patents to sue them back! We must have more patents! Everyone who gets a patent gets a bonus! ( Exit CEO, trailing exclamation marks. All the engineers file their pet idea as a patent, hoping management will be interested in building it). (Some years later) Okay, some of those patents we filed are a bit silly. But at least we now have a huge, intimidating patent pile! No one will dare sue us now! Mua ha ha! But let's be a bit more careful what we give those patent bonuses for. (Meanwhile at company X: our company has fewer patents than company Y!...) The above is a true story, happened to me. Well, apart from the moustache twirling. My name is on some not very practical patents. So I'm not very convinced by stories which read the tea leaves from patents as to what a company intends ( Or economists trying to infer innovation rate from patent filing rate). Another problem is that the patent office is slow. Unless the company is General Fusion, most probably the product will be out before the patent.
- skybrian 6y ago
  I almost got my name on a patent that way for sharing an idea in an internal forum. I refused (well, I asked politely) and they took my name off it. (There was someone else in the conversation as well.)
  - gaudat 6y ago
    Sounds like it's a bad idea to have our names on a patent from the way you said it. Can you enlighten us on that?
    - ericlewis 6y ago
      Anecdata: but, just because I threw in a couple of suggestions I didn’t feel like I deserved it. Also, don’t much care for patents personally.
    - skybrian 6y ago
      I don't like the idea of software patents, generally, and would feel weird arguing against them if I had my name on one.
whatever1 6y ago
How fast can an FPGA be reprogrammed? If I close my FPGA accelerated machine learning training algorithm, and then open a PC game, would it be feasible to load the new gaming-oriented instructions in ~10-30" that a PC game takes to open?
- gh02t 6y ago
  Programming a bitstream onto the FPGA is relatively quick, it's perfectly feasible. The time consuming part is in development and synthesis.
- dewhelmed 6y ago
  What sort of gaming-related workload do you think an FPGA would be suitable for? I don't know much about the gaming world, but isn't the majority of the computational workload graphics-rendering related, in which case, the GPU architecture is the best candidate to iterate on?
  - whatever1 6y ago
    Not a game developer, but I believe that game mechanics, lighting and "AI" are all handled by the CPU.
galaxyLogic 6y ago
I think neural networks and AI might be a good application area for this.
signa11 6y ago
this approach is not new, and has been toyed around since the 1960 (!), see G. Estrin's work on adaptive architectures for example. i got to know about this as part of PRISM (processor reconfiguration through-instruction set metamorphosis) work in the early 90's. there is a very cool paper by the same name. check it out ! ps : PRISM Paper (http://class.ece.iastate.edu/tyagi/cpre583/documents/prism.pdf http://class.ece.iastate.edu/tyagi/cpre583/documents/prism.p...)
CoffeeDregs 6y ago
This looks a bit like the old (2000s) work of Leopard Logic or Tensilica. Exciting stuff. One important note (based on some comments here): generally, these in-CPU FPGAs have very fast reconfiguration. Not sure if it's 1, 10 or 100 cycles but it's not milliseconds. Actually, (in past examples) configuration might take milliseconds but it would load a number of planes of configurations: plane 0 might be MP3 audio device; plane 1 might be MPEG2 video device. Then reconfiguration is: switch to plane 1. This AMD proposal looks like it's much more tightly integrated into the CPU so it's got to be even faster. Combine that with the deep knowledge of processor internals you'll have to have to code for this thing and I'm having a hard time seeing you and me having much luck tinkering. This is probably 99.99% data center with gnarly NDAs and field support.
nynx 6y ago
This is exciting! Would be cool if it could access some sort of gpio as well!
deleted 6y ago
[deleted]
user5994461 6y ago
Yet another patent that should never have been granted. SoC have been a thing for a long time. SoC = CPU + FPGA on a single chip. Looking at the patent, the list of 20 claims is absurd. The title says it all "... PROGRAMMABLE INSTRUCTIONS IN COMPUTER SYSTEMS", they're trying to patent anything that can run or dispatch instructions.
- cptskippy 6y ago
  That's how the industry works. You gather and hoard as many frivolous patents as you can in a cold war arms race. If a new company threatens your business, you search your portfolio for a patent they violated and sue them. Companies who grow to a certain size look to be acquired by larger firms with bigger war chests. Sometimes companies recognize patents are stifling progress and engage in cross licensing or pooling of patents. Sometimes they do it to gang up on a new rival.
- rcxdude 6y ago
  No they're not. Claims 1, 8, and 15 are the only independent claims in the patent (if you're not infringing the independent claims you're not infringing any of the dependent claims: the tradeoff is the more general independent claims are generally easier to invalidate). All of them depend on having a dispatch unit which can be programmed to dispatch instructions into some logic which is configured by a bitfile (and also having the code and bitfile alongside each other and loaded by the same system). Most FPGA SoCs don't have a programmable instruction dispatch unit (which seems to me to be the core of the patent), and they generally do not have the software and bitfield side-by-side and loaded by the same loader, though that is probably an element which is quite vague and could be argued either way. I don't like patents in general (and especially in software), but this patent is not as general as you claim.
- refulgentis 6y ago
  >> the list of 20 claims is absurd. Claims are a union - each individual claim may sound simple, what matters is the combination. >> The title says it all "... PROGRAMMABLE INSTRUCTIONS IN COMPUTER SYSTEMS", they're trying to patent anything that can run or dispatch instructions. No. The title of a patent is not a patent.
BryanBeshore 6y ago
Lisa Su is a fantastic CEO. Time will tell what the impact of AMD’s acquisition of Xilinx will be (should it close), but this shows the strategy and execution behind Su and team. While a lot of acquisitions don’t pan out, this seems great.
- parsimo2010 6y ago
  AMD purchasing Xilinx is a reaction to Intel purchasing Altera five years ago. Dr. Su might be a good CEO for other reasons, but this isn't something that illustrates brilliant strategy on her part.
  - cptskippy 6y ago
    The industry doesn't move overnight. AMD might have seen where Intel was going and didn't want to be caught off guard, or that might be the alternative to Apple approach of dozens of coprocessors on a chip.
  - sitkack 6y ago
    This is AMD competing with Nvidia, not AMD competing with Intel.
  - GeorgeTirebiter 6y ago
    Xilinx had laid off a good chunk right before their sale to AMD. Xilinx was having some financial troubles; when that happens, investors want out before a company craters. So selling themselves was one possible solution.
  - rusticpenn 6y ago
    Intel did not produce anything worthwhile from that strategy yet and I have seen no plans either. I use Altera for all my FPGA needs.
    - ATsch 6y ago
      A large reason for the deal with Altera was that Altera already used intel for fabrication. I understand Intel's 10nm and 7nm failure has hurt them a lot in that regard, quite the opposite of the expected synergy. Unlike Xilinx for AMD, they didn't really have any other technologies intel needed either, the biggest advantage was fabrication and that fell through.
qwerty456127 6y ago
I could never stop wondering why is this not a norm yet. Why doesn't every computer have an FPGA.
- imtringued 6y ago
  Existing FPGA vendors made sure their products remained in a lucrative niche by maintaining full control over the development process for FPGA designs.
- rcxdude 6y ago
  Apart from the tooling woes others have mentioned (it's hard to get across how much FPGA tooling sucks compared to software tooling), FPGAs occupy a strange set of niches, but it's not clear how many are ones which would benefit the average PC or server. If you want raw memory bandwidth and FLOPs, a GPU is better (on speed, power, and price). If you want to evaluate complicated conditions and control flow, a CPU is better (in the same catagories). Because FPGAs are very power hungry and generally slower than the raw silicon, they only really give you more compute if what you want to compute is either far enough off the beaten path that some custom logic is much more efficient than the available instructions, and/or it benefits from a specific parallel datapath which doesn't easily fit on a GPU or CPU (GPUs being the best at embarrasingly parallel systems and modern CPUs being good at parallelising general purpose code reasonably well). In practice you see FPGAs mostly in two areas: specialised embedded applications which benefit from heavy custom I/O and/or some efficient specific DSP but don't have enough volume to justify an ASIC design, or in accelerators for simulating ASIC design.
- stefan_ 6y ago
  Because adding a layer of abstraction to silicon transistors makes for terrible performance and energy usage. Every other year or so someone "rediscovers" FPGA and thinks this niche architecture is poised for a total revolution of how computing works, think drag&drop hardware and super fast custom everything. It never happens and it will never happen because customization, much like premature optimization, is the root of all evil and also just.. see the first paragraph.
  - 6y ago
leecb 6y ago
Everything described in the article sounds exactly like some of the Virtex*-FX products from more than 10 years ago. For instance, the Virtex4-FX had either one or two 450MHz PowerPC coresembedded in it, where you could implement 8 of your own additional instructions in the FPGA. This is effectively now a CPU where you can extend the instruction set, and design your own instructions specific to your application. For example, you might make special instructions using the onboard logic to accelerate video compression, or math operations; I know of one application that was designed to do a 4x4 matrix multiply per cycle. https://www.digikey.com/catalog/en/partgroup/virtex-4-fx-series/76285 https://www.digikey.com/catalog/en/partgroup/virtex-4-fx-ser... https://www.xilinx.com/support/documentation/data_sheets/ds112.pdf https://www.xilinx.com/support/documentation/data_sheets/ds1...
- thrtythreeforty 6y ago
  For those curious, Xtensa is a similar embeddable architecture (known especially for its use in the ESP32 microcontroller) that allows broad latitude to the designer to customize its instruction set with custom acceleration. The integration is very good, the compiler recognizes the new intrinsics and the designer has control over how the instruction is pipelined into the main processor. Unfortunately it's very proprietary, and as far as I know there isn't an at-home version you can play with on FPGAs. But this kind of thing does exist if you can afford it - you don't have to roll your own RTL.
- jng 6y ago
  I am very familiar with the new Zynq family, embedding ARM cores on the same die together with FPGA fabric. I didn't know that the PowerPC version allowed such a tight coupling as handing off an instruction to programmable logic, the current Zynq models are much more lightly coupled, using AXI buses to connect the ARM cores with the PL (and many other components on the same SoC).
- mhh__ 6y ago
  What was the latency like to actually get data into your shiny new instruction e.g. do I get a 14 stage pipeline stall to actually use the instruction?
rwmj 6y ago
About *!$% time! I was hoping Intel would do something like this when they acquired Altera a few years back. Does anyone know why Intel acquired Altera?
- d_tr 6y ago
  AFAIK there exist some Xeon + FPGA chips. No clue about availability though...
  - harry8 6y ago
    Are they connected by the pcie bus though? https://www.xes-inc.com/ https://www.xes-inc.com/
- PedroBatista 6y ago
  Almost the same reason someone buys a Peloton bike or rusted old Porsche. Because someone had a dream last night and have the money.
  - sbrorson 6y ago
    chuckle This is true. As far as I can see (as a hardware engineer frequently doing FPGA stuff) The Intel/Altera combo has not produced any new products nor yielded any customer benefit beyond what would have happened if the two companies had remained independent. But I'll bet the "business strategists" at each company who thought this one up made a pile of money from the deal.
mhh__ 6y ago
Xilinx already have ARM cores in their FPGAs so I wonder which way they'll go - I'd honestly prefer a neoverse core than an X86
- efferifick 6y ago
  Not sure how realistic it would be, but I would like to see a RISC-V base core, and the FPGA implementing the extensions. Why? Because it would be cool! Also, I don't really see a use case except for debugging compilers supporting multiple RISC-V extensions and what not.
  - craigjb 6y ago
    Microchip has the product for you then! Well, the RiscV part anyway. https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga https://www.microsemi.com/product-directory/soc-fpgas/5498-p...
- sbrorson 6y ago
  You are right the ARM cores, mostly. Xilinx Zynq devices have ARM A devices built into them as "hard" cores. That is, the ARMs are instantiated directly in silicon, not as "soft" cores which take LUTs (gates) from the FPGA fabric. The ARM A is a microprocessor (not a microcontroller) powerful enough to run Linux. The ARM connects to the FPGA fabric using a so-called AXI bus, which is a local bus defined by ARM. Xilinx supplies a bunch of "soft" cores which you can instantiate in the FPGA and integrate with the ARM. Of course, you can write your own logic for the FPGA too, as long as you can figure out how to interface to it using one of the AXI bus variants. Several vendors offer experimenters platforms which are affordable enough for hobbyists and folks making engineering prototypes. Examples are the Avnet's Zed board and Digilent's Zybo board. The biggest problem with the Zynq ecosystem is that the Xilinx tools -- Vivado/SDK and whatever they renamed it to last year -- are steaming piles of smelly brown stoff. Vivado is buggy, poorly supported, has bad documentation, and the supplied examples typically don't work in the latest version of Vivado since they were written long ago and have been made obsolete via version skew. An absolute disgrace compared to what software engineers are used to. The SDK is basically Eclipse which has its own problems, but is not as bad as Vivado. Ask me how I know. I think AMD and Xilinx have a long way to go before they can satisfy the hype and speculation I see in all the posts here. I suppose one could shell out $20K for a seat of Synopsys if one wanted a decent set of dev tools, but that's not the direction most software engineers are going nowadays. Also, assuming NVidia completes its acquisition of ARM, the whole Zynq ecosystem is imperiled since it pits ARM against NVidia.
ineedasername 6y ago
Sounds like spending a few hours a month learning an HDL could be a good long-term career decision.
- efferifick 6y ago
  While sibling comments mention that it is probably wiser to learn digital logic before HDL (and I agree with them), I think it is important to also consider that there is now High Level Syntehesis where programming languages similar to C (e.g., OpenCL) can compile to VHDL. HLS may lower the barrier for programmers to take advantage of FPGAs. However, whether the design can compile to fit the constraints of the FPGA available is another question that I do not know the answer.
- deelowe 6y ago
  Anyone who is considering this, make sure you learn digital circuits first.
- seabird 6y ago
  You're going to need to commit a lot more time than that. HDLs and the surrounding concepts have key fundamental differences from software that a lot of developers have a hard time stomaching. That's why high-level synthesis is the FPGA industry's City of El Dorado; software developers would be able to create acceleration designs without having to build up a fairly large new skillset.
  - imtringued 6y ago
    I've never understood this argument. The change in mindset is extremely small. It's merely a matter of awareness. High level synthesis can work just fine if you don't go overboard with constructs that are hard to synthesize. There is no fundamental reason why a math equation in C should be harder to synthesize than the Verilog or VHDL equivalent.
    - mhh__ 6y ago
      > math equation in C I think it's the bits around the outside of the (say) math kernel which will trip up an "ah it's just like C!"-thinking programmer.
ohazi 6y ago
For decades, the FPGA vendors have had this fever dream of "an FPGA in every PC" -- either as an add-on card, or as part of the chipset on a motherboard -- that would enable a compiler or operating system to seamlessly accelerate arbitrary tasks on demand. In my opinion, the problem has always been their software: the FPGA vendor tools are slow, bloated monstrosities. The core of these tools are written by the big three EDA vendors (Cadence, Synopsys, and Mentor Graphics) rather than the FPGA vendors themselves. The licenses include ridiculous, paranoid restrictions [1] and force the FPGA vendors to keep their bitstream formats and timing databases secret [2] in order to prevent competition from other tool vendors. Most FPGA vendors didn't see this as a problem, but even the ones that did didn't have much of a choice, because the tool market is a cartel. Thankfully, we now have an open source toolchain [3] with support for a growing number of FPGA architectures [4], and using it vs. the vendor tools is like using gcc or llvm vs. a '90s era, non-compliant C++ compiler. It even has a real IR that isn't Verilog, which has made it easier to design new HDLs [5]. I don't see how a dynamic FPGA accelerator platform can be even remotely viable without this. It's the difference between a developer getting to choose between one of a few dozen pre-baked designs that lock up the entire FPGA (and needing to learn how to shovel data into it), vs. a compiler flag that can give you the option of unrolling any loop directly into any inactive region of FPGA fabric. It would be quite the cherry on top to see AMD build something interesting in this space. But unless they're willing to fully unencumber at least this one design, I think the effort is likely to fail. The open source guys are chomping at the bit to make this work, and have been making real progress lately. Meanwhile, the EDA vendors have been making promises, failing, and throwing tantrums for the last 20 years. It's time to write them off. [1] https://twitter.com/OlofKindgren/status/1052822081652617221?s=20 https://twitter.com/OlofKindgren/status/1052822081652617221?... [2] Imagine trying to write an assembler without being allowed to see the manual that tells you how instructions are encoded. It's like that, but the state-space is hundreds to thousands of bytes in multiple configurations rather than a few dozen bits. [3] https://github.com/YosysHQ/yosys https://github.com/YosysHQ/yosys [4] https://symbiflow.github.io/ https://symbiflow.github.io/ [5] https://github.com/m-labs/nmigen https://github.com/m-labs/nmigen
- travis729 6y ago
  I would love to hack on FPGAs but always run into the issue of closed toolchains. The recent open source work is a breath of fresh air, but we need to see an FPGA vender that embraces and sponsors this work.
d_tr 6y ago
The main reason I am interested in this acquisition is a (faint) hope that they open some specs up to help projects like SymbiFlow.
Scene_Cast2 6y ago
A killer tech for this would be a framework that automatically reprograms the FPGA and offloads the work if it makes sense. For example - running k-means? Have your FPGA automatically (with minimal dev effort) flash to be a Nearest Neighbor accelerator. The problem is finding a way to make that translation happen with minimal dev effort, as software is written rather differently from hardware.
- d_tr 6y ago
  You might want to check the "Warp Processing" project out: http://www.cs.ucr.edu/~vahid/warp/ http://www.cs.ucr.edu/~vahid/warp/. It is probably exactly what you are thinking about. Transparent analysis of the instruction stream at runtime and synthesis and offloading of hot spots to the FPGA.
  - Scene_Cast2 6y ago
    Huh, interesting. It seems that the work doesn't have to be explicitly parallel for this to work, which is a surprise.
    - rowanG077 6y ago
      Why is that surprising. A LOT of statements that are done in programming can be executed in parallel. It's just not worth it to actually make threads for them since the overhead of threads is larger then just executing the set of instructions sequentially. In fact all modern processors take advantage of the data dependencies and execute it in parallel if possible.
- cashsterling 6y ago
  I recommend checking out CacheQ: https://cacheq.com/ https://cacheq.com/ they are working on almost exactly this. If I was an investor, or Intel or AMD, I would buy them and/or invest heavily.
  - therealcamino 6y ago

278 points by craigjb 6y ago

I hate to be that bucket of cold water, but there's multiple reasons FPGAs haven't been successful in package with CPUs. Firstly, the costs of embedding the FPGA - FPGAs are relatively large and power hungry (for what they can do), if you're sticking one on a CPU die, you're seriously talking about trading that against other extremely useful logic. You really need to make a judgement at purchase time whether you want that dark piece of silicon instead of CPU cores for day to day use. Secondly, whilst they're reconfigurable, they're not reoconfigurable in the time scales it takes to spawn a thread, it's more like the same scale of time to compile a program (this is getting a little better over time). Which makes it a difficult system design problem to make sure your FPGA is programmed with the right image to run the software programme you want. If you're at that level of optimization, why not just design your system to use a PCI-E board, it'll give you more CPU, and way more FPGA compute and both will be cheaper because you get a stock CPU and stock FPGA, not some super custom FPGA-CPU hybrid chip. Thirdly the programming model for FPGAs are fundamentally very different to CPUs, it's dataflow, and generally the FPGA is completely deterministic. We really don't have a good answer for writing FPGA logic to handle the sort of cache hierarchy, out of order execution that CPUs do. So you're not getting the same sort of advantage that you'd expect from that data locality. It's very difficult to write CPU/FPGA programs that run concurrently, almost all solutions today run in parallel - you package up your work, send it off to the FPGA and wait for it to finish. Finally, as others have said - the tools are bad. That's relatively solvable. For me, it boils down to this, if you have an application that you think would be good on the same package as a CPU, it's probably worth hardening it into ASIC (see: error correction, Apple's AI stuff). If you have an application that isn't, then a PCI-E card is probably a better bet - you get more FPGA, more CPU and you're not trading the two off.

jacoblambda 6y ago
I definitely agree that a PCI-E card is preferable. Hell even if you have it in CPU, you probably want it sat on the PCI-E bus anyways so it can P2P DMA with other hardware. Also (not disagreeing but I'm curious), last time I checked FPGAs could pull off some level of partial reconfiguration in the millisecond and sub millisecond ranges. I may be a bit off on these times but I saw them in a research paper a few years back. What types of speed would be necessary for CPUs to actually be able to benefit from a small FPGA onboard (rather than on an expansion card) with all the context switching.
- akiselev 6y ago
  High end FPGAs are theoretically capable of millisecond fast partial reconfigurations but doing so requires making a lot of tradeoffs that just highlight the impedance mismatch between the generic nature of CPUs and the purgatory that is FPGAs. The more of the FPGA you want to reconfigure, the longer it takes (stop the world, depending on which parts its touches) and unless the reconfigured portion is limited to a standard bus, the reconfiguration won't work (or you have to reconfigure more of the design to deal with different interfaces, timings, etc. blowing up reconfiguration time and defeating the purpose). All of the bitstreams have to be compiled ahead of time as well. Unless latency is so critical that the speed of light is the limiting factor, partial reconfiguration just replaces PCIe with a much harder to work with AXI interconnect (or similar, but it always end up being AXI...).
imtringued 6y ago
It's easier to provide "custom instructions" and only accelerate CPU bottlenecks if you don't have PCIe as a massive bottleneck. If you are using an accelerator behind a bus you always have to make sure there is enough work for the accelerator to justify a data transfer. GPUs are built around the idea of batching a lot of work and running it in parallel. You can make an FPGA work like that but you are throwing away the low latency benefits of FPGAs.
- wtallis 6y ago
  Even the best-case scenarios for integrating a FPGA onto the same die as CPU cores would still have the FPGA separate from the CPU cores. It's really not possible to make an open-ended high bandwidth low latency interface to a huge chunk of FPGA silicon part of the regular CPU core's tightly-optimized pipeline, without drastically slowing down that CPU. The sane way to use an FPGA is as a coprocessor, not grafted onto the processor core itself. Then, you're interacting with the FPGA through interfaces like memory-mapped IO whether it's on-die, on-package, or on an add-in card.
  - Traster 6y ago
    Yeah, worth mentioning highly optimized FPGA designs run at up to 600MHz (or to put it another way, 400MHz lower than what Intel advertised 4 years ago). So at a minimum, you're going to clock cross, have a >10 cycle pipeline at CPU speeeds (variable clock) and clock cross back.
  - therealcamino 6y ago
    > It's really not possible to make an open-ended high bandwidth low latency interface to a huge chunk of FPGA silicon part of the regular CPU core's tightly-optimized pipeline That's what's interesting about the article, because that's what the patent is about: "implementing as part of a processor pipeline a reprogrammable execution unit capable of executing specialized instructions".
pranavjoneja 6y ago
ASICs only make sense if you have high volume. PCI-e takes a lot of resources/space. The sweet spot for FPGA-CPU hybrid chips are embedded devices that are latency sensitive. For example, time-of-flight sensors and specialty cameras.
- dkersten 6y ago
  I guess to overcome the reconfiguration latency others have mentioned, the use case would be systems that configure their custom instructions once on boot and then the software just sees a cpu as normal, just with these custom instructions. Ie not intended for reconfiguration on context switch.
phendrenad2 6y ago
The downside of PCIe is PCIe is very complex. And the tools make interfacing with it bewildering. I really want a PCIe FPGA that looks to me like data magically appears on an AXI bus.
bfrog 6y ago
Replace pcie with AXI and that seems to be pretty close to what zynq/cycle v soc have today on the same package?

economusty 6y ago

Computronium

dhruvdh 6y ago

I can't help but think most commentators haven't actually read the article or the patent. This isn't about having an FPGA embedded into the CPU or near the CPU, it's about having a programmable FPGA like execution unit that can be programmed to be say a 4-bit floating point adder, or any other weird execution unit one might need. Why is this important? Have a program that does a lot of integer multiplications? Let's program all of these programmable execution units to multiply integers on the fly, etc. Now your integer multiply throughput is higher, as per the current program's needs. Have lots of weird old x86 instructions you are forced to support but no one actually uses? Don't waste transistors on them just program an execution unit to execute that instruction on the fly, etc. I think it's great, and that most people are missing the point.

mhh__ 6y ago
> Don't waste transistors on them just program an execution unit to execute that instruction on the fly, etc. Possible, but the "x86" part is already a big decoder in front of a murky processor underneath so this is already what the CPU does - if you removed the reference to an FPGA, rewriting old x86 instructions in terms of "new" ones is microcode.
ajross 6y ago
> Have lots of weird old x86 instructions you are forced to support but no one actually uses? Don't waste transistors on them That's been the role of microcode for like three decades now. Why does it matter if the instruction no one uses is implemented with FPGA gates or uops? No one uses them.
- webmobdev 6y ago
  Theoretically, Now you can create "micro-codes" in the CPU for your specific needs - e.g. scientists do a lot of calulation and would like a processor optimised for that. Now they can use the FPGA to do it. You want a CPU instruction that is optimised for something else - you can program the FPGA for that.
  - 6y ago

GuB-42 6y ago

Everyone seems to be talking about accelerated instructions but how about I/O? FPGAs are awesome at asynchronous I/O and low latency. We could implement network stacks, sound and video processing, etc... It can start a TLS handshake as soon as the electrical signal hits the ethernet port, while the CPU is not even aware of it happening. It can timestamp MIDI input down to the microsecond and replay with the same precision. It can process position data from a VR headset at the very last moment in the graphics pipeline. Maybe even do something like a software defined radio. Basically every simple but latency-critical operations. Of course, embedded/realtime systems are a prime target.

slimsag 6y ago
A fair amount of enterprise NICs in data centers do exactly this, e.g. Intel FPGA smart NICs I don't know enough to know how this being on the CPU would affect performance in this scenario, but I'd love to learn more!
AlotOfReading 6y ago
That's pretty much what Xilinx's Zynq product lines are already targeting, including embedded. They're comparatively nice boards to work on, as long as you can swallow the BOM cost.
andoriyu 6y ago
Network example is wasteful. There are already NICs that have FPGA and a whole set of linux's kernel features. You wouldn't want that to be that far away from the NIC itself. PTP works just like that - timestamps incoming and outgoing packets right after/before packet hit the wire. There is eXpress Data Path that can offload eBPF programs to NICs and deal with packets without them even coming into even kernel at all. High Frequency Traders do exactly that IIRC today. As for video processing codecs today are way too complex to be run there. Well, no one will stop you from running something like an integer DCT part on FPGA. VR thing... Generally, aside from Nvidia companies don't want to ship entire FPGA to end customers (guess why Nvidia G-Sync monitors used to be so expensive). Something like Snapdragon XR2 "solves" VR. Also, in order to render a picture you need to know headset position early, not at the last moment. How would you know what to render? How useful is the subject depends entirely on FPGA capability, and it's size. I bet it will be more useful for things like implementing some hash function there or something like that. IMO this will be a very niche product inside already niche market.

AlphaSite 6y ago

This seems more appropriate for GPUs than for CPUs where it’s high throughput and you can eat the latency cost of reconfiguring the node.

ajb 6y ago

How patents happen: An alarm goes out: our company has fewer patents than company X! In fact, we have the smallest patent hoard of our competitor group. If they sue us we might not have enough patents to sue them back! We must have more patents! Everyone who gets a patent gets a bonus! ( Exit CEO, trailing exclamation marks. All the engineers file their pet idea as a patent, hoping management will be interested in building it). (Some years later) Okay, some of those patents we filed are a bit silly. But at least we now have a huge, intimidating patent pile! No one will dare sue us now! Mua ha ha! But let's be a bit more careful what we give those patent bonuses for. (Meanwhile at company X: our company has fewer patents than company Y!...) The above is a true story, happened to me. Well, apart from the moustache twirling. My name is on some not very practical patents. So I'm not very convinced by stories which read the tea leaves from patents as to what a company intends ( Or economists trying to infer innovation rate from patent filing rate). Another problem is that the patent office is slow. Unless the company is General Fusion, most probably the product will be out before the patent.

skybrian 6y ago
I almost got my name on a patent that way for sharing an idea in an internal forum. I refused (well, I asked politely) and they took my name off it. (There was someone else in the conversation as well.)
- gaudat 6y ago
  Sounds like it's a bad idea to have our names on a patent from the way you said it. Can you enlighten us on that?
  - ericlewis 6y ago
    Anecdata: but, just because I threw in a couple of suggestions I didn’t feel like I deserved it. Also, don’t much care for patents personally.
  - skybrian 6y ago
    I don't like the idea of software patents, generally, and would feel weird arguing against them if I had my name on one.

whatever1 6y ago

How fast can an FPGA be reprogrammed? If I close my FPGA accelerated machine learning training algorithm, and then open a PC game, would it be feasible to load the new gaming-oriented instructions in ~10-30" that a PC game takes to open?

gh02t 6y ago
Programming a bitstream onto the FPGA is relatively quick, it's perfectly feasible. The time consuming part is in development and synthesis.
dewhelmed 6y ago
What sort of gaming-related workload do you think an FPGA would be suitable for? I don't know much about the gaming world, but isn't the majority of the computational workload graphics-rendering related, in which case, the GPU architecture is the best candidate to iterate on?
- whatever1 6y ago
  Not a game developer, but I believe that game mechanics, lighting and "AI" are all handled by the CPU.

galaxyLogic 6y ago

I think neural networks and AI might be a good application area for this.

signa11 6y ago

this approach is not new, and has been toyed around since the 1960 (!), see G. Estrin's work on adaptive architectures for example. i got to know about this as part of PRISM (processor reconfiguration through-instruction set metamorphosis) work in the early 90's. there is a very cool paper by the same name. check it out ! ps : PRISM Paper (http://class.ece.iastate.edu/tyagi/cpre583/documents/prism.pdf http://class.ece.iastate.edu/tyagi/cpre583/documents/prism.p...)

CoffeeDregs 6y ago

This looks a bit like the old (2000s) work of Leopard Logic or Tensilica. Exciting stuff. One important note (based on some comments here): generally, these in-CPU FPGAs have very fast reconfiguration. Not sure if it's 1, 10 or 100 cycles but it's not milliseconds. Actually, (in past examples) configuration might take milliseconds but it would load a number of planes of configurations: plane 0 might be MP3 audio device; plane 1 might be MPEG2 video device. Then reconfiguration is: switch to plane 1. This AMD proposal looks like it's much more tightly integrated into the CPU so it's got to be even faster. Combine that with the deep knowledge of processor internals you'll have to have to code for this thing and I'm having a hard time seeing you and me having much luck tinkering. This is probably 99.99% data center with gnarly NDAs and field support.

nynx 6y ago

This is exciting! Would be cool if it could access some sort of gpio as well!

deleted 6y ago

[deleted]

user5994461 6y ago

Yet another patent that should never have been granted. SoC have been a thing for a long time. SoC = CPU + FPGA on a single chip. Looking at the patent, the list of 20 claims is absurd. The title says it all "... PROGRAMMABLE INSTRUCTIONS IN COMPUTER SYSTEMS", they're trying to patent anything that can run or dispatch instructions.

cptskippy 6y ago
That's how the industry works. You gather and hoard as many frivolous patents as you can in a cold war arms race. If a new company threatens your business, you search your portfolio for a patent they violated and sue them. Companies who grow to a certain size look to be acquired by larger firms with bigger war chests. Sometimes companies recognize patents are stifling progress and engage in cross licensing or pooling of patents. Sometimes they do it to gang up on a new rival.
rcxdude 6y ago
No they're not. Claims 1, 8, and 15 are the only independent claims in the patent (if you're not infringing the independent claims you're not infringing any of the dependent claims: the tradeoff is the more general independent claims are generally easier to invalidate). All of them depend on having a dispatch unit which can be programmed to dispatch instructions into some logic which is configured by a bitfile (and also having the code and bitfile alongside each other and loaded by the same system). Most FPGA SoCs don't have a programmable instruction dispatch unit (which seems to me to be the core of the patent), and they generally do not have the software and bitfield side-by-side and loaded by the same loader, though that is probably an element which is quite vague and could be argued either way. I don't like patents in general (and especially in software), but this patent is not as general as you claim.
refulgentis 6y ago
>> the list of 20 claims is absurd. Claims are a union - each individual claim may sound simple, what matters is the combination. >> The title says it all "... PROGRAMMABLE INSTRUCTIONS IN COMPUTER SYSTEMS", they're trying to patent anything that can run or dispatch instructions. No. The title of a patent is not a patent.

BryanBeshore 6y ago

Lisa Su is a fantastic CEO. Time will tell what the impact of AMD’s acquisition of Xilinx will be (should it close), but this shows the strategy and execution behind Su and team. While a lot of acquisitions don’t pan out, this seems great.

parsimo2010 6y ago
AMD purchasing Xilinx is a reaction to Intel purchasing Altera five years ago. Dr. Su might be a good CEO for other reasons, but this isn't something that illustrates brilliant strategy on her part.
- cptskippy 6y ago
  The industry doesn't move overnight. AMD might have seen where Intel was going and didn't want to be caught off guard, or that might be the alternative to Apple approach of dozens of coprocessors on a chip.
- sitkack 6y ago
  This is AMD competing with Nvidia, not AMD competing with Intel.
- GeorgeTirebiter 6y ago
  Xilinx had laid off a good chunk right before their sale to AMD. Xilinx was having some financial troubles; when that happens, investors want out before a company craters. So selling themselves was one possible solution.
- rusticpenn 6y ago
  Intel did not produce anything worthwhile from that strategy yet and I have seen no plans either. I use Altera for all my FPGA needs.
  - ATsch 6y ago
    A large reason for the deal with Altera was that Altera already used intel for fabrication. I understand Intel's 10nm and 7nm failure has hurt them a lot in that regard, quite the opposite of the expected synergy. Unlike Xilinx for AMD, they didn't really have any other technologies intel needed either, the biggest advantage was fabrication and that fell through.

qwerty456127 6y ago

I could never stop wondering why is this not a norm yet. Why doesn't every computer have an FPGA.

imtringued 6y ago
Existing FPGA vendors made sure their products remained in a lucrative niche by maintaining full control over the development process for FPGA designs.
rcxdude 6y ago
Apart from the tooling woes others have mentioned (it's hard to get across how much FPGA tooling sucks compared to software tooling), FPGAs occupy a strange set of niches, but it's not clear how many are ones which would benefit the average PC or server. If you want raw memory bandwidth and FLOPs, a GPU is better (on speed, power, and price). If you want to evaluate complicated conditions and control flow, a CPU is better (in the same catagories). Because FPGAs are very power hungry and generally slower than the raw silicon, they only really give you more compute if what you want to compute is either far enough off the beaten path that some custom logic is much more efficient than the available instructions, and/or it benefits from a specific parallel datapath which doesn't easily fit on a GPU or CPU (GPUs being the best at embarrasingly parallel systems and modern CPUs being good at parallelising general purpose code reasonably well). In practice you see FPGAs mostly in two areas: specialised embedded applications which benefit from heavy custom I/O and/or some efficient specific DSP but don't have enough volume to justify an ASIC design, or in accelerators for simulating ASIC design.
stefan_ 6y ago
Because adding a layer of abstraction to silicon transistors makes for terrible performance and energy usage. Every other year or so someone "rediscovers" FPGA and thinks this niche architecture is poised for a total revolution of how computing works, think drag&drop hardware and super fast custom everything. It never happens and it will never happen because customization, much like premature optimization, is the root of all evil and also just.. see the first paragraph.
- 6y ago

leecb 6y ago

Everything described in the article sounds exactly like some of the Virtex*-FX products from more than 10 years ago. For instance, the Virtex4-FX had either one or two 450MHz PowerPC coresembedded in it, where you could implement 8 of your own additional instructions in the FPGA. This is effectively now a CPU where you can extend the instruction set, and design your own instructions specific to your application. For example, you might make special instructions using the onboard logic to accelerate video compression, or math operations; I know of one application that was designed to do a 4x4 matrix multiply per cycle. https://www.digikey.com/catalog/en/partgroup/virtex-4-fx-series/76285 https://www.digikey.com/catalog/en/partgroup/virtex-4-fx-ser... https://www.xilinx.com/support/documentation/data_sheets/ds112.pdf https://www.xilinx.com/support/documentation/data_sheets/ds1...

thrtythreeforty 6y ago
For those curious, Xtensa is a similar embeddable architecture (known especially for its use in the ESP32 microcontroller) that allows broad latitude to the designer to customize its instruction set with custom acceleration. The integration is very good, the compiler recognizes the new intrinsics and the designer has control over how the instruction is pipelined into the main processor. Unfortunately it's very proprietary, and as far as I know there isn't an at-home version you can play with on FPGAs. But this kind of thing does exist if you can afford it - you don't have to roll your own RTL.
jng 6y ago
I am very familiar with the new Zynq family, embedding ARM cores on the same die together with FPGA fabric. I didn't know that the PowerPC version allowed such a tight coupling as handing off an instruction to programmable logic, the current Zynq models are much more lightly coupled, using AXI buses to connect the ARM cores with the PL (and many other components on the same SoC).
mhh__ 6y ago
What was the latency like to actually get data into your shiny new instruction e.g. do I get a 14 stage pipeline stall to actually use the instruction?

rwmj 6y ago

About *!$% time! I was hoping Intel would do something like this when they acquired Altera a few years back. Does anyone know why Intel acquired Altera?

d_tr 6y ago
AFAIK there exist some Xeon + FPGA chips. No clue about availability though...
- harry8 6y ago
  Are they connected by the pcie bus though? https://www.xes-inc.com/ https://www.xes-inc.com/
PedroBatista 6y ago
Almost the same reason someone buys a Peloton bike or rusted old Porsche. Because someone had a dream last night and have the money.
- sbrorson 6y ago
  chuckle This is true. As far as I can see (as a hardware engineer frequently doing FPGA stuff) The Intel/Altera combo has not produced any new products nor yielded any customer benefit beyond what would have happened if the two companies had remained independent. But I'll bet the "business strategists" at each company who thought this one up made a pile of money from the deal.

mhh__ 6y ago

Xilinx already have ARM cores in their FPGAs so I wonder which way they'll go - I'd honestly prefer a neoverse core than an X86

efferifick 6y ago
Not sure how realistic it would be, but I would like to see a RISC-V base core, and the FPGA implementing the extensions. Why? Because it would be cool! Also, I don't really see a use case except for debugging compilers supporting multiple RISC-V extensions and what not.
- craigjb 6y ago
  Microchip has the product for you then! Well, the RiscV part anyway. https://www.microsemi.com/product-directory/soc-fpgas/5498-polarfire-soc-fpga https://www.microsemi.com/product-directory/soc-fpgas/5498-p...
sbrorson 6y ago
You are right the ARM cores, mostly. Xilinx Zynq devices have ARM A devices built into them as "hard" cores. That is, the ARMs are instantiated directly in silicon, not as "soft" cores which take LUTs (gates) from the FPGA fabric. The ARM A is a microprocessor (not a microcontroller) powerful enough to run Linux. The ARM connects to the FPGA fabric using a so-called AXI bus, which is a local bus defined by ARM. Xilinx supplies a bunch of "soft" cores which you can instantiate in the FPGA and integrate with the ARM. Of course, you can write your own logic for the FPGA too, as long as you can figure out how to interface to it using one of the AXI bus variants. Several vendors offer experimenters platforms which are affordable enough for hobbyists and folks making engineering prototypes. Examples are the Avnet's Zed board and Digilent's Zybo board. The biggest problem with the Zynq ecosystem is that the Xilinx tools -- Vivado/SDK and whatever they renamed it to last year -- are steaming piles of smelly brown stoff. Vivado is buggy, poorly supported, has bad documentation, and the supplied examples typically don't work in the latest version of Vivado since they were written long ago and have been made obsolete via version skew. An absolute disgrace compared to what software engineers are used to. The SDK is basically Eclipse which has its own problems, but is not as bad as Vivado. Ask me how I know. I think AMD and Xilinx have a long way to go before they can satisfy the hype and speculation I see in all the posts here. I suppose one could shell out $20K for a seat of Synopsys if one wanted a decent set of dev tools, but that's not the direction most software engineers are going nowadays. Also, assuming NVidia completes its acquisition of ARM, the whole Zynq ecosystem is imperiled since it pits ARM against NVidia.

ineedasername 6y ago

Sounds like spending a few hours a month learning an HDL could be a good long-term career decision.

efferifick 6y ago
While sibling comments mention that it is probably wiser to learn digital logic before HDL (and I agree with them), I think it is important to also consider that there is now High Level Syntehesis where programming languages similar to C (e.g., OpenCL) can compile to VHDL. HLS may lower the barrier for programmers to take advantage of FPGAs. However, whether the design can compile to fit the constraints of the FPGA available is another question that I do not know the answer.
deelowe 6y ago
Anyone who is considering this, make sure you learn digital circuits first.
seabird 6y ago
You're going to need to commit a lot more time than that. HDLs and the surrounding concepts have key fundamental differences from software that a lot of developers have a hard time stomaching. That's why high-level synthesis is the FPGA industry's City of El Dorado; software developers would be able to create acceleration designs without having to build up a fairly large new skillset.
- imtringued 6y ago
  I've never understood this argument. The change in mindset is extremely small. It's merely a matter of awareness. High level synthesis can work just fine if you don't go overboard with constructs that are hard to synthesize. There is no fundamental reason why a math equation in C should be harder to synthesize than the Verilog or VHDL equivalent.
  - mhh__ 6y ago
    > math equation in C I think it's the bits around the outside of the (say) math kernel which will trip up an "ah it's just like C!"-thinking programmer.

ohazi 6y ago

For decades, the FPGA vendors have had this fever dream of "an FPGA in every PC" -- either as an add-on card, or as part of the chipset on a motherboard -- that would enable a compiler or operating system to seamlessly accelerate arbitrary tasks on demand. In my opinion, the problem has always been their software: the FPGA vendor tools are slow, bloated monstrosities. The core of these tools are written by the big three EDA vendors (Cadence, Synopsys, and Mentor Graphics) rather than the FPGA vendors themselves. The licenses include ridiculous, paranoid restrictions [1] and force the FPGA vendors to keep their bitstream formats and timing databases secret [2] in order to prevent competition from other tool vendors. Most FPGA vendors didn't see this as a problem, but even the ones that did didn't have much of a choice, because the tool market is a cartel. Thankfully, we now have an open source toolchain [3] with support for a growing number of FPGA architectures [4], and using it vs. the vendor tools is like using gcc or llvm vs. a '90s era, non-compliant C++ compiler. It even has a real IR that isn't Verilog, which has made it easier to design new HDLs [5]. I don't see how a dynamic FPGA accelerator platform can be even remotely viable without this. It's the difference between a developer getting to choose between one of a few dozen pre-baked designs that lock up the entire FPGA (and needing to learn how to shovel data into it), vs. a compiler flag that can give you the option of unrolling any loop directly into any inactive region of FPGA fabric. It would be quite the cherry on top to see AMD build something interesting in this space. But unless they're willing to fully unencumber at least this one design, I think the effort is likely to fail. The open source guys are chomping at the bit to make this work, and have been making real progress lately. Meanwhile, the EDA vendors have been making promises, failing, and throwing tantrums for the last 20 years. It's time to write them off. [1] https://twitter.com/OlofKindgren/status/1052822081652617221?s=20 https://twitter.com/OlofKindgren/status/1052822081652617221?... [2] Imagine trying to write an assembler without being allowed to see the manual that tells you how instructions are encoded. It's like that, but the state-space is hundreds to thousands of bytes in multiple configurations rather than a few dozen bits. [3] https://github.com/YosysHQ/yosys https://github.com/YosysHQ/yosys [4] https://symbiflow.github.io/ https://symbiflow.github.io/ [5] https://github.com/m-labs/nmigen https://github.com/m-labs/nmigen

travis729 6y ago
I would love to hack on FPGAs but always run into the issue of closed toolchains. The recent open source work is a breath of fresh air, but we need to see an FPGA vender that embraces and sponsors this work.

d_tr 6y ago

The main reason I am interested in this acquisition is a (faint) hope that they open some specs up to help projects like SymbiFlow.

Scene_Cast2 6y ago

A killer tech for this would be a framework that automatically reprograms the FPGA and offloads the work if it makes sense. For example - running k-means? Have your FPGA automatically (with minimal dev effort) flash to be a Nearest Neighbor accelerator. The problem is finding a way to make that translation happen with minimal dev effort, as software is written rather differently from hardware.

d_tr 6y ago
You might want to check the "Warp Processing" project out: http://www.cs.ucr.edu/~vahid/warp/ http://www.cs.ucr.edu/~vahid/warp/. It is probably exactly what you are thinking about. Transparent analysis of the instruction stream at runtime and synthesis and offloading of hot spots to the FPGA.
- Scene_Cast2 6y ago
  Huh, interesting. It seems that the work doesn't have to be explicitly parallel for this to work, which is a surprise.
  - rowanG077 6y ago
    Why is that surprising. A LOT of statements that are done in programming can be executed in parallel. It's just not worth it to actually make threads for them since the overhead of threads is larger then just executing the set of instructions sequentially. In fact all modern processors take advantage of the data dependencies and execute it in parallel if possible.
cashsterling 6y ago
I recommend checking out CacheQ: https://cacheq.com/ https://cacheq.com/ they are working on almost exactly this. If I was an investor, or Intel or AMD, I would buy them and/or invest heavily.
- therealcamino 6y ago