[seanmclo]

I've been looking for an alternative hardware description language to Verilog/SystemVerilog because they're not very readable languages. But after skimming this source code, my initial thought is that I hope Haskell doesn't take off. This is extremely difficult to read.

Maybe I just don't know Haskell well enough, though.

[aseipp]

It's give and take. I've been writing Haskell for a long time, and I think just reading slowly is a big help in general when dealing with any Haskell code not written by me. This is true for everything but I find it especially true here. There are stylistic choices concerning the code base that some people would quibble over (please nobody start a flame war over 'lens' thank you) that make it a little more opaque to non-Haskell users though, I think. Like, I wouldn't blame anyone for thinking:

    scribe toMem . First . Just . InstrMem =<< dePC <<~ use fetchPC

just doesn't read very well if they don't know it Haskell, though I admit it's perfectly readable and understandable to me, and I think could be explained to a novice with a little help.

If you want an alternative to SystemVerilog, another alternative is Bluespec. It's higher level than SV, but much more productive and easier to get right, too. (Incidentally, Bluespec is also a kind of Haskell, but it has two different kinds of syntax, one inspired by Haskell, and one inspired by SystemVerilog...)

[marcosdumay]

That line does make me wish for an IDE that automatically display parenthesis around the operators that aren't (.) or ($)...

But I remember that the precedence of lenses compared to binding operators is really important. It's just that I didn't write any lenses for a long time.

[tome]

I know Haskell well and I hate to read code like that!

[jeff_ciesielski]

(From someone who is working on a rv32im implementation in Clash)

I really love writing RTL in haskell when compared to verilog/vhdl, but as a language I think it suffers from the same thing a lot of other languages do: too many ways to do the same thing. Mix that with a language that encourages meta-programming and you've got yourself a recipe for every complex haskell project basically becoming it's own little DSL. It's also often made worse because so much haskell is written by type-theorists and mathematicians churning out symbol-soup without a thought for the rest of us plebs.

IMO this is actually pretty readable and the implementation is stitched together nicely. There are some haskell/ml-isms like lenses/monad transformers/partial functions sprinkled in there that complicate a casual read-through, but if you've got a grasp on those most of this is reasonably clear.

It isn't the most complex beast (as others have pointed out, it skips things like the Zicsr and M extensions which add significant complexity) but it could serve very well as say, a companion core to some more complex piece of hardware. Perhaps one that requires reconfigurable logic that would be impractical in silicon but doesn't require realtime interrupts or fast math?

[MrRadar]

Robert Baruch on Youtube is building a RISC-V CPU core of comparable complexity to the one in the OP using nMigen which is an HDL based on Python and it looks like a very nice tool to work with relative to other HDLs I've seen (though I've never had to actually use an HDL myself before so I may not be the best judge). Here's a playlist of the video series, with the earlier videos basically being an introduction to nMigen: https://www.youtube.com/watch?v=YgXJf8c5PLo&list=PLEeZWGE3Pw... He's got another series that's focused more on the HDL itself building a (relatively much simpler) 6800 CPU core: https://www.youtube.com/watch?v=85ZCTuekjGA&list=PLEeZWGE3Pw...

[GregarianChild]

The RISC-V ecosystem is quite fond of Chisel [1]. A new kid on the block is LLHD [2]. There are numerous others.

[1] https://github.com/lowRISC/chisel

[2] https://llhd.io/

[gpanders]

I want Chisel to succeed so badly. I'm so sick and tired of writing VHDL. Verilog is no better.

Also it looks like LLHD is perhaps analogous to LLVM in that they offer an intermediate representation instead of providing a language that you code in yourself. Chisel also offers this via FIRRTL [1]. I can't decide whether to be excited about the fact that there are multiple ideas in this space or frustrated that these disparate teams aren't simply collaborating.

[1]: https://github.com/chipsalliance/firrtl

[spamizbad]

You should look into Bluespec.https://en.wikipedia.org/wiki/Bluespec

[sitkack]

*much delayed*

When two technology vectors merge, it is really nice when the product is simpler and purer rather than the simple union of the two becoming a Simpson's-esque swiss army knife.

It can be dangerous when two similar ideas are too close, for whatever reason they formed to begin with will continue to hold and now you have competing factions along with the problem you are trying to solve. Everyone has to agree before you can start using regexps in your codebase. Oddly specific but true.

I am going to say hold your papers, but this problem is not going to be solved just yet, but in two or three iterations, it will be amazing. It won't just be a hardware description language, that is much too narrow, and it will arrived at in a kind of Erlang way, discovered through necessity, not from a formal system. But who knows?!

I do think that folks should adopt some sort of language above VHDL/Verilog.

[GregarianChild]

There is a lot of resistance to dropping Verilog among working processor designers in my experience. Interestingly, LLHD is being folded into CIRCT [1] which is part of LLVM.

[1] https://github.com/circt

[sitkack]

I am trying to come to grips with this, this looks like this sets up the condition where the whole language compiler stack can change the target architecture and implementation.

This feels like some powerful algebraic property has been satisfied.

https://en.wikipedia.org/wiki/Popek_and_Goldberg_virtualizat...

[UncleOxidant]

After playing with some of the alternative HDLs (and even trying to make my own at one point) I've come back to just coding the design in VHDL (which I prefer over Verilog/SystemVerilog, YMMV) and using cocotb (https://github.com/cocotb/cocotb) for creating testbenches. I think in a lot of cases effective use of VHDL generate statements can do a lot of the things these alternative HDLs are trying to do anyway. The alternative HDLs try to shoehorn HDL semantics (everything happens in parallel) into languages that are serial and it ends up being awkward and not any easier to read.

Get comfortable with an HDL. Use something like cocotb to generate testbenches.

[chrsw]

I feel like I'm a similar boat as you. I came into the ASIC world from the EE side of things: digital design, VLSI layout and traditional HDLs. I never learned functional programming so the entire paradigm of FP is opaque to me. Verilog and VHDL have their problems but at least I can get somewhere with them. It's up to me to learn these new HDL technologies because it appears this is where the industry is headed. I think starting with programming language theory and going from there will help with getting my head around technologies like Chisel and Clash.

[a1369209993]

> But after skimming this source code, my initial thought is that I hope Haskell doesn't take off. This is extremely difficult to read.

> Maybe I just don't know Haskell well enough, though.

Speaking as someone who knows Haskell fairly well (and likes it), and has used Verilog at least a bit, I agree - it looks like they took all the worst parts of Verilog (especially the procedural parts), translated them into Haskell, and abandoned the occasional redeeming qualities.

(I suspect it's possible to shoehorn a decent (though not great) HDL into a Haskell DSL, but I've yet to see it actually done.)

[jand]

I while back i came across SystemC [1]. Have a look, even if C++ might be perceived as a joke in a thread about formally verified RISC-V.

[1] https://en.wikipedia.org/wiki/SystemC

[UncleOxidant]

You're going to have a hard time synthesizing SystemC. Yes, there are tools available, but they cost a lot of $$$. And then there are the error messages you get from SystemC - if you like sifting through pages of C++ template error messages to find your mistake, you'll love SystemC.

[mhh__]

Bluespec is Haskell underneath SystemVerilog on top and it seems quite nice.

It's open source as of about a year ago

[phkahler]

Have you looked at chisel? Or whatever it is the BROOM core is written in.