3 ms·

To be fair, this is a paper about FPGA use internally for Microsoft for their datacenters for select applications. You're probably never going to be exposed to

by aseipp 10y ago

To be fair, this is a paper about FPGA use internally for Microsoft for their datacenters for select applications. You're probably never going to be exposed to the fabric yourselves, unless you have ungodly amounts of money to pay them behind closed doors, or just buy your own custom systems. Average individuals are no closer to these hybrid, re-programmable systems than they were before. Anyway -- doesn't Chisel just generate Verilog, like basically every other alternative HDL does? What's the problem with just plugging that resulting code into your synthesis tool and going at it? Granted, the "plugging" part is the annoying bit, since most EDA toolchains seem to be fundamentally hostile to the outside world. But it doesn't really seem like Chisel should be the limiting factor here, at all. (As an alternative case study -- it was very easy for me to integrate a 3rd party HDL (Clash) with tools like IceStorm, but it did require some automation boilerplate)

webaholic 10y ago
It does generate verilog, but there is quite a lot of glue which you need to run that verilog on an fpga. And all this glue is proprietary(I heard some rumblings about open tools being pretty limited), you need a license to use the compilers which compile the verilog to bitcode.
- aseipp 10y ago
  Sure, but that's the truth no matter what EDA toolchain you're using and has nothing to do with Microsoft, or their FPGA deployments at all - all modern, high-end FPGAs are proprietary from top to bottom, and every vendor has different logic libraries and hardware capabilities. High end customers such as Microsoft very likely have their own completely custom silicon with custom chip layout -- It would be extremely costly to start developing and supporting such things at a "consumer level". And things like Chisel and Clash - despite my affections - are still actively evolving research projects, and they only concern themselves with one part of the overall process. They still leave many things to be desired -- for example, I'm still working out the best ways to integrate Clash with the formal verification tools of Yosys, in a way that doesn't just require me to shim some Verilog code. That might require improving the language/libraries to allow the notion of things like SystemVerilog properties. I don't know what it would look like to integrate multi-clock verification with the type safe cross-domain clocks of Clash, etc. There's a lot of things I still can't do with these tools alone, and because they're moving targets, that means I generally have to pick up the slack. They can certainly offer many advantages in terms of time-to-iterate and time-to-fabricate, but they aren't magic wands. Furthermore -- and I really don't mean to be flippant -- if you're the kind of group who would benefit from FPGAs being deployed to accelerate your workload, but you're blocked on things like gluing Chisel code to your EDA toolchain -- well, you're going to be in for a very rude awakening when you realize that's an incredibly tiny, easy part of the overall process.
webaholic 10y ago
There is no reason for microsoft not to expose the fabric to customers of Azure. I am sure there are applications out there which can benefit by being able to synthesize their own code just like microsoft did for its bing search traffic etc.,
- aseipp 10y ago
  Of course there are reasons not to expose it, what are you talking about? Support, reliability, isolation, debuggability, and platform control are a few reasons (it would be a goddamn nightmare to debug these things remotely, not to mention provide support for them through traditional channels -- and let's not even begin thinking about the security nightmare it could imply to do things like securely provision FPGAs on demand, or wipe them after the fact. Bare-metal cloud providers already have a lot to do here, because the threat model involves people who can do shit like flash your BIOS or attack your firmware). If these aren't a challenge for you, and FPGA development would actually pay off economically -- you're already in a decidedly different market than the vast majority of Azure customers. Even then, there's also no indication it would actually be profitable for them - FPGAs are actually quite niche in their applications and require extensive development cycles in order to utilize to their full potential, especially for complex tasks. Microsoft and Azure employees can justify this because of economies of scale as of right now. It's a labor intensive process -- there's no indication a vast majority of applications would find a good use case for developing their own fabric, one that would offset the costs. What's more likely is that people like Microsoft and Google will start offering you serves that are powered by this stuff under the hood, to give their platforms a competitive advantage. A better SQL server enhanced with custom logic is far more valuable to the vast majority of their customers than being able to program some custom fabric themselves, in today's world. Microsoft already has custom fabricated Xeons with unlocked silicon for example, giving them private functionality to accelerate things like SDN workloads, and those Xeons power Azure -- why aren't you being given access to those? For the same reasons: those features only make sense to support, develop and utilize at a certain scale for the involved parties -- and it gives them competitive advantages when used to accelerate traditional workloads (that can only be realized with a substantial amount of work on part of the vendor, but is "free" for the customers.) The venn diagram of "People who have a problem which FPGAs would solve" and "Customers who desire commodity cloud computing on Azure" is extremely small. That could change one day, but it doesn't look like it's set to change anytime in the near future, especially given the landscape of EDA tooling, and the fundamentally different cost models associated with hardware vs software development.

by aseipp 10y ago

webaholic 10y ago

It does generate verilog, but there is quite a lot of glue which you need to run that verilog on an fpga. And all this glue is proprietary(I heard some rumblings about open tools being pretty limited), you need a license to use the compilers which compile the verilog to bitcode.

aseipp 10y ago
Sure, but that's the truth no matter what EDA toolchain you're using and has nothing to do with Microsoft, or their FPGA deployments at all - all modern, high-end FPGAs are proprietary from top to bottom, and every vendor has different logic libraries and hardware capabilities. High end customers such as Microsoft very likely have their own completely custom silicon with custom chip layout -- It would be extremely costly to start developing and supporting such things at a "consumer level". And things like Chisel and Clash - despite my affections - are still actively evolving research projects, and they only concern themselves with one part of the overall process. They still leave many things to be desired -- for example, I'm still working out the best ways to integrate Clash with the formal verification tools of Yosys, in a way that doesn't just require me to shim some Verilog code. That might require improving the language/libraries to allow the notion of things like SystemVerilog properties. I don't know what it would look like to integrate multi-clock verification with the type safe cross-domain clocks of Clash, etc. There's a lot of things I still can't do with these tools alone, and because they're moving targets, that means I generally have to pick up the slack. They can certainly offer many advantages in terms of time-to-iterate and time-to-fabricate, but they aren't magic wands. Furthermore -- and I really don't mean to be flippant -- if you're the kind of group who would benefit from FPGAs being deployed to accelerate your workload, but you're blocked on things like gluing Chisel code to your EDA toolchain -- well, you're going to be in for a very rude awakening when you realize that's an incredibly tiny, easy part of the overall process.

webaholic 10y ago

There is no reason for microsoft not to expose the fabric to customers of Azure. I am sure there are applications out there which can benefit by being able to synthesize their own code just like microsoft did for its bing search traffic etc.,

aseipp 10y ago
Of course there are reasons not to expose it, what are you talking about? Support, reliability, isolation, debuggability, and platform control are a few reasons (it would be a goddamn nightmare to debug these things remotely, not to mention provide support for them through traditional channels -- and let's not even begin thinking about the security nightmare it could imply to do things like securely provision FPGAs on demand, or wipe them after the fact. Bare-metal cloud providers already have a lot to do here, because the threat model involves people who can do shit like flash your BIOS or attack your firmware). If these aren't a challenge for you, and FPGA development would actually pay off economically -- you're already in a decidedly different market than the vast majority of Azure customers. Even then, there's also no indication it would actually be profitable for them - FPGAs are actually quite niche in their applications and require extensive development cycles in order to utilize to their full potential, especially for complex tasks. Microsoft and Azure employees can justify this because of economies of scale as of right now. It's a labor intensive process -- there's no indication a vast majority of applications would find a good use case for developing their own fabric, one that would offset the costs. What's more likely is that people like Microsoft and Google will start offering you serves that are powered by this stuff under the hood, to give their platforms a competitive advantage. A better SQL server enhanced with custom logic is far more valuable to the vast majority of their customers than being able to program some custom fabric themselves, in today's world. Microsoft already has custom fabricated Xeons with unlocked silicon for example, giving them private functionality to accelerate things like SDN workloads, and those Xeons power Azure -- why aren't you being given access to those? For the same reasons: those features only make sense to support, develop and utilize at a certain scale for the involved parties -- and it gives them competitive advantages when used to accelerate traditional workloads (that can only be realized with a substantial amount of work on part of the vendor, but is "free" for the customers.) The venn diagram of "People who have a problem which FPGAs would solve" and "Customers who desire commodity cloud computing on Azure" is extremely small. That could change one day, but it doesn't look like it's set to change anytime in the near future, especially given the landscape of EDA tooling, and the fundamentally different cost models associated with hardware vs software development.