SUS Lang: The SUS Hardware Description Language

SUS is a new HDL aiming to be a user-friendly alternative to Verilog and VHDL for synchronous hardware design. It simplifies netlist creation while still being compatible with existing synthesis tools. Key features include: * **Latency Counting:** Easier reasoning about timing and pipelining. * **Tinkering-Friendly:** The compiler actively tracks and displays hardware design aspects in the editor. * **Powerful Metaprogramming:** Compile-time code execution enables dynamic generation of hardware structures. * **Intuitive Syntax:** Designed to make hardware design complexity more manageable without imposing paradigms. * **Focused Feature Set:** Supports bounded integers, multi-clock modules, formal verification integration, and syntactic sugar for common tasks like valid signals and resets. * **Explicit Pipeline Design:** Provides an orthogonal "Latency Counting" construct for pipelining and offers abstractions for handshake protocols. SUS prioritizes a direct code-to-netlist mapping, enabling fine-grained control while providing a streamlined development experience.

This Hacker News thread discusses the "SUS" hardware description language (HDL) and the broader state of HDLs and EDA tooling. A key frustration is the difficulty of testbench design and integration in new languages like SUS, particularly when crossing language boundaries with tools like Verilator and Cocotb. Many experienced hardware designers argue that existing HDLs (Verilog, VHDL, SystemVerilog) are "more than fine," and that new languages are not the solution. They believe the real bottleneck lies in EDA tooling and verification capabilities, which are limiting design complexity. Some suggest focusing on improving existing tools rather than creating new languages. The need for an "NXT" (Next Generation Tool) equivalent of "gcc" (GNU Compiler Collection) is also mentioned, highlighting the desire for open-source and performant EDA toolchains. There is mention that languages such as System Verilog can do powerful metaprogramming and that compilers such as Intel's can create more performant / efficient code than compilers such as GCC or Clang.

Why SUS?

The SUS HDL stands out compared to other HDLs like Verilog or VHDL due to its:

⚡

Latency Counting

Timing and pipelining is easier to reason about because the compiler keeps track of them.

🛠️

Made for tinkering

The compiler keeps track of many aspects of your hardware design, and displays them in the editor.

🔒

Full Control

If you can draw your design as synchronous logic, you can represent it in SUS.

💡

Powerful Metaprogramming

SUS allows compile-time code execution to generate LUTs

    module tree_add #(int WIDTH) {
  input int[WIDTH] values;
  output int sum;  if WIDTH == 1 {
    sum = values[0];
  } else {
    gen int HALF_WIDTH = WIDTH / 2;
    tree_add #(WIDTH: HALF_WIDTH) left;
    tree_add #(WIDTH: HALF_WIDTH) right;
    for int i in 0..HALF_WIDTH{
      left.values[i] = values[i];
      right.values[i] = values[i+HALF_WIDTH];
    }
    if WIDTH % 2 == 0 {
      reg sum = left.sum + right.sum;
    } else {
      reg sum = left.sum + right.sum + values[WIDTH - 1];
    }
}

Core Philosophy

The SUS HDL is meant to be a direct competitor to Synthesizeable Verilog and VHDL. Its main goal is to be an intuitive and thin syntax for building netlists, such that traditional synthesis tools can still be used to analyze the resulting hardware. SUS shall impose no paradigm on the hardware designer, such as requiring specific communication protocols or iteration constructs. In other words, SUS is not there to abstract away complexity, but rather to make the inherent complexity of hardware design more manageable.

The one restriction SUS does impose over Verilog and VHDL is that it requires the hardware to be synchronous over one or more clocks. Asynchronous hardware is therefore unrepresentable making SUS less suitable for ASIC development.

Generative Variables and Types: Can be freely combined, sidestepping any "Dependent Types" headaches.
Easy Pipelining: Achieved through an orthogonal construct called "Latency Counting" that doesn't interfere with other features.
Separation of Pipelines: Using interfaces to prevent crossing signals without logical relationship.

A direct 1-to-1 mapping from code to netlist
Hardware domain separation with explicit crossing primitives
A built-in syntax for pipelining that does not impose structural constraints
In-IDE compilation errors & warnings
Metaprogramming for hardware generation

Type safety with Bounded Integers
Multi-Clock modules
Formal Verification Integration
Syntactic sugar for common constructs like valid signals, resets and submodule communication
Moving some timing constraints to the source file

Provide abstractions for handshake protocols (like AXI)
Runtime iteration constructs
Automatic pipelining & retiming

Learn SUS in 40 Minutes

Watch an introductory video covering the basics of the language.