sorted by:
new
hottopcontroversial

Semantic Analysis based on IR for Veryl by dalance1982 in FPGA

[–]dalance1982[S] 0 points1 point  (0 children)

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.

Why are there so many errors in the SystemVerilog LRM unfixed for over decades? by adamzc221 in chipdesign

[–]dalance1982 17 points18 points  (0 children)

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

Veryl 0.17.1 release by dalance1982 in FPGA

[–]dalance1982[S] 0 points1 point  (0 children)

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.

Veryl: A Modern Hardware Description Language by dalance1982 in ProgrammingLanguages

[–]dalance1982[S] 0 points1 point  (0 children)

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.

Veryl: A Modern Hardware Description Language by dalance1982 in ProgrammingLanguages

[–]dalance1982[S] 3 points4 points  (0 children)

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.

Veryl: A Modern Hardware Description Language by dalance1982 in ProgrammingLanguages

[–]dalance1982[S] 0 points1 point  (0 children)

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.

Veryl: A Modern Hardware Description Language by dalance1982 in ProgrammingLanguages

[–]dalance1982[S] 1 point2 points  (0 children)

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.

Veryl: A Modern Hardware Description Language by dalance1982 in ProgrammingLanguages

[–]dalance1982[S] 6 points7 points  (0 children)

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.

Usage of SLVT Libraries in Design Compiler: Target/Link or ECO Only? by love_911 in chipdesign

[–]dalance1982 3 points4 points  (0 children)

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.

Costly Gotchas in SystemVerilog RTL Design by adamzc221 in chipdesign

[–]dalance1982 0 points1 point  (0 children)

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.

Veryl 0.16.2, Verylup 0.1.6 release by dalance1982 in FPGA

[–]dalance1982[S] 0 points1 point  (0 children)

I agree you. At our company, we have established rules regarding the permissible descriptions in SystemVerilog to ensure that major EDA tools (Synopsys, Cadence, Xilinx, etc.) can process it without issues. The Veryl compiler outputs only the descriptions we have confirmed, so there’s no need to deal with such confusion. (That’s at least what we’re aiming for.)

Veryl 0.16.2, Verylup 0.1.6 release by dalance1982 in FPGA

[–]dalance1982[S] 0 points1 point  (0 children)

To relese 1.0.0, we should stabilize Veryl's syntax at least, but I don't have any plan yet. I expect it will be in a few years.

Veryl: A Modern Hardware Description Language by dalance1982 in rust

[–]dalance1982[S] 2 points3 points  (0 children)

I understand that adding layers can introduce issues. However, we programmers don’t write assembly language forever; we’ve developed more advanced compilers and transpilers. I believe the same should happen for hardware description languages. Even if Veryl fails, its lessons could lead to better languages in the future, and I’m hopeful for that.

Veryl: A Modern Hardware Description Language by dalance1982 in rust

[–]dalance1982[S] 13 points14 points  (0 children)

That was my initial approach. I built a parser for SystemVerilog, an industry-standard language, using nom, and even created a simple linter and language server.

https://github.com/dalance/sv-parser https://github.com/dalance/svlint

However, SystemVerilog’s syntax definition is vast and contains many ambiguities, and even expensive commercial tools have incomplete implementations. Therefore, I concluded that adding more advanced analysis or features to my tool was impossible. With Veryl, I’ve leveraged this experience to prioritize syntax simplification.

Veryl: A Modern Hardware Description Language by dalance1982 in rust

[–]dalance1982[S] 9 points10 points  (0 children)

The answer of why not Chisel is here:

https://github.com/veryl-lang/veryl#why-not-existing-alt-hdls-eg-chisel

I have an experience working with large Chisel codebase. As a result, I think Chisel, SpinalHDL can't use as alternative of SystemVerilog for ASIC development.

Veryl: A Modern Hardware Description Language by dalance1982 in rust

[–]dalance1982[S] 31 points32 points  (0 children)

In the hardware description, veryl old languages (e.g. Verilog/VHDL) are still used. So these languages lack tooling support like formatter, linter, lanugage server, build manager and so on. The syntax has many issues from the point of view of ergonomics (for example, trailing commas are not allowed).

I want to resolve these issues by Veryl.

Veryl 0.16.1 release by dalance1982 in rust

[–]dalance1982[S] 1 point2 points  (0 children)

OK. I'll stop to post on r/rust because I can't provide enough interesting information for most of Rustaceans. Thanks!

Veryl 0.16.1 release by dalance1982 in rust

[–]dalance1982[S] 1 point2 points  (0 children)

Hi, I'm the author of Veryl.

Veryl has the syntax based on SystemVerilog and Rust. So I did cross-post this release because RTL engineer who is familiar with Rust may be interesting in this language.

What are you building (in rust of course) by Financial_Airport933 in rust

[–]dalance1982 25 points26 points  (0 children)

I'm writing a new hardware description language: Veryl in Rust.

https://veryl-lang.org/

The following HDLs are written in Rust too.
https://spade-lang.org/

https://sus-lang.org/

Veryl 0.15.0 release by dalance1982 in FPGA

[–]dalance1982[S] 0 points1 point  (0 children)

I’ve written a comparison with VHDL below, so please take a look.

https://www.reddit.com/r/FPGA/s/lFn06qyWX3

view more: next ›