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 threadTheZoq2
@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
May 26 at 7:06pmTusky
Show threadCan Lehmann5d 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 threadTheZoq25d 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 threadTheZoq25d 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 Lehmann5d ago

@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.

Show threadTheZoq25d 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 Laeufer5d 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 Laeufer5d 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
Show threadCan Lehmann5d ago
@ethan @thezoq2 @adrian To what extent is marlin testbench language agnostic? It seems like currently it is rust only, but what would be the overhead associated with having C++ bindings?
Show threadTheZoq25d ago
@CanLehmann @ethan @adrian Oh, Marlin is a simulator agnostic testbench library if you distill it. Currently, Verilator is the only backend so C++ bindings for Marlin would just be Verilator test benches :D
Show threadEthan5d ago
@thezoq2 @CanLehmann @adrian and cxxrtl which i am also working on supporting is C++ too. the only cases i can think of where C++ support wouldn't come for free as a result of me needing to generate C ffi (and so there is already a C interface) would be a rust simulator like veryl's new one
Show threadCan Lehmann5d ago

@thezoq2 @ethan @adrian Ok, that makes sense. So it seems like this would mostly be interesting once there is

a) handling of more complex data types from the HDL
b) simulators other than verilator

Show threadTheZoq25d ago

@CanLehmann @ethan @adrian

For me with Spade, the complex data types from the HDL is the big selling point of Marlin.

But I also am not sure if C++ is a particularly good choice for a testbench language, so even if I was writing Verilog I think i'd prefer Rust over C++ or taking the performance hit from Cocotb

Show threadCan Lehmann5d ago
@thezoq2 @ethan @adrian In the end it comes down to personal preference I think. The big advantage you have with C++ is its popularity in the embedded space: Since people are familiar with it, using it to implement a testbench has a lower barrier to entry. I realize increasingly many people also adopt Rust, though I am not sure where the actual adoption in industry is.
Show threadTheZoq25d ago

@CanLehmann @ethan @adrian Oh yeah, Rust certainly doesn't have the market share of C++ yet.

But with that argument, we should also use Verilog :P

Show threadCan Lehmann5d ago

@thezoq2 @ethan @adrian Oh yeah sure 🤣

Though I think in this aspirational world, Rust wouldn't be it either for me. I realize that I am going to make myself a bit unpopular in this thread by saying this, but I love C++ for how I can quickly bend it to do whatever I want. The safety vs. extra effort tradeoff has not made sense for me, since most of the bugs I actually sped time debugging are logic issues somewhere in some compiler pass, not memory issues.

Show threadTheZoq25d ago

@CanLehmann @ethan @adrian

Oh yeah, C++ certainly wouldn't be my last choice for a language, I love the fact that if I want to do something, there is almost certainly a way to do it, albeit a hacky one.

The reason I like Rust so much is that it brings a lot of that, but with more type safety and less footguns

Show threadCan Lehmann5d ago
@thezoq2 I think Swift has come closest for me personally, but I never got to use it as much as I would like to. Also especially if you want to interface with LLVM using a non C++ language is extremely annoying. So maybe the answer is "a secret third thing" 😅 or idk something like -fbounds-safety + praying that by using arenas and refcounting nothing breaks to badly 🤣
Show threadTheZoq25d ago

@CanLehmann I do need to try swift at some point, from what I hear it has some really good ideas.

And for what it's worth, I've often said that if I had to remove any feature from Rust, it'd be memory safety. I think you're right that logic bugs are more interesting generally, and the rest of the Rust type system does a very good job of catching those in my experience

Show threadCan Lehmann5d ago
@thezoq2 Oh thats an interesting take, which I don't think I've heard before. Isn't memory safety the reason why people use Rust in the first place?
Show threadTheZoq25d ago

@CanLehmann For me, memory safety is the thing that brought me to the language, but I'm staying for the functional inspired type system and top tier tooling. I assume I'm not alone in that

I guess it also depends on the context, I use it as a fast high level language for compilers, if I was doing more systems programming I'd care a lot more about memory safety

Show threadCan Lehmann5d ago
@thezoq2 Interesting! I mean I certainly wouldn't mind having a better type system in C++. Especially proper tagged unions which do not have std::variant's ugly interface would be great.
Show threadTheZoq25d ago
@CanLehmann Ah yes, tagged unions are one of the main things I miss in C++, and not having them in Verilog was a big reason to start Spade :D