NEW_HDL.HTML

Ideas about a new HDL

WHY?

The SystemVerilog standard is around 1300 pages. Many features cannot be mapped to hardware and are rejected by hardware synthesis tools. And features that can be mapped, such as if, for, etc., are not controlled by us. It depends on the synthesis tools. Hence, I want to simplify and bring more freedom. This is my elevator pitch to you.

HOW?

Most of the chips come with their own synthesizer. Initially, the new HDL will transpile into a "rigorous" Verilog that can then be synthesized or simulated. Later on, as we gain traction, we will start by supporting chips that already have a good open source ecosystem, such as Lattice, etc.

WHY NOW?

The hardware industry is slowly opening up to outsiders. PCB manufacturing is cheap. Microprocessors and controllers are dirt cheap(RP2350 is a dual-core that can run ARM and RISC-V @ 150MHz, priced at $1.22). Taping out custom ASICS is on the rise(tinytapeout), along with many hobbyist FPGA chips. At the same time, the software industry has tried and tested out so many language ideas. I say we borrow some ideas, simplify the current stack, and save headaches for future engineers.

A small step for a hobby logic designer, but a giant leap for @tinytapeout. The first official RISC-V uLinux ASIC, yes, ASIC, you heard that right, is operational and functional. Just dabbling in chip design as a hobbyist. Haha, what an awesome achievement! Thanx to @matthewvenn… pic.twitter.com/FPcKuEGdFB

— Semiconductor logic destroyer (@splinedrive) July 22, 2024

HMMMMM WHAT DO YOU HAVE IN YOUR MIND?

Here are a couple of ideas that I would like to try out. These ideas may or may not make it into the HDL, so if you don't like(or if you really like) a couple of them, please reach out, and I would love to have a conversation :)
@_smoke_y
grms076@gmail.com

So here are some handwavy ideas
1) Syntax: Verilog is too verbose. There is a reason why most of the new languages don't use "begin" and "end."
2) Type system: Need I say something?
3) Simplify: As I said, many features cannot be synthesized. There should be a clear distinction between statements that can be realized and those that cannot, which will be ignored by the transpiler(in synthesis mode).
4) Programming Language ideas to be stolen: Polymorphism(templates) instead of parameterized modules, compile-time module instantiation to reduce manual work, AST-level macro for better error reporting, standard libraries that implement UART, common state machines(polymorphism allows it to change according to the use case), etc.
5) printf debugging: Sometimes, though the code works in a simulator, it may not work on the silicon. Defining a "printf" module, such as lighting up an LED on board, sending messages through UART, etc, that can be called anywhere to allow debugging on silicon.
6) Macros such as #pipeline, along with a depth for autopipeling, and assert statements that can be associated with a "printf" module for printf debugging.

And a couple more ideas to improve debugging and reduce the gap between simulating and syntesizing.

I was looking for a new project when I came across these 2 posts: 1) why hardware developement is hard
2) pl-troll
I decided to merge my compiler knowledge from my previous project and my okish Verilog skills for this one. I emailed Jonathan Blow, and I got into JAI beta.

This transpiler will be written in JAI.