7 ms·

Show HN: Retrocomputing with Clash: Haskell for FPGA Hardware Design

80 points by gergoerdi 5y ago

xupybd 5y ago
I had so much fun a decade ago in University creating a game that ran on an FPGA. We were generating the RGB signals in the FPGA so we only had a little time between screen refreshes for an game logic. It was very challenging but very fun. We made a little scorched earth clone. That game worked amazingly well given the constraints of the system. For anyone wanting to learn these systems I'd highly recommend developing a game as a learning project.
- gergoerdi 5y ago
  In the book (see the sample chapter 8 at https://unsafeperform.io/retroclash/#samples https://unsafeperform.io/retroclash/#samples) we create a proto-almost-game (just a bouncing ball) first by directly wiring together signals. However, the resulting circuit description is much harder to understand and extend than a more structured approach, so we rewrite it in a more principled manner by decomposing it into two parts: a `Input -> State -> State` circuit used as a register transfer enabled by the start of the vblank, and a `State -> Coordinate -> RGB` circuit connected to the video output signal generator. This has the added benefit that we can compile the same description as software Haskell instead of hardware Clash, and so we can use high-level simulation to run the bouncing ball in an SDL window. Sample chapter 9 then creates a Pong game by just changing these two (pure, Haskell) functions slightly. With minimal changes, we go from idle animation to playable game!
exdsq 5y ago
Awesome! You have a customer :)
laydn 5y ago
I am having trouble understanding the usefulness of all these new pseudo-HDL languages. In all the projects that I've worked on, the choice of HDL (which was 95% of the time, Verilog, for the rest, VHDL), was never actually 'important'; the language features were never critical to the completion of the project. Verilog is fully adequate for any kind of serious HDL development. What mattered were, the tooling, IDEs, debuggers, timing analysis tools, verification infrastructure, the IP ecosystem, etc. Perhaps I am getting old but I just can not see how these new languages can be a serious alternative to Verilog/VHDL.
- rowanG077 5y ago
  The same could be said about ASM. You can complete any project with it, the tooling is very good. It will just take much longer and you will have to debug more. In that sense no language ever is important. The point of a language is to allow the developer to write code faster and in a more secure manner. In both of these clash is vastly superior to vhdl or verilog. Imagine a world were we would still be stuck with C because people don't understand the point of improving on it. I think this would have had societal level consequences with what we would have been able to do with computers.
  - laydn 5y ago
    But, HOW do you debug Clash? For example, what is the design and debug flow of using Clash to target a Xilinx FPGA? My guess is that you're going to tell me I will have to debug the generated Verilog code?
    - rowanG077 5y ago
      I've been using Clash for about 2 years now. I just debug the clash code. As in just use the normal Haskell test tooling. The only reason I ever read the generated HDL is when I make sure I have integrated another IP correctly.
      - tubby12345 5y ago
        qq: i know that for HLS sometimes (most?) the generated HDL is 10x the number of resources (flip-flops?) compared to hand-written HDL. how bad is clash in this respect?
        rowanG077 5y ago
        Clash is not HLS. You have full control of register placement and pipelining just like VHDL and Verilog. Clash in that sense is not "higher level" then VHDL or Verilog. In some respects you could even say that Clash is "lower level" because you don't write things just right to be inferred correctly. You actually specify what hardware you want. E.g. you write I want a blockram with this size here, and not if I write this specific Verilog the tools will infer a blockram. What Clash gives you is the power and tooling of Haskell.
qwerty456127 5y ago
By the way, I recently had an idea while taking shower: can there be such a CPU (e.g. FPGA-based) that would support algebraic typing on the hardware level?
gergoerdi 5y ago
Previous discussion on HN about Clash itself: https://news.ycombinator.com/item?id=23096338 https://news.ycombinator.com/item?id=23096338 https://news.ycombinator.com/item?id=9516217 https://news.ycombinator.com/item?id=9516217
tasty_freeze 5y ago
It was an interesting choice to include the Compucolor II emulation. It was a very quirky machine with some interesting design choices, but not very popular. Ops website references https://compucolor.org https://compucolor.org, which I created. I'm glad someone was able to find something useful in it. The site has an in-browser javascript emulation of the Compucolor II. I've written one javascript program in my life, and that emulator is it. It has languished since 2014 other than a bug fix here and there. Eventually I'll refresh the code, and hopefully replace the display generation logic with webgl. The core emulator was quite simple to write, but 90% of the time was spent getting the code to work across browsers and dealing with the infuriating differences in keyboard handling. Maybe things are better now.
- gergoerdi 5y ago
  Your website is of course referenced in the Compucolor II chapter of the book. It was invaluable in getting my Compucolor II implementation working. In fact, I even sent you a PR to fix the TMS 5501 chip's behaviour to match its datasheet (https://github.com/jtbattle/ccemu/pull/2/ https://github.com/jtbattle/ccemu/pull/2/). I chose the Compucolor II for its simplicity. Its original design goal of cheapness via very small number of components translates is a big win for my purposes because implementing many small special-purpose chips would bloat the book considerably, without adding too much extra value. With the Compucolor II, we can just take the Intel 8080 core from an earlier chapter, implement two custom chips, take the UART from another earlier chapter, and boom done. In fact, I chose the Intel 8080 in the first place instead of the more widely used Z80 for the same reason: adding the Z80 extensions wouldn't bring anything new to the table, but would increase cruft. Turns out there's a small but reasonable number of 8080-based home computers (https://retrocomputing.stackexchange.com/q/11682/115 https://retrocomputing.stackexchange.com/q/11682/115).

80 points by gergoerdi 5y ago

I had so much fun a decade ago in University creating a game that ran on an FPGA. We were generating the RGB signals in the FPGA so we only had a little time between screen refreshes for an game logic. It was very challenging but very fun. We made a little scorched earth clone. That game worked amazingly well given the constraints of the system. For anyone wanting to learn these systems I'd highly recommend developing a game as a learning project.

gergoerdi 5y ago
In the book (see the sample chapter 8 at https://unsafeperform.io/retroclash/#samples https://unsafeperform.io/retroclash/#samples) we create a proto-almost-game (just a bouncing ball) first by directly wiring together signals. However, the resulting circuit description is much harder to understand and extend than a more structured approach, so we rewrite it in a more principled manner by decomposing it into two parts: a `Input -> State -> State` circuit used as a register transfer enabled by the start of the vblank, and a `State -> Coordinate -> RGB` circuit connected to the video output signal generator. This has the added benefit that we can compile the same description as software Haskell instead of hardware Clash, and so we can use high-level simulation to run the bouncing ball in an SDL window. Sample chapter 9 then creates a Pong game by just changing these two (pure, Haskell) functions slightly. With minimal changes, we go from idle animation to playable game!

exdsq 5y ago

Awesome! You have a customer :)

laydn 5y ago

I am having trouble understanding the usefulness of all these new pseudo-HDL languages. In all the projects that I've worked on, the choice of HDL (which was 95% of the time, Verilog, for the rest, VHDL), was never actually 'important'; the language features were never critical to the completion of the project. Verilog is fully adequate for any kind of serious HDL development. What mattered were, the tooling, IDEs, debuggers, timing analysis tools, verification infrastructure, the IP ecosystem, etc. Perhaps I am getting old but I just can not see how these new languages can be a serious alternative to Verilog/VHDL.

rowanG077 5y ago
The same could be said about ASM. You can complete any project with it, the tooling is very good. It will just take much longer and you will have to debug more. In that sense no language ever is important. The point of a language is to allow the developer to write code faster and in a more secure manner. In both of these clash is vastly superior to vhdl or verilog. Imagine a world were we would still be stuck with C because people don't understand the point of improving on it. I think this would have had societal level consequences with what we would have been able to do with computers.
- laydn 5y ago
  But, HOW do you debug Clash? For example, what is the design and debug flow of using Clash to target a Xilinx FPGA? My guess is that you're going to tell me I will have to debug the generated Verilog code?
  - rowanG077 5y ago
    I've been using Clash for about 2 years now. I just debug the clash code. As in just use the normal Haskell test tooling. The only reason I ever read the generated HDL is when I make sure I have integrated another IP correctly.
    - tubby12345 5y ago
      qq: i know that for HLS sometimes (most?) the generated HDL is 10x the number of resources (flip-flops?) compared to hand-written HDL. how bad is clash in this respect?
      - rowanG077 5y ago
        Clash is not HLS. You have full control of register placement and pipelining just like VHDL and Verilog. Clash in that sense is not "higher level" then VHDL or Verilog. In some respects you could even say that Clash is "lower level" because you don't write things just right to be inferred correctly. You actually specify what hardware you want. E.g. you write I want a blockram with this size here, and not if I write this specific Verilog the tools will infer a blockram. What Clash gives you is the power and tooling of Haskell.

qwerty456127 5y ago

By the way, I recently had an idea while taking shower: can there be such a CPU (e.g. FPGA-based) that would support algebraic typing on the hardware level?

gergoerdi 5y ago

Previous discussion on HN about Clash itself: https://news.ycombinator.com/item?id=23096338 https://news.ycombinator.com/item?id=23096338 https://news.ycombinator.com/item?id=9516217 https://news.ycombinator.com/item?id=9516217

tasty_freeze 5y ago

It was an interesting choice to include the Compucolor II emulation. It was a very quirky machine with some interesting design choices, but not very popular. Ops website references https://compucolor.org https://compucolor.org, which I created. I'm glad someone was able to find something useful in it. The site has an in-browser javascript emulation of the Compucolor II. I've written one javascript program in my life, and that emulator is it. It has languished since 2014 other than a bug fix here and there. Eventually I'll refresh the code, and hopefully replace the display generation logic with webgl. The core emulator was quite simple to write, but 90% of the time was spent getting the code to work across browsers and dealing with the infuriating differences in keyboard handling. Maybe things are better now.

gergoerdi 5y ago
Your website is of course referenced in the Compucolor II chapter of the book. It was invaluable in getting my Compucolor II implementation working. In fact, I even sent you a PR to fix the TMS 5501 chip's behaviour to match its datasheet (https://github.com/jtbattle/ccemu/pull/2/ https://github.com/jtbattle/ccemu/pull/2/). I chose the Compucolor II for its simplicity. Its original design goal of cheapness via very small number of components translates is a big win for my purposes because implementing many small special-purpose chips would bloat the book considerably, without adding too much extra value. With the Compucolor II, we can just take the Intel 8080 core from an earlier chapter, implement two custom chips, take the UART from another earlier chapter, and boom done. In fact, I chose the Intel 8080 in the first place instead of the more widely used Z80 for the same reason: adding the Z80 extensions wouldn't bring anything new to the table, but would increase cruft. Turns out there's a small but reasonable number of 8080-based home computers (https://retrocomputing.stackexchange.com/q/11682/115 https://retrocomputing.stackexchange.com/q/11682/115).