I would quite like an FPGA on board my CPU. Intel have what used to be called Altera, but they don't seem to have done much publicly with it in relation to their CPU business.
The current model for interacting with an FPGA connected to a PC has it sitting on a peripheral card, on the other side of a PCIe bus. AFAIK there's no story for exposing higher level abstractions of these devices though the OS in a way that would allow them to be shared between different applications.
How would you envision an "FPGA on board the CPU" differing from this? Would it still be a separate thing the way GPU is today, or would you see it more as like a new set of CPU instructions which enable little blobs of HDL to be somehow passed in and invoked, kind of like how a shader works today on GPUs?
There's the possibility of a Xilinx Zynq with AMD x86 cores instead of the ARM cores in current Zynq versions, though I'm not sure that would really be interesting to anyone.
Beyond that, there's been research in the past that envisions using a FPGA fabric as an execution unit within the CPU itself: https://www.microsoft.com/en-us/research/project/emips/ Intel hasn't pursued such a thing but that doesn't mean AMD couldn't.
I'm not so sure that's something which is really feasible from a design point of view. Everything involving instructions in the CPU is extremely performance critical and cross-cutting, so designing an interface which allows custom instructions without utterly destroying performance seems like quite a feat. I've a feeling the memory interface is a much more natural place for any integration (this is how it works on any existing FPGA + CPU chips)
I think the idea of configurable hdl modules could be very interesting. A game could load a physics core. Ssh could load a security core and so on. These could be updated similar to firmware or even could ship with the application. The only barrier right now is the long programming times.
Well and the whole story with multi-tasking is pretty interesting. Does one application get exclusive use, with the thing able to somehow cache its state on a context switch?
Are many of those devices actually reprogramming the FPGA at runtime from the OS running on the soft processor, though?
My impression was that you tended to define pretty static blocks of functionality (you know, hash calculators for your bitcoin mining or whatever), and then just communicate to those from the OS using interrupts and a shared memory interface like any other peripheral.
What I want is a small FPGA that is really close to each CPU core. I want to be able to send a query to it with about the same minimum latency as an L1 hit.
Basically, I want it to implement what are essentially custom CPU instructions.
Rather than implementing your full algorithm on a big FPGA over a PCIe link, you should be able to implement just the few custom specialized instructions that regular CPU is missing, while still utilizing the regular CPU resources.
How would OSs manage this security and process wise? I imagine its impossible to program an fpga fast enough to have it switch config for each process that wants it.
Why re-program?
Extend the X86 ISA with a set of instructions for mailbox style programming (put, trigger, wait for flag/interrupt, get), then address the FPGA as a set of registers and flags.
Hide the registers or set a flag if the FPGA is not configured for it.
Moreover, put another configuration flag to FPGA part so that it either shows up a device or works as a set of registers.
It's easier said than done but, it's not impossible.
How would accessing the FPGA through registers instead of instruction opcodes do anything to address the issue of needing to ensure that the FPGA is currently configured to behave in the manner expected by the current process, as opposed to the FPGA still being configured to suit the process that was running before the last context switch?
The fundamental way that an FPGA works (more or less) is to program the configuration registers with values that then determine the routing. One thing you could do is have multiple sets of these configuration registers, at process start you allocate one configuration to that process and set it up, from that point onwards you when you despatch instructions to the functional unit you do it along with the process configuration. So one process could be using the FPGA as a custom hashing function and another could be using it for some funky video IP. I'm not saying it's a guaranteed win but I think there are technical solutions that you could experiment with.
Sounds workable, though you'd also need a way to save and restore any internal state, or else some way to mark off checkpoints where it is interruptible.
The other thing to note is that this only covers using the FPGA for compute. While that's the obvious use-case for an "FPGA in CPU" concept, in the real world, IO is a pretty important part of many non-cryptocurrency FPGA applications, whether you're just counting edges on some input like an encoder, providing a highly time-sensitive output signal, such as for an SDR, or implementing some custom serial protocol.
I'm not fit to judge, but the 6138P with integrated Alter 10GX appears to connect to the main Xeon cores via a UPI2 link and dual PCIe x8 links. It exports an HSSI bus, whatever that is[1].
The thing is, I don't think AMD is going to have much of an advantage. Back when AMD64 was becoming a thing, a long time ago, there was a lot of excitement around HyperTransport (HTX), around an inter-processor bus that people could make interesting accelerators out of & connect fpgas with. It never... really went anywhere. It's still supposedly quite prevalent as the basis for AMD's modern Infinity Fabric, but AMD seems to have no interest, no energy to make Infinity Fabric or HyperTransport interesting to the world, anything beyond an implementation detail.
If AMD does want to start integrating FPGAs, they either need to go back 17 years & start pushing Infinity Fabric / HyperTransport, or they need some other plan to make the fpga useful. Perhaps CXL or CCIX or GenZ or just like they do now gobs of pcie is enough, is how an fpga can mesh with core complexes & peripherals, but wow AMD would be in a much better place to start integrating FPGAs if HTX has kept up steam.
From what I remember, the problem is that there is a fairly large amount of work to get useful performance out of a hybrid like that. It's easier to just, say, learn CUDA and use a GPU than it is to have HDL folks work with SW. I have no doubt a system like that would be useful, but it would probably be expensive and limited to specialized, low-volume applications(like big FPGAs are now).
I'm unsure if this type of merger is good for consumers. Will AMD and Xilinx make better products together, or does competition drive them more efficiently. I tend to believe the latter.
Probably comes down to whether you believe they compete with eachother. If they do compete, net loss in competition may be bad. If they don't, then two smaller companies gained scale & integration opportunities.
They don't seem to have a lot of overlap - AMD is mainly in the CPU business and Xilinx seems to be mainly focused on the FPGA space (JP Morgan used their hardware for Monte Carlo simulations[0]). This seems like a good fit.
They compete head to head in machine learning applications. Xilinx's latest Versal device added AI engines to accelerate ML further. In a situation where AMD owns Xilinx, I would think they execs would decide not to add those types of features to FPGAs to not compete against their own product.
Edit: Actually I'm thinking of Nvidia, with their ML supported by TensorFlow. AMD is lacking here.
Has Altera done that well for Intel's bottom line? I haven't been watching that closely.
I would love an RFSOC type peripheral though. Sort of a Spectrum Processing Unit or SPU. If you extrapolate the cu:Signal work to its logical extreme of a purpose built auxiliary processing unit the possibilities are pretty amazing.
>Has Altera done that well for Intel's bottom line? I haven't been watching that closely.
Altera is doing about the same before Intel's acquisition. Or may be losing to Xilinx a little ( within margin of error )
But one thing for certain is that it hasn't grow. ( At least on paper )
So it depends how you define well. Considering the performance of Intel's past acquisition ( Look at Infineon ) and the total failure of Intel Custom Foundry I think it is doing quite well.
Going back to 2006, Xilinx was making FPGAs that would sit in an Opteron socket and speak HyperTransport to the other CPU(s).
I never heard much more about that, but I can imagine it might've been popular with certain specialized workloads, in an era before GPU compute took off, or perhaps workloads that don't fit GPUs well.
I wonder if those specialized applications might be a small but important market.
Governments were the consumers of that Opteron/FPGA hybrid product. It was an interesting idea but way too difficult to use for anything that would justify the cost. In practice, the FPGAs seemed to mostly be used to run crypto algorithms and codecs, which seems kind of disappointing. I vaguely recall some attempts at building ticker plants with them but I don’t know that it was ever actually used for that.
5 years ago amd was a $2 stock and xilinx was a 50 dollar stock. Now amd is a 80 dollar stock and Xilinxis ~100 dollar stock. Xilinx market cap was 5x of amd. Even today xilinx generates more free cash than amd. Its kind of crazy how fast company values can change.
It's also weird because shareholders want stocks to grow indefinitely at an exponential rate, whereas there are a whole lot of companies like Xilinx that don't really need to grow all that much beyond just scaling to a number of gates that is useful to today's industry. Or Dropbox, which I really don't want them doing anything innovative except syncing my directories between machines until the end of time.
You gotta have a low P/E to pay dividends. It's the only sensible long term strategy. It gets ruined when people drive up stock prices playing the greater fool strategy.
Really hoping the ARM acquisition can transform Nvidia from the inside, make them a responsible & cooperative partner.
AMD seems to be doing well.
Intel is indeed faltering, yes. Especially with process technology. Given what they've got to work with in the process department, they've been building neat good stuff. Xe just launched & in a mobile form factor is quite competitive, no longer leaving AMD APUs to dominate. These same mobile parts have far higher integration than anything AMD can offer, with dual USB4/TB4 ports good for 2 x 40Gbps. Intel has a range of neat things few others have. Intel has a pretty competent wifi that integrates nicely. Their new Tremot Atom cores are a great value, really nice light-weight cores, & scale up to 24 cores on expensive but interesting cellular radio platforms. Xeon-D is a wonderful connectivity platform that there is not much competition for. Alas Intel cancelled OmniPath, which was a brilliant thing to integrate & give away on server CPUs almost for free (~$100 on a >> $1000 chip). And alas the process tech really hampers big server cores, but intel has been getting more competitive.
At this point, Linux need competition. Nvidia thus-far has never played well, Linux4Tegra and CUDA are walled gardens & driver support is otherwise awful, still no good way to run Wayland. AMD is doing great & Linux support is very high. But we kind of need Intel to keep AMD from growing lethargic & un-competitive, from exploiting their new market position as, well, better.
Feels like a datacenter play for specialized compute. Given AMDs domination of server workloads in $/performance, seems like doubling down on that advantage. FPGA is already used today to offload SSL termination from the CPU.
Yeah it feels like a move to try and keep up with Nvidia. With Xilinx, they might be able to offer a networking offload product similar to Mellanox. They can also focus on ML acceleration that is custom tailored to the task instead of trying to push GPUs.
AMD really needs to focus on software if they want to catch Nvidia though.
"ML acceleration that is custom tailored to the task"
Hope for this, the Nvidia monopoly is hurting ML, I wished to have something else but am forced to buy Nvidias offerings b/c hardware and tool support.
Intel does not seem to have capitalized on the Altera acquisition but maybe that is also related to Intel's fab issues.
From an operation perspective, this combines two non-overlapping TSMC customers that can potentially negotiate better wafer prices together. I assume that AMD has significantly higher wafer counts than Xilinx so this would primarily benefit the Xilinx business.
From a technology perspective, this acquisition may succeed where the Intel/Altera acquisition fizzled due to AMD's chiplet approach. Swapping a processor core for an FPGA chiplet might be an "easy" win in some markets.
> From a technology perspective, this acquisition may succeed where the Intel/Altera acquisition fizzled due to AMD's chiplet approach.
Intel has been using EIMB quite effectively to allow for very interesting fpga configurability, letting purchasers pick from a variety of "front end" transcievers to match their app[1]. This doesn't combine multiple big processors, but is still a very interesting tech!
Intel's also been working to standardize & accelerate mulit-chip connectivity, by donating their Advanced Interface Bus to the open group the CHIPS Alliance[2]. This saw a 2.0 draft emerge this summer.
Agreed that Intel has been fairly ineffective at driving interesting new fpga adoption. There has been interesting work but it's hard to see what adoption has looked like. There is the Xeon 6138P for example, which uses a UPI link and dual 8x PCIe links of a 20 core xeon chip to talk to an on-package Arria 10GX[3]. I'm not a market researcher, but my guess is that adoption hasn't been stellar. I haven't seen any follow ups. I do hope there have been some interesting & good uses though! I feel like AMD will face similar challenges to adoption. Frankly, tech like Xe and Radeon seems more appealing to the world we live in; big gpus that can do bfloat16 &c. One of the big advantages of fpgas has been great connectivity, powerful transcievers & other i/o capabilities, which, if you put them in an existing platform socket, is probably going to squander some of those capabilities, I feel like?
Wasn't there another angle with the Intel/Altera tie-up - to more closely integrate the x86 architecture with top-end FPGA tech, and to relegate ARM to embedded SOC (not kill it, but equally not pour R&D budget into it) ?
How many f8, f16, f32, f64 units you want now? Do you need some special instructions like add+multiply, or some bit permutation? You can add some.
There's no need to reconfigure it very fast, or per VM; not having to reboot the hypervisor OS would be enough. But it e.g. would allow to change the type of instances a particular server can offer, adjust to demand, and so overprovision less.
I think this is a terrible idea for the future of technology. AMD would not be existentially dependent on the FPGA market and the stack is so important to cutting-edge tech that it demands focused stewardship. It's clear something needs to change in FPGA land. Xilinx and Intel both produce abhorrent FPGA software causing project delays and cancellations of cutting-edge technology dependent on their devices. Xilinx probably needs an activist investor to force their software to move past the time in history when Java was something you put on your resume. Maybe AMD can be that, but I doubt it and an acquisition by AMD would likely result in the same abandonment we see from Intel towards Altera.
Xilinx had an opportunity to be in the position NVidia is in today and it was not obvious in 2005 who was going to win the high performance computing (HPC) market because the inherent advantages that FPGAs had and still have today for high speed I/O, RAM throughput, and hard timing requirements. NVidia's CUDA, on the other hand, produces generally painlessly portable results, with easy improvement on new devices. They have essentially won in HPC application development.
Fundamentally the FPGA companies need to adopt an open-source, cloud-first ethos towards their stacks and especially be focused on making agile low-level application development. Making a counter control some LEDs should be a 10 second process. Changing the clock speed should be a 1 seconds process. Adding a button to reset the counter should be a 1 second process. None of this is true. Good luck getting this to work within one day as a newbie on a vanilla machine. Good luck even installing Vivado and compiling any bitstream in one day (thank God they have AWS images -- good luck getting that going within 2 hours). Good luck coordinating with source control and generally merging work with a team.
There was some hope when Intel bought Altera that the compilers engineering expertise might help improve virtual CPU stacks, or at least some investment in the usability of their software tools might have been thought of as a competitive advantage, but all the FPGA vendors have seriously dropped the ball on improving the eco-system with usable software. FPGA software is so bad that you have to justify a 6 month development cycle for something that should probably take a few days if things were even remotely sane. It's hard to enumerate all the examples of broken-ness but small changes end up taking a long time to re-build, things like inverting your reset in a module and then waiting two hours for trivial changes to resynthesize and place-and-route. (edit, two hours later the trivial reset polarity inversion failed timing, because it also required me to add synchronization stages to send the inverted reset signal across clock domains, shouldn't be doing this at night).
When Jim Anderson left AMD to take on CEO at Lattice I invested heavily in them with the thesis that there would be an eventually merger. Unsure what to do now
> Xilinx and Intel both produce abhorrent FPGA software causing project delays and cancellations of cutting-edge technology dependent on their devices.
I feel this pain!!!!
Absolutely love the flexibility of Xilinx's System-On-Module architectures but their Software toolchain is arguably the most time-wasting frustrating piece of software I have ever had to work with.
We need an open-source LLVM-like toolchain equivalent for FPGA's. I hope AMD has enough muscle to push for this.
I would also like to point out that there are projects out there pushing this boundary, David Shah has made amazing contributions towards this, with projects like SymbiFlow and yosys.
Being involved with FPGAs for 20+ years now, and Xilinx for the most part of it, I have witnessed the progressive decay of their software quality. The legacy Xilinx tools (Foundation) were far from perfect but at least useable -- and hackable to a degree if you needed to implement workarounds. Those were many times even suggested by Xilinx own employees that were easy to approach and responsive back in the days.
Altera Quartus was always better in terms of project organization and user interface, including their hardware tools. Third party software such as Synplify (before Synopsys bought their maker Synplicity) were light-years ahead, especially on the synthesis introspection and support for design and RTL troubleshooting.
People tend to justify the software quality and vendor lock-in because these are niche markets. I think that is a lame statement. You could tell both Xilinx and Altera, being "fabless hardware companies", treated their software departments as a necessary burden and not a critical part of their business model, which by de facto it was. The software started going downhill, progressively accumulating technical debt while it kept getting even more cryptic and expensive. I think they offshored a significant part of its maintenance in the last decade. Each release fixed bugs but astonishingly introduced very stupid new ones that a minimally decent software verification process should have caught.
Vivado is a mess. You can optimize your workflow digging down deeply with TCL scripts (yikes, its 2020!). However who has the time for learning their badly designed API and fighting with the quirkiness of their tools? I am amazed some of us use it in regulated environments where our tools need to be properly validated. I have had designs that take more than one day to synthesize, map and route. Having being bitten by some bugs and my own errors dealing with the cumbersome IDE, I always painfully go through all the logs of each step, and also many times recreate the project and rebuild just to check if the output is reproducible.
Tcl is the de facto scripting standard for EDA (it's in thr name!), it's a quirky language, but what Xilinx has done is allow portability and compatability between it and major HW design tools. The low levels commands themselves are similar to ones ASIC designers would use, e.g. report_timing is the same as you would see in countless other EDA tools. Perhaps supporting python and TCL for scripting would be good, but not supprting TCL would have been a big mistake
I recently encountered a bug in the Vivado IP integrator packaging whatever crap where if you left the "Vendor name" field at its default value '(none)', the packaging aborted with an error because that field contained invalid characters: the parentheses. That's a bug that any kind of testing should have caught (two bugs, actually).
Also: Why does Vivado have to treat any little IP core I create like it's some full-fledged library that exists independently of my main project? I just want to attach a 50-line HDL module to an AXI interconnect in the block diagram – I don't want to create a new project for this, ffs.
Vivado is amazing. TCL is chosen because its portable across almost All EDA tools, so by using it, Xilinx are ensuring your existing HW design skills apply to FPGA tools also, instead of the proprietary interfaces ISE used. So while TCL is not a language I like, it is the HW standard so it must be in any serious EDA tool. I use many EDA tools daily (design compiler, primetime, icc2, vcs, xcelium, verdi, redhawk, and vivado) all have TCL, so some scripts are portable between tools, which is I assume why Xilinx chose to also have some command compatability with the Synopsys commands. So doing this makes HW design skills portable, which I really appreciate. This was also why they moved to XDC constraints from the UCF, embraching existing standards to help engineers.
I'm not sure about amazing (there's certainly worse FPGA tools though), but I think you're right on TCL. It's still a perfectly servicable language to do the job and it's ubiquitous in the industry so you'd need a pretty strong reason to break from it. The terribleness of the tooling comes from other sources (mainly its sheer opaqueness, followed by bugginess, followed and excacerbated by its slowness, though the last point may be hard to get around: place-and-route is not like compiler optimisation, compiler optimisation is almost entirely local decisions, wheras place and route is essentially a global optimisation problem).
I guess my perspective comes from the other side, ASIC tools that do the same thing (synthesis, place and route, STA, simulation) are way, way worse. Design compiler was designed in the 90s, and while it has many advanced features, it's usability is incredibly poor. A million variables you never heard of, and each one tweaks its behaviour in weird and wonderful ways, and a GUI that still looks like its from the 90s. Costs 90k a seat to boot, but if you're doing ASIC design, it's one of the major tools you will use. And it just does the synthesis bit. Vivado does it all, and has seamless cross probing between each stage, right back to source code. It's usability to me is refreshing. I have found bugs, sure, but never a show stopper. It's free Verilog simulator (xsim) is better than any other free system Verilog simulator out there, and that's just one sub component of Vivado.
oh yeah, by all accounts ASIC design tools are even worse. But from a software perspective FPGA tooling is still in the dark ages from most perspectives (and the frustrating thing is a lot of it wouldn't be very hard to do better).
This could work if AMD invested a ton in software like Intel has with OneAPI.
But, if AMD really wants to get into a new market, it could try going into mobile. The 4000-series CPUs are great laptops CPUs which could go further down the scale, and over a couple generations maybe in phones too. Unlikely or stupid idea (RIP Broxton)? Still worth a shot, I feel.
At least Xilinx will be able to fall back to AMD’s amd64 or x86 architecture if NVIDIA will limit ARM core licensing. The new SoC products like ZynQ Ultrascale+ with ARM cores are really great.
It is really useful to include ARM cores in a FPGA, but Xilinx has remain stuck with completely obsolete cores (Cortex-A53 and Cortex-A72) since forever.
The modern ARM cores, starting with Cortex-A55 (2017), use the corrected ISA ARMv8.2-A.
On the ancient cores used by Xilinx, when writing multithreaded applications, it is annoying to lack atomic instructions.
Yes, sure atomic instructions can be simulated with only the base ARMv8.0-A ISA, but it is not possible to guarantee worst case timings for the simulated atomics (because of retries).
From my perspective an ancient ARM core is better than 100 MHz Microblaze softcore. ARM core opens lots of new possibilities and I don’t need quirky high level synthesis.
The best outcome for me would be more open FPGA tools, maybe even documented bitstream format
This could just be a strategic acquisition for internal purposes: I bet a lot of design and architecture validation is done on big FPGAs. Maybe they wanted some custom ones?
Yep, emulation is huge. HAPS by Synoosys for example has a bunch of huge Xilinx FPGAs in there. I've never used one, but apparently it takes care of splitting the huge ASIC design over the array of FPGAs so it looks like a single chip, and can run at 100s of MHz, so way better than simulation that could be a few kHz at best
I have been looking forward to this happening for a long time. A quick search on my past comment shows that was 2016. And I remember checking Xilinx market cap last year and it was ~$30+ B, while AMD was only ~$50 B. I was thinking the chance of that ever happening is going to be very slim. ( I was an AMD Shareholder, but I never thought it would be $100B mark cap company, sold it all last year) Now AMD is at $100B+, while Xilinx is at Sub $30B. The market is crazy.
But things has changed since 2016 - 2018. I used to see the move to FPGA as going offensive attack in the server space, now both AMD, and Intel are doing what ever they can to fence off ARM.
I sold a few shares when they were at 20 or some dollars a share thinking AMD would stay second fiddle to Intel for the rest of time. Turns out I am a terrible value investor.
I thought about buying them at under $2 a few years ago but didnt... I probably would have cashed out half my share at $8 or $15 thinking the catchup to Intel was temporary. I'm glad they are doing well. There is no perfect crystal ball.
It's quite an interesting world where AMD has one of the 8 cores on a chip-let be a Xilinx FPGA. The only issue is they are not easy enough to program but maybe AMD can get out ahead of Nvidia on this one and define the software stack here in the way Nvidia did with CUDA.
VHDL / Verilog is very different, but not necessarily harder per-se. It's just people spend 4 years learning "normal" programming, and at best have a one-semester course which uses VHDL.
As an FPGA dev, I tend to think of HDLs akin to HTML than “code”. It’s just a DSL to describe a graph. Actually pretty similar to how tensorflow is designed.
The issue I see is they are slow to compile. I write them daily and it's not that hard to lean when you grok the parallel nature, but generating the HW usually takes at least 10 to 30 mins for a medium sized block, that is a bit of a barrier to entry.
I'm really very bearish on this idea. When Intel bought Altera there were really 3 issues. The first was that they drove growth by bundling their FPGA stuff with their fabrication services - so like someone like Ericson could do half their design on FPGA and then slowly move to ASIC. That was good for Intel because it won them business, but it didn't really do anything for FPGAs.
The second thing was bundling FPGAs into the same package as a CPU. There were two problems with this, firstly it's a load of dark silicon when you aren't using the FPGA part and you have to make a load of tricky decisions like "Am I going to design my thermals to let me run all the Xeon cores at max speed whilst running my FPGA". The other problem being that it's really bloody hard figuring out the programming model, where the FPGA wants a deterministic data flow and you've got these CPU nutters throwing memory at you out of order, stalling and screwing you up with really bizarre cache behaviour. Since the CPU guys designed the interface it leaves the FPGA developer an almost impossible task to build efficient processing pipelines.
Finally we've got the moonshot - the idea that you could come up with a high level design language to programme FPGAs like software. Intel very heavily invested in this when they bought Altera but I'm still not seeing any forward progress on this, and let's be clear, Intel poured huge resources into making that happen. The last I heard they had over 100 engineers on that project and the sum total of their achievement is a handful of "partners" who wrote OpenCL/HLS/whatever and then worked with the engineers to go through a grueling process re-writing their code over and over and over until it looked like the RTL they already wanted. At one point Intel were going to re-write their entire FPGA video IP suite in HLS, I don't know how they went, but the acquisition of Omnitek probably wasn'ta good sign. It's been 4 years since the acquisition, and they were working on it long before then. The project is still basically just a load of marketing guff on their website that no one can actually use. I would say with the innevitable restructuring that Intel will have to do due to their various other fuck ups, this project is on thin ice.
The problem is that AMD is so likely to fall into the trap of points 2 and 3, and we're going to lose the final big independent FPGA company so that AMD can kill themselves trying to compete with Nvidia. And the real danger is that whilst all that's happening, actual innovation will disappear in the FPGA space. Xilinx's ACAPs are actually interesting (one way of solving the programming model), but Intel's last piece of innovation in the FPGA space died with the failure of hyperflex.
This a very interesting take on the subject and I share the sentiment of your last paragraph, it's a pity if it comes to that.
FPGAs are such a useful tool for a variety of engineering (and product) problems that fall in-between general computing and ASICs, unfortunately these problems are usually so disparate in nature that you can't target them as a single market. So the datacenter / HLS game will keep going until either a viable solution for the programming model is found or until everyone gives up on it once and for all and decides that FPGAs should go back to their niche (which is fine by me)
What do you think of the Xilinx HLS tool, I've only played with examples, but the c code being input looks like regular C, and can generate hardware (though you need pragmas to guide it for max efficiency)
As a value multiplying investment AMD should buy a company that has programmers that can code a half-decent CUDA compatible layer for its graphics cards.
Cuda will suddenly change and then the AMD implementation will look old.
AMD is in a position to take over via LLVM open source extensions instead of CUDA.
If they can provide an alternative towards the same goal they dont necessarily have to copy the API just make their own reliable API. I just wonder if the concept of CUDA is patented in regards to GPUs.
Thanks! I was hoping somebody would steer me in the right direction if they had something. I wonder when AMD will focus on making things that are developer focused, I know for example that Intel has their own C++ compiler, not sure if AMD has one, though I heard it mentioned they've been contributing to LLVM. If the tooling developers use is enhanced for your hardware platform it will make it almost a no brainer to use for new projects.
Aside from the technology, this merger probably means a bunch more downward pressure on jobs/salaries for silicon hardware people doesn't it? The consolidations in the chip industry generally have produced an oversupply of redundant roles after mergers, such that wages in silicon jobs are much lower than in software, right? This only adds more.
So when Intel bought Altera their Stratix-10 was announced to be manufactured on Intel's fab. Predictably (Intel is not an open fab business) this massively delayed Stratix-10.
At least AMD is fabless so there should be no such issue with Xilinx.
Both Altera and Xilinx sell premium devices in terms of cost. If you make a high volume product based on an FPGA and care about profit margin, you are better off with Lattice (assuming their devices are performant enough for your application). It would be nice if any of these acquisitions made the FPGA prices more competitive, but I doubt it.
114 comments
[ 3.4 ms ] story [ 212 ms ] threadHow would you envision an "FPGA on board the CPU" differing from this? Would it still be a separate thing the way GPU is today, or would you see it more as like a new set of CPU instructions which enable little blobs of HDL to be somehow passed in and invoked, kind of like how a shader works today on GPUs?
Beyond that, there's been research in the past that envisions using a FPGA fabric as an execution unit within the CPU itself: https://www.microsoft.com/en-us/research/project/emips/ Intel hasn't pursued such a thing but that doesn't mean AMD couldn't.
Have you ever thought of building your own processor or maybe just defining your own machine instructions? With eMIPS now you can.
Microcode strikes me as the natural way to define arbitrary instructions.
There's SoC devices that have a soft processor on it that runs a linux kernel and can communicate with the FPGA.
My impression was that you tended to define pretty static blocks of functionality (you know, hash calculators for your bitcoin mining or whatever), and then just communicate to those from the OS using interrupts and a shared memory interface like any other peripheral.
Basically, I want it to implement what are essentially custom CPU instructions.
Rather than implementing your full algorithm on a big FPGA over a PCIe link, you should be able to implement just the few custom specialized instructions that regular CPU is missing, while still utilizing the regular CPU resources.
Hide the registers or set a flag if the FPGA is not configured for it.
Moreover, put another configuration flag to FPGA part so that it either shows up a device or works as a set of registers.
It's easier said than done but, it's not impossible.
The other thing to note is that this only covers using the FPGA for compute. While that's the obvious use-case for an "FPGA in CPU" concept, in the real world, IO is a pretty important part of many non-cryptocurrency FPGA applications, whether you're just counting edges on some input like an encoder, providing a highly time-sensitive output signal, such as for an SDR, or implementing some custom serial protocol.
The thing is, I don't think AMD is going to have much of an advantage. Back when AMD64 was becoming a thing, a long time ago, there was a lot of excitement around HyperTransport (HTX), around an inter-processor bus that people could make interesting accelerators out of & connect fpgas with. It never... really went anywhere. It's still supposedly quite prevalent as the basis for AMD's modern Infinity Fabric, but AMD seems to have no interest, no energy to make Infinity Fabric or HyperTransport interesting to the world, anything beyond an implementation detail.
If AMD does want to start integrating FPGAs, they either need to go back 17 years & start pushing Infinity Fabric / HyperTransport, or they need some other plan to make the fpga useful. Perhaps CXL or CCIX or GenZ or just like they do now gobs of pcie is enough, is how an fpga can mesh with core complexes & peripherals, but wow AMD would be in a much better place to start integrating FPGAs if HTX has kept up steam.
[1] https://www.anandtech.com/show/12773/intel-shows-xeon-scalab...
https://www.nextplatform.com/2018/05/24/a-peek-inside-that-i...
From what I remember, the problem is that there is a fairly large amount of work to get useful performance out of a hybrid like that. It's easier to just, say, learn CUDA and use a GPU than it is to have HDL folks work with SW. I have no doubt a system like that would be useful, but it would probably be expensive and limited to specialized, low-volume applications(like big FPGAs are now).
[0]: https://www.hpcwire.com/2011/07/13/jp_morgan_buys_into_fpga_...
Edit: Actually I'm thinking of Nvidia, with their ML supported by TensorFlow. AMD is lacking here.
I would love an RFSOC type peripheral though. Sort of a Spectrum Processing Unit or SPU. If you extrapolate the cu:Signal work to its logical extreme of a purpose built auxiliary processing unit the possibilities are pretty amazing.
[1] https://github.com/rapidsai/cusignal
Altera is doing about the same before Intel's acquisition. Or may be losing to Xilinx a little ( within margin of error )
But one thing for certain is that it hasn't grow. ( At least on paper )
So it depends how you define well. Considering the performance of Intel's past acquisition ( Look at Infineon ) and the total failure of Intel Custom Foundry I think it is doing quite well.
I never heard much more about that, but I can imagine it might've been popular with certain specialized workloads, in an era before GPU compute took off, or perhaps workloads that don't fit GPUs well.
I wonder if those specialized applications might be a small but important market.
Really cool to hear this used to be a thing with HT (though long before chiplets), gives me some hope we'll see something like that again.
what makes you believe that is has anything to do with "values"? ;)
https://www.wsj.com/articles/amd-is-in-advanced-talks-to-buy...
AMD seems to be doing well.
Intel is indeed faltering, yes. Especially with process technology. Given what they've got to work with in the process department, they've been building neat good stuff. Xe just launched & in a mobile form factor is quite competitive, no longer leaving AMD APUs to dominate. These same mobile parts have far higher integration than anything AMD can offer, with dual USB4/TB4 ports good for 2 x 40Gbps. Intel has a range of neat things few others have. Intel has a pretty competent wifi that integrates nicely. Their new Tremot Atom cores are a great value, really nice light-weight cores, & scale up to 24 cores on expensive but interesting cellular radio platforms. Xeon-D is a wonderful connectivity platform that there is not much competition for. Alas Intel cancelled OmniPath, which was a brilliant thing to integrate & give away on server CPUs almost for free (~$100 on a >> $1000 chip). And alas the process tech really hampers big server cores, but intel has been getting more competitive.
At this point, Linux need competition. Nvidia thus-far has never played well, Linux4Tegra and CUDA are walled gardens & driver support is otherwise awful, still no good way to run Wayland. AMD is doing great & Linux support is very high. But we kind of need Intel to keep AMD from growing lethargic & un-competitive, from exploiting their new market position as, well, better.
AMD really needs to focus on software if they want to catch Nvidia though.
Hope for this, the Nvidia monopoly is hurting ML, I wished to have something else but am forced to buy Nvidias offerings b/c hardware and tool support.
From an operation perspective, this combines two non-overlapping TSMC customers that can potentially negotiate better wafer prices together. I assume that AMD has significantly higher wafer counts than Xilinx so this would primarily benefit the Xilinx business.
From a technology perspective, this acquisition may succeed where the Intel/Altera acquisition fizzled due to AMD's chiplet approach. Swapping a processor core for an FPGA chiplet might be an "easy" win in some markets.
Intel has been using EIMB quite effectively to allow for very interesting fpga configurability, letting purchasers pick from a variety of "front end" transcievers to match their app[1]. This doesn't combine multiple big processors, but is still a very interesting tech!
Intel's also been working to standardize & accelerate mulit-chip connectivity, by donating their Advanced Interface Bus to the open group the CHIPS Alliance[2]. This saw a 2.0 draft emerge this summer.
Agreed that Intel has been fairly ineffective at driving interesting new fpga adoption. There has been interesting work but it's hard to see what adoption has looked like. There is the Xeon 6138P for example, which uses a UPI link and dual 8x PCIe links of a 20 core xeon chip to talk to an on-package Arria 10GX[3]. I'm not a market researcher, but my guess is that adoption hasn't been stellar. I haven't seen any follow ups. I do hope there have been some interesting & good uses though! I feel like AMD will face similar challenges to adoption. Frankly, tech like Xe and Radeon seems more appealing to the world we live in; big gpus that can do bfloat16 &c. One of the big advantages of fpgas has been great connectivity, powerful transcievers & other i/o capabilities, which, if you put them in an existing platform socket, is probably going to squander some of those capabilities, I feel like?
[1] https://www.anandtech.com/show/14211/intels-interconnected-f...
[2] https://www.anandtech.com/show/15434/intel-joins-chips-allia...
[3] https://www.anandtech.com/show/12773/intel-shows-xeon-scalab...
http://blog.notdot.net/2012/10/Build-your-own-FPGA https://news.ycombinator.com/item?id=24252737
https://github.com/haojunliu/OpenFPGA https://www.eecs.berkeley.edu/Pubs/TechRpts/2014/EECS-2014-4...
How many f8, f16, f32, f64 units you want now? Do you need some special instructions like add+multiply, or some bit permutation? You can add some.
There's no need to reconfigure it very fast, or per VM; not having to reboot the hypervisor OS would be enough. But it e.g. would allow to change the type of instances a particular server can offer, adjust to demand, and so overprovision less.
Xilinx had an opportunity to be in the position NVidia is in today and it was not obvious in 2005 who was going to win the high performance computing (HPC) market because the inherent advantages that FPGAs had and still have today for high speed I/O, RAM throughput, and hard timing requirements. NVidia's CUDA, on the other hand, produces generally painlessly portable results, with easy improvement on new devices. They have essentially won in HPC application development.
Fundamentally the FPGA companies need to adopt an open-source, cloud-first ethos towards their stacks and especially be focused on making agile low-level application development. Making a counter control some LEDs should be a 10 second process. Changing the clock speed should be a 1 seconds process. Adding a button to reset the counter should be a 1 second process. None of this is true. Good luck getting this to work within one day as a newbie on a vanilla machine. Good luck even installing Vivado and compiling any bitstream in one day (thank God they have AWS images -- good luck getting that going within 2 hours). Good luck coordinating with source control and generally merging work with a team.
There was some hope when Intel bought Altera that the compilers engineering expertise might help improve virtual CPU stacks, or at least some investment in the usability of their software tools might have been thought of as a competitive advantage, but all the FPGA vendors have seriously dropped the ball on improving the eco-system with usable software. FPGA software is so bad that you have to justify a 6 month development cycle for something that should probably take a few days if things were even remotely sane. It's hard to enumerate all the examples of broken-ness but small changes end up taking a long time to re-build, things like inverting your reset in a module and then waiting two hours for trivial changes to resynthesize and place-and-route. (edit, two hours later the trivial reset polarity inversion failed timing, because it also required me to add synchronization stages to send the inverted reset signal across clock domains, shouldn't be doing this at night).
This is probably good news only for Lattice Semiconductor.
I feel this pain!!!!
Absolutely love the flexibility of Xilinx's System-On-Module architectures but their Software toolchain is arguably the most time-wasting frustrating piece of software I have ever had to work with.
We need an open-source LLVM-like toolchain equivalent for FPGA's. I hope AMD has enough muscle to push for this.
I would also like to point out that there are projects out there pushing this boundary, David Shah has made amazing contributions towards this, with projects like SymbiFlow and yosys.
Being involved with FPGAs for 20+ years now, and Xilinx for the most part of it, I have witnessed the progressive decay of their software quality. The legacy Xilinx tools (Foundation) were far from perfect but at least useable -- and hackable to a degree if you needed to implement workarounds. Those were many times even suggested by Xilinx own employees that were easy to approach and responsive back in the days.
Altera Quartus was always better in terms of project organization and user interface, including their hardware tools. Third party software such as Synplify (before Synopsys bought their maker Synplicity) were light-years ahead, especially on the synthesis introspection and support for design and RTL troubleshooting.
People tend to justify the software quality and vendor lock-in because these are niche markets. I think that is a lame statement. You could tell both Xilinx and Altera, being "fabless hardware companies", treated their software departments as a necessary burden and not a critical part of their business model, which by de facto it was. The software started going downhill, progressively accumulating technical debt while it kept getting even more cryptic and expensive. I think they offshored a significant part of its maintenance in the last decade. Each release fixed bugs but astonishingly introduced very stupid new ones that a minimally decent software verification process should have caught.
Vivado is a mess. You can optimize your workflow digging down deeply with TCL scripts (yikes, its 2020!). However who has the time for learning their badly designed API and fighting with the quirkiness of their tools? I am amazed some of us use it in regulated environments where our tools need to be properly validated. I have had designs that take more than one day to synthesize, map and route. Having being bitten by some bugs and my own errors dealing with the cumbersome IDE, I always painfully go through all the logs of each step, and also many times recreate the project and rebuild just to check if the output is reproducible.
You can always tell when someone is a seasoned FPGA veteran by the quality of their rants about the tools.
I recently encountered a bug in the Vivado IP integrator packaging whatever crap where if you left the "Vendor name" field at its default value '(none)', the packaging aborted with an error because that field contained invalid characters: the parentheses. That's a bug that any kind of testing should have caught (two bugs, actually).
Also: Why does Vivado have to treat any little IP core I create like it's some full-fledged library that exists independently of my main project? I just want to attach a 50-line HDL module to an AXI interconnect in the block diagram – I don't want to create a new project for this, ffs.
But, if AMD really wants to get into a new market, it could try going into mobile. The 4000-series CPUs are great laptops CPUs which could go further down the scale, and over a couple generations maybe in phones too. Unlikely or stupid idea (RIP Broxton)? Still worth a shot, I feel.
Not my area of expertise, but I get the same feeling regarding their GPUs. Everything is built using CUDA, so AMD is out for ML/AI, etc.
The modern ARM cores, starting with Cortex-A55 (2017), use the corrected ISA ARMv8.2-A.
On the ancient cores used by Xilinx, when writing multithreaded applications, it is annoying to lack atomic instructions.
Yes, sure atomic instructions can be simulated with only the base ARMv8.0-A ISA, but it is not possible to guarantee worst case timings for the simulated atomics (because of retries).
This could just be a strategic acquisition for internal purposes: I bet a lot of design and architecture validation is done on big FPGAs. Maybe they wanted some custom ones?
There was a talk at 32c3 (2015) by David Kaplan from AMD about developing and testing/verifying real world x86 CPU designs:
https://media.ccc.de/v/32c3-7171-when_hardware_must_just_wor...
Around minute ~11/12 he briefly mentions (among other methods) emulation on massive FPGA workstations costing something in the order of $1M.
It is.
And the board and software used for this are so damn expensive they probably account for half of xilinx income despite the low quantities
But things has changed since 2016 - 2018. I used to see the move to FPGA as going offensive attack in the server space, now both AMD, and Intel are doing what ever they can to fence off ARM.
You should sit on some TSLA for now also.
But yes, a software stack would help.
The second thing was bundling FPGAs into the same package as a CPU. There were two problems with this, firstly it's a load of dark silicon when you aren't using the FPGA part and you have to make a load of tricky decisions like "Am I going to design my thermals to let me run all the Xeon cores at max speed whilst running my FPGA". The other problem being that it's really bloody hard figuring out the programming model, where the FPGA wants a deterministic data flow and you've got these CPU nutters throwing memory at you out of order, stalling and screwing you up with really bizarre cache behaviour. Since the CPU guys designed the interface it leaves the FPGA developer an almost impossible task to build efficient processing pipelines.
Finally we've got the moonshot - the idea that you could come up with a high level design language to programme FPGAs like software. Intel very heavily invested in this when they bought Altera but I'm still not seeing any forward progress on this, and let's be clear, Intel poured huge resources into making that happen. The last I heard they had over 100 engineers on that project and the sum total of their achievement is a handful of "partners" who wrote OpenCL/HLS/whatever and then worked with the engineers to go through a grueling process re-writing their code over and over and over until it looked like the RTL they already wanted. At one point Intel were going to re-write their entire FPGA video IP suite in HLS, I don't know how they went, but the acquisition of Omnitek probably wasn'ta good sign. It's been 4 years since the acquisition, and they were working on it long before then. The project is still basically just a load of marketing guff on their website that no one can actually use. I would say with the innevitable restructuring that Intel will have to do due to their various other fuck ups, this project is on thin ice.
The problem is that AMD is so likely to fall into the trap of points 2 and 3, and we're going to lose the final big independent FPGA company so that AMD can kill themselves trying to compete with Nvidia. And the real danger is that whilst all that's happening, actual innovation will disappear in the FPGA space. Xilinx's ACAPs are actually interesting (one way of solving the programming model), but Intel's last piece of innovation in the FPGA space died with the failure of hyperflex.
FPGAs are such a useful tool for a variety of engineering (and product) problems that fall in-between general computing and ASICs, unfortunately these problems are usually so disparate in nature that you can't target them as a single market. So the datacenter / HLS game will keep going until either a viable solution for the programming model is found or until everyone gives up on it once and for all and decides that FPGAs should go back to their niche (which is fine by me)
https://github.com/RadeonOpenCompute/ROCm/issues/892
At least AMD is fabless so there should be no such issue with Xilinx.
Both Altera and Xilinx sell premium devices in terms of cost. If you make a high volume product based on an FPGA and care about profit margin, you are better off with Lattice (assuming their devices are performant enough for your application). It would be nice if any of these acquisitions made the FPGA prices more competitive, but I doubt it.