Ops website references 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.
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).
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.
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.
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?
> 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
Because both are equally bad, and have little meaningful difference in their features.
> Verilog is fully adequate for any kind of serious HDL development.
This confirms my past experience of interacting with hardware people. They have extremely low standard for their programming languages and tooling in general, and don't like reflecting on these too much. They just suck it up and do the job, no matter what.
My Verilog just quietly accepts the code which assigns values to a wire which is declared as input? I guess it's my fault, I will just be more careful in the future not to do that again.
My Verilog doesn't allow parametrizing modules with anything other than natural numbers? Well, I'll just duplicate code, that's how we always did it.
My Verilog has no types other than "wire" and "array of wires" (and also allows assigning array[2][3] to array[3][2] emitting no warning)? It's fine, I will just try to keep in mind what data I have in which wires and try to make sure I never mix things up.
My Verilog uses pseudo-imperative code with "assignments" in it to describe a network of flipflops with combinational logic between them? It's ok, I will just train my brain to convert between the two even though there's no good reason for Verilog to be like that.
My Verilog has constructions which are synthesizable only when used in one very specific way, instead of clearly differentiating between synthesizable (actual hardware) and un-synthesizable (imperative testing code)? It's ok, I will just remember the details.
My Verilog produces so much noise in the build logs that nobody actually reads it unless something breaks? I guess I just have to be more careful or write more testbenches.
> I just can not see how these new languages can be a serious alternative to Verilog/VHDL
This is learned helplessness.
Clash has better, more natural abstractions for the wires and flipflops. Combinational and sequential logic are clearly separated. It also uses many primitives of Haskell which make your code more compact, easier to read and verify. You can parameterize modules with anything, including other modules, this drastically reduces code duplication and lets you manage the code on a higher level (while still seeing how does it correspond to bits and wires).
It's not impossible, but it is an incredibly big chicken and egg problem where most of the pieces are out of your control - the best you can do is to make highly efficient (ie synthesises well, simulates well) verilog or vhdl and hope enough people start using your tooling that the big vendors choose to implement your language as a target.
(oh and My (system)Verilog has far more types than just wire, is accepted by the big guy's tooling and generate allows me to avoid almost all copying)
When I am close to tapeout and I am moving a single gate across a flip flop in order to extract the final few Mhz out of the design, and my formal equivalence checker only understands Verilog, I will have to use Verilog.
I suppose my benchmark in assessing the capabilities of this -or any- language and its ecosystem is the following : Can you use Clash in the design of a reasonably complex chip from scratch (HDL to tapeout)?
https://news.ycombinator.com/item?id=23096338 https://news.ycombinator.com/item?id=9516217
For anyone wanting to learn these systems I'd highly recommend developing a game as a learning project.
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!
