CLaSH: A functional hardware description language
hackage.haskell.org
hackage.haskell.org
http://scholar.google.com/citations?user=zQ49M2sAAAAJ&hl=en http://www.cs.ox.ac.uk/publications/publication3787-abstract...
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.
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.
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.
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.
In my experience, it is quite easy to describing the hardware logic if the architecture is designed well. So, what I mean in "VISIO and Excel are much more important" that the architecture should be concise and cycle accurate. Then verilog coding is just a piece of cake.
It's amazing how Verilog manages to be too low level and too high level at the same time. It's a simulation language not originally intended for synthesis, so it doesn't have access to hardware primitives, and requires you to write specific patterns to ensure they're inferred correctly. But at the same time, it's too low level to even allow you to abstract those patterns.
Also, though figuring out what Verilog to write is not difficult if you've properly thought out the microarchitecture, it can be rather tedious and error-prone to actually write it. I'm not sure how CLaSH works, but Chisel allows you to essentially script generation of hardware using Scala. This removes some of the tedium of writing Verilog and also encourages code reuse (for instance, by allowing you to generate a 32-bit adder and an 8-bit adder using the same code but with different parameters).
Your example of for loops being fragile is actually a good argument for higher level abstractions: maps and folds are much better tools for working with hardware, since they constrain you to a specific hardware layout, and make it clear what's happening.
>Traditionally you first design your module conceptually on a whiteboard (or Excel, Viso, etc.), then implement it in an HDL.
So wouldn't it be nice if the language you used could express the same concepts you use in your higher level diagrams?
Since then, Bluespec has not become too popular, but Haskell has. Clash may have a chance.
I'm also not really convinced by their hardware model (Guarded Atomic Actions). In practice, I've found that it leads to very disjointed flow control, and forbids what seem like intuitive designs.
IIRC European Silicon Structures used to offer it as a part of their toolset when VLSI design was young and hot.
https://en.wikipedia.org/wiki/ELLA_%28programming_language%2...
From a more short-term practical standpoint, no, I don't expect anyone to use this. Hardware engineers are incredibly stubborn when it comes to software. Their work typically involves large time investments with lots of costs and risks. For better or worse, they typically don't ever want to add more risk by using an "untrusted" tool, creating a chicken-and-egg problem.
In the second paragraph, the author admits that there's not yet a good way to represent a recursive algorithm in his language. I think this is more of a proof-of-concept that could eventually become useful.
I don't think these things are at all comparable. The finance industry is writing code to do software things. The hardware industry is writing code to build hardware.
It is not just a matter of how much money and risk is involved, it's a matter of whether the language is a good mapping for the things it is describing.
Also, there is the issue of interfacing with third-party IP blocks or builtin FPGA hardware slices. You either have to stub these out in your high-level description or simulate using the generated HDL.
The field really needs some fresh blood or dare I say "disruption". I'm glad people are trying to make things better.