Hacker News Reader

Comment by dalance | Hacker News Reader

Hi, Im' developer of Veryl. So I'll try to write the answer to "why new HDL?".

I use SystemVerilog from 10+ years ago, and developed many large ASICs. But development environment of SystemVerilog was poor than software development. So I wrote some SystemVerilog tools to improve the environment like below: https://github.com/dalance/svlint

After writing it, I felt that more improvement is difficult because the specification of SystemVerilog is too complicated. (For example, even commercial EDA tool vendors can't cover all specification...)

Therefore I decided to develop a new language replacing SystemVerilog. I focus that the new language can be used by production ASIC development. I'm plan to develop a part of a new project in my company by using Veryl.

View on HN

I probably don't have nearly as much experience as you do, but I have used VHDL, Verilog, and modern HDLs like Chisel and SpinalHDL. I think the main advantage of a modern HDL is to have the full power of a traditional programming language when it comes to generating hardware. This especially helps when making deeply parameterizable and reusable hardware in a fraction of the lines compared to SystemVerilog, and which sometimes is impossible to do in Verilog.

From a first impression, your language doesn't look all that different from SystemVerilog. Does it have any features that make parameterization easier than SystemVerilog? Can I, for example, easily generate hardware using higher order functions and other functional programming features like those available in Rust and Scala?

I plan to introduce generics to enable module/interface/package as type parameter. But I'm not aiming Chisel like programability.

I tried to use Chisel in a large codebase to judge it can be used as SystemVerilog alternative in my company. So I found many problems which causes difficulty to apply ASIC development flow. I think that differences of semantics from SystemVerilog causes a part of these problems.

So I aim that Veryl has the almost same semantics as SystemVerilog. I think this ease to interoperate with SystemVerilog codebase too.

Powerful generative capabilities aren't always as useful as you might think. There's two major issues:

1. Verification - You can verify one particular part of the configuration space but verifying the full generic component is something else entirely. As far as I'm aware there's no new HDL which seriously tries to address this point.

2. Implementation - If you're generating something sufficiently advanced you likely want different micro-architecture for different configurations to reach the most optimum design (in terms of power, timing and area). As an example, take a CPU, a single, dual and triple issue core will need to be designed in very different ways. You could aim to build something which can generate all of these wrapped up as a nice CPU module with an 'IssueWidth' parameter but that's going to be harder than just writing separate 1, 2 and 3 issue width CPUs.

Certainly for more mechanical things like interconnects, interrupt controllers, pin multiplexers etc yes it can work well. However building those things in System Verilog is often done with separate generator programs anyway and overall doesn't consume much of the total project engineering time, it's just tedious work.

It does seem a lot of new HDLs focus on eradicating the annoyances and tedium you get developing with System Verilog but increase the difficulties you get in point 1 and 2 which are the actual hard bits that take up the bulk of the time.

Early days for Veryl but it's taking a different direction for most (i.e. just building a more sane System Verilog) I shall be watching with interest!

I agree both issues. I experienced the whole design became to be broken by adding a trait in my Chisel work. When I want to change a timing path related a register, Chisel-ish sophisticated descriptions could't be used.

I think SystemVerilog has sufficient function for ASIC development. So I think more efficient development can be achieved if there are modern development tools like real-time semantic checker through language server, build tool handling dependencies, and so on.

> because the specification of SystemVerilog is too complicated

Right, too big and complicated, too much stuff to decently cover in one language (more than e.g. Ada covers), and the majority of people use only a fraction of it (different identifiable user groups use different subsets).

Do you try to add the full SV feature set in your language, or do you focus on a user group/use-case?

I'm focusing ASIC designers who write synthesizable SystemVerilog. So I choose language features to avoid mismatch between synthesis and simulation. Verification engineers is a second group. But verification features like SVA and UVM are too large. So I think it may be better to achieve these features by interoperation with SystemVerilog instead of adding them to Veryl.

I appreciated e.g. in Wirth's Lola-2 HDL that it was conceived up-front for synchronous design and you didn't waste hours to explain to people how to select the proper subset of the language for the most prevalent use-case. Concerning verification, I assume more and more people use other languages for verification than SV, e.g. Python or C++.

Thank you for your information about Lola-2 HDL. I'll check it.

As a verification engineer, I write large verification models by Rust, and connect them to SV testbench through DPI. The same usage can be done by Veryl. About Python, cocotb integration seems to be good for integrated unit test feature. So I've just started to consider about the idea.

Reply on news.ycombinator.com