FPGA world suffers a lot from fragmentation - some tools produce Verilog, some VHDL, some - only subsets of them, creating low-level LLVM-like alternative will help everyone, so HDL implementations will opt only for generating this low-level HDL and routing/synthesizers accept it. LLVM or WebAssembly - you can see how many languages and targets are supported now by both. With more open source tools for FPGA this is more feasible now than ever.

See f4pga/ideas#19

This issue is for bikeshedding keywords.

"def" is introduced as an analog for "wire" in Verilog, albeit more strictly typed (no latches should be inferred when using this). The term "def" for definition is used instead of "let" because we don't lexically scope the variable definition; instead it is referencable by the entire entity.

"def mut" is analogous to "reg" in Verilog, and is meant to draw a similarity to Rust's "mut" declaration. This means that a latch will be generated (if necessary) for the variable, and it can only be assigned using nonblocking "<=" or blocking ":=" operators inside of an on <expr> { ... } block.

"def" for defining a static declaration isn't my favorite; "static" would be nice, but is fairly verbose. "mut" I am more comfortable with, though it means something different in Rust and HDL, since the guarantees by either feel similar.

Initial reset values are convenient but visibly separate from where the values are actually used. I prototyped a reset { } block that would assign initial values from variable declaration, but this mostly seems to make it difficult to track where variables get assigned / easy to miss these initialization blocks. The alternative, having an explicit reset block, is easy to do with just if { ... } statements.

Need some primitive typeck.

We get syntax errors that can't be printed.

In a future version these will become "always" blocks.

With the sequence.hdl example, the _FSM variable in the generated Verilog is never declared, so it defaults to a 1-bit wire. This results in it toggling between two states instead of going through the whole sequence. I added a reg [2:0] _FSM = 0; to the generated Verilog and it behaved as expected.

This would make more sense if "let" is reused as inside of blocks.

Borrowing another idea from VHDL (and Rust), it'd be nice to separate the entity definition from its logic/"architecture".

entity SpiMaster {
  in rst: bit,
  in clk: bit,
  in tx_trigger: bit,
  out tx_ready: bit,
  in tx_byte: bit[8],
  out rx_byte: bit[8],
  out spi_clk: bit,
  out spi_tx: bit,
  in spi_rx: bit,
}

impl SpiMaster {
  ...
}

In addition to separating the entity definition, this could go a step further and allow declarations which implicitly generate our wires:

let spi = SpiMaster {
  rst: rst,
  spi_tx: MOSI,
  spi_rx: MISO,
};

let div_idx: uint{..4} = 0;
on clk.negedge {
    reset rst {
        if div_idx == 3 {
            spi.clk <= !spi.clk;
            div_idx <= 0;
        } else {
            div_idx <= div_idx + 1;
        }
    }
}

The question here is whether we should declare all variables, no variables, just in variables, or something else.

These are markers used in Verilog to force a type of FSM generation. These are needed if we can guarantee we generate the appropriate FSM types, but it may help to have the extra annotation (especially if we can detect when we generate invalid Verilog cases).

See more about this topic: http://www.sunburst-design.com/papers/CummingsSNUG1999Boston_FullParallelCase_rev1_1.pdf

Codegen is a useful feature in any language, and also an obvious footgun.

1. Extract macros into a language-level feature that allows templates to intersperse AST, FSM transitions, data, and more into code. This is the most flexible and hardest to prototype.
2. Allow us to yield to a function, where the function executes and can terminate, but is expanded into FSM generation. This is a more structured approach to the above, but fits a narrow usecase.
3. Require macros be expanded into their own entities and interfaced with. This probably doesn't fit all usecases either.

In an on { } statement.

The current "sequence" blocks are designed to convert sequential code into a state machine. This makes state machines easy to write, but hard to leverage their full expressive power.

A complementary "fsm" block may make it easy to author states:

fsm my_state {
    IDLE => {
        led <= 0;
        if start_condition {
            my_state <= ACTIVE;
        }
    }
    ACTIVE => {
        led <= 1;
        if some_condition {
            my_state <= IDLE; // maybe "next IDLE;" or "fsm <= IDLE;" for anonymous
        }
    }
}

Some questions:

1. Can we elide my_state in most cases?
2. Can we reference my_state outside of the fsm? Can we change (or check) its value from other blocks?
3. Is an explicit my_state <= {value} allowed inside the fsm?
4. How do you declare the initial state; is it just the first state?
5. How does scoping of states work inside of fsm?
6. Can we nest fsms?

Added Verilog literal to compensate, but this still needs to be verified.

Currently, you can specify a unfixed width literal with a leading 0:

115 => 115
0d115 => 115
0b1110011 => 115
0x73 => 115

You can specify a bit width by changing "0" to a different leading number, but this information is currently tossed. This should propagate to the final Verilog stage, as so:

115 => 7'd115
7d115 => 7'd115
7b1110011 => 7'b1110011
7x73 => 7'h73

Notably, even bare variables like 115 should be compiled with a bit width as much as possible, given that Verilog's default assumption of 32 bits is probably incorrect for many intents. When a bit width can't be determined or inferred by types, a compilation error should be thrown.

Recompiling with AST changes takes upwards of 30s on my machine. While the Hoodlum parser is broken out into a sub-crate so this doesn't impact build time usually, it still makes it hard to address and debug AST issues.

This could be addressed by switching to another parser, or taking steps to reduce the amount of code that is involved in the AST step.

For example,

fsm(one-hot) { ... }
fsm(index/binary) { ... }
fsm(gray) { ... }
fsm(one-cold) { ... }

This could be extended to sequences naturally.

This will allow the ethernet.hdl hack naming __FSM_1 to be removed.

e.g.

let a = b | c;

Both Verilog and VHDL support named instance port assignment.
I understand that Hoodlum tries to stick to Rust syntax as much as possible,
but HDL modules can have a very large number of ports.
It is simply impossible to maintain such code with positional port assignment only.

Testing and verification is the part of Verilog I'm weakest at. What should it look like if it were redesigned and implemented in Hoodlum?

These need tests to show that the max_value calculation is correct by testing all edge cases.

These are redundant and can just be top-level.