4 ms·

I am hardware engineer in this industry. And I know Haskell and made my site with Haskell language. But I do not understand why Haskell is used to hardware desi

I am hardware engineer in this industry. And I know Haskell and made my site with Haskell language. But I do not understand why Haskell is used to hardware design. Designing hardware is much more important than describing hardware logic itself. IMO, VISIO and Excel are the tools to design hardware logic not Verilog nor like this CLaSH. But, If this kind of HDL can be used along with Verilog, it might be helpful to build verification IPs.

zhemao 12y ago
Wait, so what are you using to describe the circuit on the logic or RTL level? Do you have VLSI engineers using Cadence or something? From my understanding, using Verilog in ASIC design (and not just verification) is pretty widespread in industry.
- platinum1 12y ago
  I think what he's saying is the architectural decisions outweigh the implementation language. When I was taught Verilog for IP implementation, one thing I noticed is that people get caught in the trap of trying to abstract away the hardware or approach it from a higher level. Haskell/Verilog 2001/SystemVerilog all give us tools to do this. However, when trying to make real silicon, you need to understand what is actually getting built (i.e. know exactly how many flip flops you're creating and how they fan out) and then use the language to describe it. If you use a 'for' loop to try to do computation, as you might in a programming language, you could end up with something entirely unexpected or unsynthesizable. Traditionally you first design your module conceptually on a whiteboard (or Excel, Viso, etc.), then implement it in an HDL. Because of the influx of software engineers trying to get into hardware (via FPGAs, etc.), there has been a trend in trying to obfuscate away the details of the implementation, and this can cause a lot of confusion. That said, I've heard of projects that already translate native Haskell to HDL with some success. I'm not a programmer so I don't claim to understand if it's a good idea, but I still think understanding exactly what's being output is important to knowing if it can perform in a reasonable way, especially if you're doing something of any complexity.
  - dkarapetyan 12y ago
    How is this any different from compiling C to assembly? Why would higher level languages create unsynthesizable circuits? You trust the C compiler to create the proper instructions for your target architecture then I don't see why the same can't be done with a Haskell DSL that compiles to Verilog.
    - cantankerous 12y ago
      Higher level languages inevitably come with built in semantics that the programmer takes for granted, but can't be synthesized directly to hardware. In C, it's the function call stack. In Haskell it's higher order types and recursive data structures (and more). You could in theory create some runtime package that you'd compile to hardware for your program to be synthesized to, or "run on".....but then you'd just be making a straight up computer, wouldn't you. ;-)
      - jroesch 12y ago
        None of these things are relevant in most HDLs implemented as DSLs in high level languages. The point of most of the HDL work in Haskell (for example Lava, and Bluespec) is to provide primitives to talk about hardware and to use a sane language as a way to manipulate them to build larger specifications. It is embarrassing that people use tools that allow you to write un-synthesizable code.
    - marcosdumay 12y ago
      A computer is a much simpler abstraction and much less leaky than a circuit model. Yes, in theory a computer could get a high level description of a circuit, and turn it into a very efficient hardware implementation. In practice our computers are not good enough - the same way they were not good enough for compiling high level languages at the 70's, and people wrote assembly by hand.
    - axman6 12y ago
      From memory, in several HDLs like VHDL and Verilog, a "boolean" value can have up to 8 or so different values (true, false, undefined, hi, lo (different from true and false apparently) plus a few more). My experience with Verilog is that it's very easy to write things which look fine, you can simulate and then fail in hardware; the semantics are just wrong in the languages.

zhemao 12y ago

Wait, so what are you using to describe the circuit on the logic or RTL level? Do you have VLSI engineers using Cadence or something? From my understanding, using Verilog in ASIC design (and not just verification) is pretty widespread in industry.

platinum1 12y ago
I think what he's saying is the architectural decisions outweigh the implementation language. When I was taught Verilog for IP implementation, one thing I noticed is that people get caught in the trap of trying to abstract away the hardware or approach it from a higher level. Haskell/Verilog 2001/SystemVerilog all give us tools to do this. However, when trying to make real silicon, you need to understand what is actually getting built (i.e. know exactly how many flip flops you're creating and how they fan out) and then use the language to describe it. If you use a 'for' loop to try to do computation, as you might in a programming language, you could end up with something entirely unexpected or unsynthesizable. Traditionally you first design your module conceptually on a whiteboard (or Excel, Viso, etc.), then implement it in an HDL. Because of the influx of software engineers trying to get into hardware (via FPGAs, etc.), there has been a trend in trying to obfuscate away the details of the implementation, and this can cause a lot of confusion. That said, I've heard of projects that already translate native Haskell to HDL with some success. I'm not a programmer so I don't claim to understand if it's a good idea, but I still think understanding exactly what's being output is important to knowing if it can perform in a reasonable way, especially if you're doing something of any complexity.
- dkarapetyan 12y ago
  How is this any different from compiling C to assembly? Why would higher level languages create unsynthesizable circuits? You trust the C compiler to create the proper instructions for your target architecture then I don't see why the same can't be done with a Haskell DSL that compiles to Verilog.
  - cantankerous 12y ago
    Higher level languages inevitably come with built in semantics that the programmer takes for granted, but can't be synthesized directly to hardware. In C, it's the function call stack. In Haskell it's higher order types and recursive data structures (and more). You could in theory create some runtime package that you'd compile to hardware for your program to be synthesized to, or "run on".....but then you'd just be making a straight up computer, wouldn't you. ;-)
    - jroesch 12y ago
      None of these things are relevant in most HDLs implemented as DSLs in high level languages. The point of most of the HDL work in Haskell (for example Lava, and Bluespec) is to provide primitives to talk about hardware and to use a sane language as a way to manipulate them to build larger specifications. It is embarrassing that people use tools that allow you to write un-synthesizable code.
  - marcosdumay 12y ago
    A computer is a much simpler abstraction and much less leaky than a circuit model. Yes, in theory a computer could get a high level description of a circuit, and turn it into a very efficient hardware implementation. In practice our computers are not good enough - the same way they were not good enough for compiling high level languages at the 70's, and people wrote assembly by hand.
  - axman6 12y ago
    From memory, in several HDLs like VHDL and Verilog, a "boolean" value can have up to 8 or so different values (true, false, undefined, hi, lo (different from true and false apparently) plus a few more). My experience with Verilog is that it's very easy to write things which look fine, you can simulate and then fail in hardware; the semantics are just wrong in the languages.