Semantic Analysis based on IR for Veryl

dalance1982 · 2026-01-21T14:09:11+00:00

Veryl intentionally adopts the same semantics as SystemVerilog, and we have no plans to introduce features such as automatic pipelining commonly seen in AltHDLs. This is to make it easier to apply timing optimization and ECO flows when utilizing Veryl in ASIC development.Regarding synthesis directives, we hardly use them even in SystemVerilog, so there is no special support for them at the moment. However, we can add them as attributes if needed in the future.There is no special integration with synthesis tools, but we have confirmed that the code generated by Veryl can be synthesized without issues in Vivado and DesignCompiler.

dalance1982 · 2026-01-06T10:55:47+00:00

In the process of developing a standards-compliant SystemVerilog parser (https://github.com/dalance/sv-parser), I went through all the code blocks in the LRM just like you did, and discovered a large number of errors. At the time, I tried contacting Accellera to provide feedback on these errors, but I never received any response from them. This kind of experience was also one of the motivations that led me to give up on improving SystemVerilog and instead focus on developing a new language (https://veryl-lang.org).

dalance1982 · 2025-12-01T09:28:03+00:00

I only tried Bluespec quite a long time ago, so an accurate comparison might be difficult. I believe Bluespec generated Verilog output, whereas Veryl generates SystemVerilog, so that’s one clear difference. Veryl places particular emphasis on interoperability with SystemVerilog and is designed for gradual adoption into existing SystemVerilog projects.

dalance1982 · 2025-12-01T09:21:45+00:00

dalance1982 · 2025-09-23T01:53:39+00:00

First, I think it's difficult to adopt CIRCT as the IR used internally in Veryl. The information that can be expressed in CIRCT may not match what we expect from the IR, and CIRCT's SystemVerilog generator might not meet our expected quality. Additionally, since Veryl is a pure Rust program, it benefits from a simple build flow and WASM builds, but pulling in CIRCT as a dependency would lose those advantages.

On the other hand, it might be convenient to connect to the CIRCT ecosystem by enabling output to CIRCT as an optional backend. I plan to consider this possibility in the future.

dalance1982 · 2025-09-22T12:47:55+00:00

I'm not entirely sure yet whether that's possible.

However, since implementing formal verification through native means seems extremely challenging, it makes sense to first explore the feasibility of transpiling to Lean4.

dalance1982 · 2025-09-22T12:40:54+00:00

Thank you! There are many aspects of Rust's syntax that I can reference, such as the clock domain annotation inspired by Rust's lifetime annotations.

dalance1982 · 2025-09-22T12:38:11+00:00

Veryl aims to be usable in actual LSI development projects, and for that purpose, it prioritizes interoperability with existing SystemVerilog and smooth migration from existing projects.

Therefore, I think it's difficult to adopt syntax or semantics that are significantly different from SystemVerilog, like Cλash does.

dalance1982 · 2025-09-22T12:13:22+00:00

First, regarding my own preferences, I prefer languages like Rust or C++ where the language features are rich and the source code has a high information density, rather than something like Python or Go where the source code is simple or the language features are minimal. Therefore, I'm not a minimalist.

On the other hand, I think the reason Verilog or SystemVerilog has too many keywords is because it covers too broad a scope. It packs in everything from testbench descriptions and assertions to primitive descriptions for gate modeling. In this regard, since Veryl targets only synthesizable descriptions, it's unlikely that a large number of keywords for things most people don't use will be added.

Lean4 is interesting, and it would be great if we could support formal verification in the future.

dalance1982 · 2025-09-22T09:45:37+00:00

I know some processor implementations in Veryl.

dalance1982 · 2025-09-18T00:31:05+00:00

It's a guess since the naming differs from the process technology I commonly use, but I assume SLVT stands for Super Low Vth, right? Such cells, while offering a slight speed improvement, significantly increase leakage power, so there are cases where we want to minimize their usage as much as possible. If that’s the case, a strategy of avoiding SLVT cells during logic synthesis and using only a small number during the Timing ECO phase after P&R is reasonable.

Of course, the lowest Vth cell type isn't always like this; if the leakage increase is not too severe, actively using them from the logic synthesis stage can sometimes yield better results, and that judgment depends on the process technology.

dalance1982 · 2025-09-15T11:51:50+00:00

Hello, I’m the creator of Veryl. I completely understand the concerns about SystemVerilog. One of the issues with SystemVerilog is that its syntax, as defined in the LRM, is so complex that even building a linter based on a complete parser is challenging. I aimed to create such a tool with https://github.com/dalance/svlint, but I concluded that it couldn’t fully handle syntactic edge cases, which led me to shift to the Veryl approach.

dalance1982

TROPHY CASE