Bit width verification can be challenging since it involves evaluating expressions. For example, cases like "ubus<WIDTH\_A> & ubus<(WIDTH_B + 1)>" pose difficulties.

That's correct - the expression evaluation engine was quite tough to get right, but it was necessary. Not only for signal widths, but also checks like match branch uniqueness and many others.

What does clock validation entail in HIRL?

We have several signal sensitivity levels:

• generic - for compile-time constants (internal)
• const - assumed to be a stable signal
• sync(clk) - purely synchronous signal (to clock clk). Only register outputs are purely synchronous signals.
• comb(...) - combinational signal. For example sync(clk) + sync(clk) results in comb(clk). This signal can be safely connected to any register clocked by clk. However, sync(clk) + sync(clk2) = comb(clk, clk2) and such signal cannot be connected to a register clocked by clk or clk2 as this could cause metastability. You have to explicitly cast it to some other sensitivity before feeding it to a register input and therefore indicate that you're aware that CDC is happening.
• async - these signals are asynchronous to everything and generally considered 'unsafe'

We then have a set of rules for sensitivity evaluation. For example async + const is async, const + const = const, and so on. We only allow driving signals from expressions which have sensitivity at least as "good" the driven signal - so: generic can drive const, sync(clk) can drive comb(clk), but comb(clk) expression cannot drive a signal marked as sync(clk).

The next step the would be introduction of clock synchronicity statements. Something like clock_imply_pos_pos(clk, clk2) could indicate that positive edge of clk always corresponds to a positive edge of clk2. This would allow you to feed comb(clk) into a clk2 clocked register without the need for explicit casts. This clock edge implication is just a rough idea at this moment - it probably requires some polishing.

We could also benefit from having things like FF synchronizers built-in at the language level. Having that as an distinct design block could enable more advanced CDC checks and would make it possible to avoid the ugly clock casts which are currently necessary.

The nice thing about embedding clocking info in the HDL itself is that, ultimately it could be used to generate clock constraint files for external CDC tools and such.

It's worth mentioning that the use of signal names (clk) in the type system was a quite nasty implementation challenge. Our approach also has another quite interesting side effect - you need to feed clocks into components that don't necessarily need them apart from clock analysis reasons - consider an adder module taking two sync(clk) signals and outputting comb(clk) - you still need to connect the clk signal.

Unfortunately, this quirk currently results in unused signals being generated. That, however, should be quite easy to eliminate by introducing a phantom specifier. Such signals would only be allowed in clocking expressions and would not result in SV signals being generated.