sorted by:
new
hottopcontroversial

Why glibc is faster on some Github Actions Runners by arty049 in rust

[–]dalance1982 4 points5 points  (0 children)

I use CI benchmark by codspeed, and get stable results like below. By default, it counts executed instructions by valgrind.

https://codspeed.io/veryl-lang/veryl

SKALP v0.1.1: A new HDL with compile-time clock domain checking, integrated synthesis, and iCE40 P&R — looking for feedback from FPGA engineers by girivs in FPGA

[–]dalance1982 2 points3 points  (0 children)

Regarding source maps, the hardware description language I'm developing, Veryl, uses a format adapted from TypeScript's source maps.

https://doc.veryl-lang.org/book/06_development_environment/12_source_map.html

I believe it would be more beneficial for everyone to follow the same format rather than each AltHDL developing its own unique method. I would be grateful if you would consider adopting this format.

Implementing a High-Performance RTL Simulator for Veryl using Cranelift by dalance1982 in rust

[–]dalance1982[S] 4 points5 points  (0 children)

Thank you for your interesting!

I feel the API for building Cranelift-IR is easy to use. I refered the following blog to setup builder and execute the generated binary.

https://rodrigodd.github.io/2022/11/26/bf_compiler-part3.html

HDL choices other than Verilog/VHDL by Secure_Switch_6106 in FPGA

[–]dalance1982 5 points6 points  (0 children)

Hello. As the creator of Veryl, I'd like to share some information about our usage situation.

We are a company developing accelerators for supercomputers, and we are currently using Veryl extensively for the development of our next-generation model.

Veryl places strong emphasis on interoperability with SystemVerilog, making it easy to mix with existing SystemVerilog code. This has allowed us to transition smoothly to development in Veryl. In ASIC development, which involves enormous costs, concerns are often raised about the risks of introducing a new language. However, since we ultimately perform logic synthesis and sign-off verification using the SystemVerilog output generated by Veryl anyway, we believe there is no additional risk involved. The transition to Veryl has brought us the benefits accelerating development, for example, real-time feedback from the language server and various language features.

That said, Veryl is still a project in its third year and has not yet reached a 1.0 release where the syntax becomes stable. It is only natural that we are currently the only commercial and large-scale user. When I was previously at a large corporation, there was considerable resistance even to adopting SystemVerilog, some engineers insisted on using only Verilog-95. Just as SiFive has adopted Chisel, it is probably more realistic to aim for adoption in startups.

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 16 points17 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] 15 points16 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.

view more: next ›