13 ms·

I wish they would work out how to run the chisel toolchain on those fpgas. From what I understand, you have to program in verilog currently which is a huge pain

I wish they would work out how to run the chisel toolchain on those fpgas. From what I understand, you have to program in verilog currently which is a huge pain. Please enable chisel and put it in your Azure cloud. It will be a great platform for custom software.

sargun 10y ago
Azure and Bing are two different departments.
- LyalinDotCom 10y ago
  Things will never be perfect as it is a huge company, but thanks to Satya teams are working a lot more together
- webaholic 10y ago
  They are moving towards homogeneous systems in all their data centers. Each and every system will have these fpgas.
wyager 10y ago
I've tried both Chisel and Clash. They are both huge improvements over Verilog, but I was more impressed with the latter. Clash converts run-of-the-mill non-recursive Haskell code into hardware, and does so fairly efficiently. It turns out there's a really really close mapping between lazy functional semantics and hardware semantics.
DigitalJack 10y ago
Can you recommend some resources on chisel? I've been an ASIC/FPGA designer for 20 years. We mostly do VHDL and SystemVerilog for design, and SystemVerilog for verification. I've only heard about chisel briefly, used in reference to a risc design I think. I've considered making a lisp like language for design on a few occasions. But maybe chisel solves the pain points?
- aseipp 10y ago
  Chisel is the language used to describe the RISC-V Rocket core, which is the current primary RISC-V implementation and reference (with real, synthesized boards coming out of it). > I've considered making a lisp like language for design on a few occasions. But maybe chisel solves the pain points? To be honest, I've only been doing FPGA design for a few weeks but, like: basically anything is better than VHDL/Verilog IMO. :) Personally, I prefer CLaSH as opposed to Chisel. (Chisel is a DSL built using Scala - Clash is actually a compiler, not a DSL, from Haskell to Hardware. I think CLaSH conceptually is very nice.) But honestly it really does seem to me that anything is a vast improvement over the current languages, for the most part. Your life is simply vastly improved by being able to do things like use a REPL in Scala/Haskell, or having cosimulation support in your toolchains (so you can run your designs as cycle-accurate software simulations, with no code changes, before doing synthesis). Even then -- the intuition to use, or build something like Lisp isn't necessarily misplaced! Hardware description and functional programming share some interesting commonalities, it seems.
  - blackguardx 10y ago
    The key to learning HDL is to understand that it isn't software. There are no instructions to a state machine. You are describing the functionality of the state machine itself.
    - aseipp 10y ago
      Not to sound rude, but what are you addressing with this statement? I've been doing functional programming for over a decade; I'm quite familiar with the concept of declarative programming, so circuits were not a big leap from this point (one of the many ways in which FP nicely dovetails with hardware design.) My point wasn't really about state machines or whatever. Languages like Verilog and VHDL are absolutely terrible at things like abstraction capabilities. You don't have modules, you don't have a REPL, you don't have any kind of abstraction facilities almost at all, on top of the languages being ridiculously verbose. They sit in some bizarre uncanny valley where anything takes a surprising amount of code to write, yet is terrible in terms of reuse, modularity, understandability, etc. Example: A few weeks ago I ran into a case where I couldn't easily wrap a cell library primitive by wrapping it in a Verilog module, and then re-use that module a few times. The primitive was a PLL on my board. Oops, can't do that -- because the synthesis toolchain disliked a module around the PLL primitive, as the primitive had some arguments which were required to be constants (despite the fact all call sites to the wrapping module had constant arguments). So I had to use a Verilog macro which generated a Verilog module, and I had to instantiate that macro like 10 times to 10 different modules, each one corresponding to a different clock speed, with no reuse outside of a Macro. Because some parameters had to be constant. If Verilog metaprogramming wasn't just a rip off of C macros, it might not be so terrible. But shit like this is just tedious. I can't even do things like use higher order functions, or strong typing capabilities, or things like leverage a real module system (with boundary and abstraction capabilities) -- even when I am completely in control of their use and completely understand how they will synthesize. Tools like REPLs vastly improve time-to-iterate with an interactive environment. Cosimulation being a primary feature of these tools means I generally get fairly accurate software simulations directly from my HDL itself, independent of any EDA toolchain etc. The languages are just bad languages. Can you get work done in them? Yes, and everybody does. Do they accurately reflect the fact you're declaratively describing a hardware circuit? Yes. That doesn't mean Verilog/VHDL, as languages, aren't objectively terrible. I understand why this is. The cost models associated with these tools -- and process -- are fundamentally different (for hardware, it's not about "determinism" like software programmers care about -- but things like MTTF, lead time, and optimizing around that), and Verilog is really a small portion of the overall lifecycle of developing a chip (you still need post-synth testing, possibly do gate-level debugging, post-synth modifications, on-board testing, etc). And tools like Clash/Chisel are not perfect by any means, and I still have plenty of slack to pick up by myself, nonetheless. The languages are still bad, despite all that.
monocasa 10y ago
What? Chisel compiles to Verilog generally?
- webaholic 10y ago
  see above...
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.
blackguardx 10y ago
I'm curious as to why you think Verilog a huge pain. I would think that the toolchains would be the biggest complaint. If one wanted to do web development, javascript knowledge is important. It is the same with FPGAs and HDL.

sargun 10y ago

Azure and Bing are two different departments.

LyalinDotCom 10y ago
Things will never be perfect as it is a huge company, but thanks to Satya teams are working a lot more together
webaholic 10y ago
They are moving towards homogeneous systems in all their data centers. Each and every system will have these fpgas.

wyager 10y ago

I've tried both Chisel and Clash. They are both huge improvements over Verilog, but I was more impressed with the latter. Clash converts run-of-the-mill non-recursive Haskell code into hardware, and does so fairly efficiently. It turns out there's a really really close mapping between lazy functional semantics and hardware semantics.

DigitalJack 10y ago

Can you recommend some resources on chisel? I've been an ASIC/FPGA designer for 20 years. We mostly do VHDL and SystemVerilog for design, and SystemVerilog for verification. I've only heard about chisel briefly, used in reference to a risc design I think. I've considered making a lisp like language for design on a few occasions. But maybe chisel solves the pain points?

aseipp 10y ago
Chisel is the language used to describe the RISC-V Rocket core, which is the current primary RISC-V implementation and reference (with real, synthesized boards coming out of it). > I've considered making a lisp like language for design on a few occasions. But maybe chisel solves the pain points? To be honest, I've only been doing FPGA design for a few weeks but, like: basically anything is better than VHDL/Verilog IMO. :) Personally, I prefer CLaSH as opposed to Chisel. (Chisel is a DSL built using Scala - Clash is actually a compiler, not a DSL, from Haskell to Hardware. I think CLaSH conceptually is very nice.) But honestly it really does seem to me that anything is a vast improvement over the current languages, for the most part. Your life is simply vastly improved by being able to do things like use a REPL in Scala/Haskell, or having cosimulation support in your toolchains (so you can run your designs as cycle-accurate software simulations, with no code changes, before doing synthesis). Even then -- the intuition to use, or build something like Lisp isn't necessarily misplaced! Hardware description and functional programming share some interesting commonalities, it seems.
- blackguardx 10y ago
  The key to learning HDL is to understand that it isn't software. There are no instructions to a state machine. You are describing the functionality of the state machine itself.
  - aseipp 10y ago
    Not to sound rude, but what are you addressing with this statement? I've been doing functional programming for over a decade; I'm quite familiar with the concept of declarative programming, so circuits were not a big leap from this point (one of the many ways in which FP nicely dovetails with hardware design.) My point wasn't really about state machines or whatever. Languages like Verilog and VHDL are absolutely terrible at things like abstraction capabilities. You don't have modules, you don't have a REPL, you don't have any kind of abstraction facilities almost at all, on top of the languages being ridiculously verbose. They sit in some bizarre uncanny valley where anything takes a surprising amount of code to write, yet is terrible in terms of reuse, modularity, understandability, etc. Example: A few weeks ago I ran into a case where I couldn't easily wrap a cell library primitive by wrapping it in a Verilog module, and then re-use that module a few times. The primitive was a PLL on my board. Oops, can't do that -- because the synthesis toolchain disliked a module around the PLL primitive, as the primitive had some arguments which were required to be constants (despite the fact all call sites to the wrapping module had constant arguments). So I had to use a Verilog macro which generated a Verilog module, and I had to instantiate that macro like 10 times to 10 different modules, each one corresponding to a different clock speed, with no reuse outside of a Macro. Because some parameters had to be constant. If Verilog metaprogramming wasn't just a rip off of C macros, it might not be so terrible. But shit like this is just tedious. I can't even do things like use higher order functions, or strong typing capabilities, or things like leverage a real module system (with boundary and abstraction capabilities) -- even when I am completely in control of their use and completely understand how they will synthesize. Tools like REPLs vastly improve time-to-iterate with an interactive environment. Cosimulation being a primary feature of these tools means I generally get fairly accurate software simulations directly from my HDL itself, independent of any EDA toolchain etc. The languages are just bad languages. Can you get work done in them? Yes, and everybody does. Do they accurately reflect the fact you're declaratively describing a hardware circuit? Yes. That doesn't mean Verilog/VHDL, as languages, aren't objectively terrible. I understand why this is. The cost models associated with these tools -- and process -- are fundamentally different (for hardware, it's not about "determinism" like software programmers care about -- but things like MTTF, lead time, and optimizing around that), and Verilog is really a small portion of the overall lifecycle of developing a chip (you still need post-synth testing, possibly do gate-level debugging, post-synth modifications, on-board testing, etc). And tools like Clash/Chisel are not perfect by any means, and I still have plenty of slack to pick up by myself, nonetheless. The languages are still bad, despite all that.

monocasa 10y ago

What? Chisel compiles to Verilog generally?

webaholic 10y ago
see above...

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.

blackguardx 10y ago

I'm curious as to why you think Verilog a huge pain. I would think that the toolchains would be the biggest complaint. If one wanted to do web development, javascript knowledge is important. It is the same with FPGAs and HDL.