5 ms·

Chisel/FIRRTL Hardware Compiler Framework

59 points by lnyan 5y ago

syntaxing 5y ago
I think (?) the first generation of TPU and Coral chips were designed using Chisel. There was a good presentation done by Google a while back but I will have to dig for it to find it
- ekiwi 5y ago
  It was in fact the EdgeTPU (which is different from the TPU used in data centers). The talk from a google engineer can be found on youtube: https://www.youtube.com/watch?v=x85342Cny8c https://www.youtube.com/watch?v=x85342Cny8c Please note that they were using a version of Chisel from 5+ years ago and many things have changed since then. It is still true though that Chisel can be hard to learn for typical hardware engineers, which is why it may be best suited for small and highly dedicated teams rather then large hardware companies. [EDIT] Here is a talk from a solo-developer using the latest version of Chisel: https://www.youtube.com/watch?v=Wst8IoYRWKo https://www.youtube.com/watch?v=Wst8IoYRWKo
  - Rochus 5y ago
    Some interesting quotes from the presentation: "frankly, most hardware engineers don't really get passed this yellow [Chisel learning] curve" "Chisel makes the long pole of chip design longer" "the productivity gains we might have had on the design side were more than lost on the verification side" "It might be a hard sell for other projects to adopt Chisel [...] there were a buch of dark periods, mostly".
    - cushychicken 5y ago
      the productivity gains we might have had on the design side were more than lost on the verification side This makes sense. Without a complementary lift to verification capability, a lot of the design side wins don't gain you much.
      - aDfbrtVt 5y ago
        I'm very surprised by the reported cost to verification. One of the major reasons to move to a high level synthesis design strategy is to ensure equivalence between your models and RTL. I have experience with C++ HLS and it has enabled massive reductions in verification time.
        ekiwi 5y ago
        Chisel is not HLS. It is a Scala library that lets you generate circuits on an RTL abstraction level. That means that you explicitly define every state element like registers and memories. But you can generate N registers inside a loop (or a map/foreach) instead of only 1 at a time. In HLS the compiler needs to somehow infer your registers and memories. That said, I think one of the problems the google team was struggling with is that in traditional HW development there is design and a separate verification team. The design team bought into Chisel since it would let them generate hardware more quickly, but the verification team just tried to apply their traditional verification methods on the _generated_ Verilog. This is almost like trying to test the assembly that a C++ compiler generates instead of trying to test the C++ program since all your testing infrastructure is setup for testing assembly code and that is "what we have always been doing". In order to catch verification up to modern Hardware Construction Languages [0] we need more powerful verification libraries that can allow us to build tests that can automatically adapt to the parameters that were supplied to the hardware generator. There are different groups working on this right now. The jury is still out on how to best solver the "verification gap". In case you are interested: - https://github.com/chiselverify/chiselverify https://github.com/chiselverify/chiselverify - https://github.com/leonardt/fault https://github.com/leonardt/fault - https://github.com/ucb-bar/chisel-testers2/ https://github.com/ucb-bar/chisel-testers2/ I am probably missing some approaches from the nmigen world that I am not familiar with. You can always write cocotb [1] tests in python, but I am not sure if they can directly interface with nmigen generators to adapt to their parameterization. [0] besides Chisel, there is also https://github.com/nmigen/nmigen https://github.com/nmigen/nmigen and https://github.com/SpinalHDL/SpinalHDL https://github.com/SpinalHDL/SpinalHDL [1] https://github.com/cocotb/cocotb https://github.com/cocotb/cocotb
xvilka 5y ago
There was a suggestion[1] (by me) to coordinate more between various hardware design/programming tools to agree on the common intermediate representation. Sadly, nothing came out of it yet. [1] https://github.com/SymbiFlow/ideas/issues/19 https://github.com/SymbiFlow/ideas/issues/19
- ekiwi 5y ago
  Did you see the work being done on CIRCT? https://github.com/llvm/circt https://github.com/llvm/circt I remember one of the reasons you did not want to use firrtl was that its compiler is implemented in Scala and thus hard to integrate into other projexts. CIRCT will solve that problem by providing a firrtl compiler implemented in C++. Other languages like Verilog/VHDL and new high level languages for HLS-like designs are also on the todo list.
  - mikeurbach 5y ago
    I contribute to CIRCT, so I feel like I should chime in here. I personally hope that it can provide exactly the kind of unifying IRs we are all hoping for in the open-source community. The fact that the tools are implemented in C++ may be a win for some, but I think the CIRCT project is compelling for much deeper reasons. The README states the ambition clearly: > By working together, we hope that we can build a new center of gravity to draw contributions from the small (but enthusiastic!) community of people who work on open hardware tooling. There are weekly community meetings that are open to the public, and we have guest speakers from all sorts of interesting projects in the open-source community. Many of those are leading to collaborations and contributions to CIRCT. There hasn't been much (any?) discussion of CIRCT on HN, but rather than present the reasons I think it's so great here, I'll point to a talk[1] I gave earlier this year and a much better talk[2] Chris Lattner gave shortly thereafter, both of which lead up to the "Why CIRCT?" question in the second half. Looking back at that SymbiFlow thread, I see familiar faces that are now actively contributing to CIRCT. There are mentions of many different hardware IRs in some of the posts, but at least three have first-class support in CIRCT today: FIRRTL[3], LLHD[4], and Calyx[5]. This is all very recent and experimental, but I would say the results are already promising. [1] https://slideslive.com/38955645/applying-circuit-ir-compilers-and-tools-circt-to-ml-applications https://slideslive.com/38955645/applying-circuit-ir-compiler... [2] https://www.youtube.com/watch?v=4HgShra-KnY https://www.youtube.com/watch?v=4HgShra-KnY [3] https://circt.llvm.org/docs/Dialects/FIRRTL/ https://circt.llvm.org/docs/Dialects/FIRRTL/ [4] https://circt.llvm.org/docs/Dialects/LLHD/ https://circt.llvm.org/docs/Dialects/LLHD/ [5] https://circt.llvm.org/docs/Dialects/Calyx/ https://circt.llvm.org/docs/Dialects/Calyx/

59 points by lnyan 5y ago

I think (?) the first generation of TPU and Coral chips were designed using Chisel. There was a good presentation done by Google a while back but I will have to dig for it to find it

ekiwi 5y ago
It was in fact the EdgeTPU (which is different from the TPU used in data centers). The talk from a google engineer can be found on youtube: https://www.youtube.com/watch?v=x85342Cny8c https://www.youtube.com/watch?v=x85342Cny8c Please note that they were using a version of Chisel from 5+ years ago and many things have changed since then. It is still true though that Chisel can be hard to learn for typical hardware engineers, which is why it may be best suited for small and highly dedicated teams rather then large hardware companies. [EDIT] Here is a talk from a solo-developer using the latest version of Chisel: https://www.youtube.com/watch?v=Wst8IoYRWKo https://www.youtube.com/watch?v=Wst8IoYRWKo
- Rochus 5y ago
  Some interesting quotes from the presentation: "frankly, most hardware engineers don't really get passed this yellow [Chisel learning] curve" "Chisel makes the long pole of chip design longer" "the productivity gains we might have had on the design side were more than lost on the verification side" "It might be a hard sell for other projects to adopt Chisel [...] there were a buch of dark periods, mostly".
  - cushychicken 5y ago
    the productivity gains we might have had on the design side were more than lost on the verification side This makes sense. Without a complementary lift to verification capability, a lot of the design side wins don't gain you much.
    - aDfbrtVt 5y ago
      I'm very surprised by the reported cost to verification. One of the major reasons to move to a high level synthesis design strategy is to ensure equivalence between your models and RTL. I have experience with C++ HLS and it has enabled massive reductions in verification time.
      - ekiwi 5y ago
        Chisel is not HLS. It is a Scala library that lets you generate circuits on an RTL abstraction level. That means that you explicitly define every state element like registers and memories. But you can generate N registers inside a loop (or a map/foreach) instead of only 1 at a time. In HLS the compiler needs to somehow infer your registers and memories. That said, I think one of the problems the google team was struggling with is that in traditional HW development there is design and a separate verification team. The design team bought into Chisel since it would let them generate hardware more quickly, but the verification team just tried to apply their traditional verification methods on the _generated_ Verilog. This is almost like trying to test the assembly that a C++ compiler generates instead of trying to test the C++ program since all your testing infrastructure is setup for testing assembly code and that is "what we have always been doing". In order to catch verification up to modern Hardware Construction Languages [0] we need more powerful verification libraries that can allow us to build tests that can automatically adapt to the parameters that were supplied to the hardware generator. There are different groups working on this right now. The jury is still out on how to best solver the "verification gap". In case you are interested: - https://github.com/chiselverify/chiselverify https://github.com/chiselverify/chiselverify - https://github.com/leonardt/fault https://github.com/leonardt/fault - https://github.com/ucb-bar/chisel-testers2/ https://github.com/ucb-bar/chisel-testers2/ I am probably missing some approaches from the nmigen world that I am not familiar with. You can always write cocotb [1] tests in python, but I am not sure if they can directly interface with nmigen generators to adapt to their parameterization. [0] besides Chisel, there is also https://github.com/nmigen/nmigen https://github.com/nmigen/nmigen and https://github.com/SpinalHDL/SpinalHDL https://github.com/SpinalHDL/SpinalHDL [1] https://github.com/cocotb/cocotb https://github.com/cocotb/cocotb

xvilka 5y ago

There was a suggestion[1] (by me) to coordinate more between various hardware design/programming tools to agree on the common intermediate representation. Sadly, nothing came out of it yet. [1] https://github.com/SymbiFlow/ideas/issues/19 https://github.com/SymbiFlow/ideas/issues/19

ekiwi 5y ago
Did you see the work being done on CIRCT? https://github.com/llvm/circt https://github.com/llvm/circt I remember one of the reasons you did not want to use firrtl was that its compiler is implemented in Scala and thus hard to integrate into other projexts. CIRCT will solve that problem by providing a firrtl compiler implemented in C++. Other languages like Verilog/VHDL and new high level languages for HLS-like designs are also on the todo list.
- mikeurbach 5y ago
  I contribute to CIRCT, so I feel like I should chime in here. I personally hope that it can provide exactly the kind of unifying IRs we are all hoping for in the open-source community. The fact that the tools are implemented in C++ may be a win for some, but I think the CIRCT project is compelling for much deeper reasons. The README states the ambition clearly: > By working together, we hope that we can build a new center of gravity to draw contributions from the small (but enthusiastic!) community of people who work on open hardware tooling. There are weekly community meetings that are open to the public, and we have guest speakers from all sorts of interesting projects in the open-source community. Many of those are leading to collaborations and contributions to CIRCT. There hasn't been much (any?) discussion of CIRCT on HN, but rather than present the reasons I think it's so great here, I'll point to a talk[1] I gave earlier this year and a much better talk[2] Chris Lattner gave shortly thereafter, both of which lead up to the "Why CIRCT?" question in the second half. Looking back at that SymbiFlow thread, I see familiar faces that are now actively contributing to CIRCT. There are mentions of many different hardware IRs in some of the posts, but at least three have first-class support in CIRCT today: FIRRTL[3], LLHD[4], and Calyx[5]. This is all very recent and experimental, but I would say the results are already promising. [1] https://slideslive.com/38955645/applying-circuit-ir-compilers-and-tools-circt-to-ml-applications https://slideslive.com/38955645/applying-circuit-ir-compiler... [2] https://www.youtube.com/watch?v=4HgShra-KnY https://www.youtube.com/watch?v=4HgShra-KnY [3] https://circt.llvm.org/docs/Dialects/FIRRTL/ https://circt.llvm.org/docs/Dialects/FIRRTL/ [4] https://circt.llvm.org/docs/Dialects/LLHD/ https://circt.llvm.org/docs/Dialects/LLHD/ [5] https://circt.llvm.org/docs/Dialects/Calyx/ https://circt.llvm.org/docs/Dialects/Calyx/