Adrian Sampson5d ago
This blog post is an extended metaphor that serves as an excuse to complain about Verilog. https://www.cs.cornell.edu/~asampson/blog/buildingblocks.html
Back to the Building Blocks’ Building Blocks

Verilog is the foundation of all hardware design, and it is fatally flawed. We should all be worried about a glut of hardware bugs caused by Verilog’s unpredictable semantics and simplistic type system.

Show threadCan Lehmann5d ago

@adrian I feel this. I am currently working on our SystemVerilog Frontend for @verijit and I was surprised how differently you think about Verilog when designing hardware vs when writing a simulator. I mean I knew in theory that Verilog is event driven, but the common subset people actually use does conveniently not run into this much.

I feel like I am actually writing half a synthesis toolchain to make our simulator fast. We gained an entire new intermediate representation for this reason.

Show threadCan Lehmann5d ago

@adrian Honestly, much of this feels like it comes from the idea that you can do verification and design in a single language + the very "I know it when I see it" approach to defining the synthesizable subset.

Essentially it feels a bit like bolting on a half baked imperative/OO language onto an existing HDL. Having separate languages seems like the way forward here.

(I don't have enough experience with embedded DSLs to really have an opinion on that yet)

Show threadTheZoq25d ago
@CanLehmann @adrian Absolutely! And given the popularity of cocotb it seems like the world is moving in a synth/sim language separation already. We just need to make sure that we stop using Verilog as the synth language :D
Show threadCan Lehmann4d ago
@thezoq2 @adrian Cocotb is greeat! While I have many smaller issues with it (performance and its bitvector API are two of them), I think the overall direction is correct.
Show threadTheZoq24d ago

@CanLehmann @adrian Yep, performance is a really big downside to it.

I'm really excited for @ethan's https://github.com/ethanuppal/marlin and need to get around to finishing the Spade support for it. Especially with Verilator's upcoming 4-valued simulation support

GitHub - ethanuppal/marlin: 🦀 No-nonsense hardware testing/simulation in Rust 🛠️ | Verilog, Spade, Veryl

🦀 No-nonsense hardware testing/simulation in Rust 🛠️ | Verilog, Spade, Veryl - ethanuppal/marlin

GitHub
Show threadTheZoq24d ago
@CanLehmann @adrian @ethan Oh wait, I just realized that Spade codegen inherits Verilog's "X is falsy" problem because we inherit Verilog semantics for things like this 
Show threadCan Lehmann

@thezoq2 @adrian @ethan I mean honestly it seems like the solution to that is to auto generate assert ~$isunknown(...) for all conditions. At least that what I will probably do for verijit (probably with a flag because we still need to support the actual behaviour somehow).

I mean in the if(1'bx) thing is a classic refinement issue, i.e. you are simulating one refinement of your model, but the synthesis tool might refine differently.

May 26 at 7:18pmWeb
Show threadTheZoq24d ago

@CanLehmann @adrian Yeah, I guess I'm just annoyed by us potentially falling for a footgun like this and having to deal with it

Though on further reflection I remembered that we compile to ternaries and not if

Show threadKevin Laeufer4d ago
@thezoq2 @CanLehmann @adrian chisel was designed to be two state only. Thus, the original compiler would insert a lot of randomization in order to avoid any X. Now that SiFive is selling the generated SystemVerilog and customers combine it with other designs that have X, all of this has changed a bit.
Show threadKevin Laeufer4d ago
@thezoq2 @CanLehmann @adrian grumble grumble: https://github.com/chipsalliance/rocket-chip/pull/2659
Misc. fixes to make Rocket tolerant to X-propagation by aswaterman · Pull Request #2659 · chipsalliance/rocket-chip

grumble grumble Related issue: Type of change: other enhancement Impact: no functional change Development Phase: implementation Release Notes

GitHub