4 ms·

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 rumbling

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.

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.