Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Chisel: A Modern Hardware Design Language

github.com

Post reply on HN
Print view View original

51–60 of 78 posts

Re: Chisel: A Modern Hardware Design Language

#51

Post by IshKebab »

gchadwick wrote: post #10

I've said as much before but I find the issue with alternative HDLs Vs SystemVerilog is they concentrate on fixing annoying and frustrating things but don't address the really hard issues in hardware design and can actually make them harder. For example SystemVerilog has no real typing which sucks, so a typical thing to do is to build a massively improved type system for a new HDL. However in my experience good use o…

> However in my experience good use of verilog style guides and decent linting tools solves most of the problem. You do still get bugs caused by missed typing issues but they're usually quickly caught by simple tests.

Decent linting tools are really expensive. And even it verif does catch all these simple typing mistakes, they still cost a huge amount of time!

I think the real issue with most of these "compile to Verilog" tools is that all the vendor tools work with SystemVerilog, and now you're debugging autogenerated code, which sucks.

Another huge issue is formal verification. The tools only understand SVA so you basically have to be using SystemVerilog.

> I think my ideal HDL at this point is a stripped down SystemVerilog with a good type system, better generative capability that crucially produces plain system verilog that's human readable (maintaining comments, signal and module names and module hierarchy as much as possible).

I 100% agree here. There's a gazillion things you could fix in SystemVerilog and still have something that compiles to something similar enough that it's easy to debug. Kiiind of like Typescript for SystemVerilog. I wonder if anyone is working on that.

Re: Chisel: A Modern Hardware Design Language

#52

Post by mikeurbach »

gchadwick wrote: post #47
mikeurbach wrote: post #27

Earlier quoted context omitted.

Disclaimer: I work on Chisel and CIRCT, and these opinions are my own. These are good points, and I think Chisel is actually improving in these areas recently. Chisel is now built on top of the CIRCT[1] compiler infrastructure, which uses MLIR[2] and allows capturing much more information than just RTL in the intermediate representations of the design. This has several benefits. Regarding the problem of converting fr…

Thanks for the info these all certainly sound like promising developments though I still think there's a major hurdles to overcome. > good PPA with popular backend tools Getting good PPA for any given thing you can express in the language is only part of the problem. The other aspect is how easy does the language make it to express the thing you need to get the best PPA (discussed in example below)? > Think of it lik…

> To get to this fix you have two things to deal with, first taking the identified timing path and choosing a sensible point to target for optimization and second actually being able to do the optimization.

> Because of SystemVerilog's lack of powerful abstractions making a tweak to get the read mux to use the earlier signal was easy to do but how does that work when you've got more powerful abstractions that deal with all the muxing for you in cases like this and the tool is producing the mux select signal for you.

Thanks for the example and illustrating a real world change. In this specific case, Chisel provides several kinds of Mux primitives[1], which CIRCT tries to emit in the form you'd expect, and I think Chisel/CIRCT would admit a similarly simple solution.

That said, there are other pain points here where Chisel's higher-level abstractions make it hard to get the gates you want, or make a simple change when you know how you want the gates to be different. A complaint we hear from users is the lack of a direct way to express complex logic in enable signals to flops. Definitely something we can improve, and the result will probably be new primitive constructs in Chisel that are lower-level and map more directly to the System Verilog backend tools expect. This is one example of what I was alluding to in my previous reply about new primitives in Chisel.

> Your example here certainly sounds useful but to me at least falls into the bucket of annoying and tedious tasks that won't radically alter how you design nor the final quality and speed of development.

I guess it depends on your goals. I spoke[2] about CIRCT and the new features in this realm at Latch-Up 2023, and after the talk people from different companies seemed very excited about this. For example, someone from a large semiconductor company was complaining about how brittle it is to maintain all their physical constraints when RTL changes.

> Maybe I should make one of my new year's resolution to finally get around to looking at Chisel and CIRCT more deeply!

We'd love to hear any feedback!

> Could even have a crack at toy HDL in the form of the fixed SystemVerilog with a decent type system solution I proposed above using CIRCT as an IR...

That's exactly what the CIRCT community is hoping to foster. If you're serious about diving in, I'd recommend swinging by a CIRCT open design meeting. The link is at the top of the CIRCT webpage. These can be very informal, and we love to hear from people interested in using CIRCT to push hardware description forward.

[1] https://www.chisel-lang.org/docs/explanations/muxes-and-inpu...

[2] https://www.youtube.com/watch?v=w_W0_Z3n9PA

Re: Chisel: A Modern Hardware Design Language

#53

Post by IshKebab »

glitchc wrote: post #21
programjames wrote: post #9

One thing I really like about Verilog is explicit register widths. I want to be able to work at the individual bit level, something that Python (and even C) are not very good at. Is Chisel decent for efficiency?

C is excellent at bit-banging, miles better than Python.

Actually for that Python is better than C due to its support for arbitrary precision integers. One of the few things Python got really right.

It's way slower of course.

Re: Chisel: A Modern Hardware Design Language

#54

Post by duped »

BooneJS wrote: post #45

These languages are fun. "Look ma, no verilog!" But the underlying problem with all of these DSLs is the fact that the EDA[0] industry interoperates on verilog. Period. Worse, at some point in the design cycle, post-synthesized gate-level verilog becomes the codebase. No upstream verilog changes are allowed because it can be difficult to get a precise edit (e.g. 2-input NAND into a 2-input AOI by changing a verilog f…

Chisel isn't some toy, it's actually used in industry. IIRC SiFive's portfolio is built on it.

Re: Chisel: A Modern Hardware Design Language

#55

Post by sweden »

phkahler wrote: post #48
BooneJS wrote: post #45

These languages are fun. "Look ma, no verilog!" But the underlying problem with all of these DSLs is the fact that the EDA[0] industry interoperates on verilog. Period. Worse, at some point in the design cycle, post-synthesized gate-level verilog becomes the codebase. No upstream verilog changes are allowed because it can be difficult to get a precise edit (e.g. 2-input NAND into a 2-input AOI by changing a verilog f…

Your stance seems well founded and very compelling. As an outsider to chip design ima play devils advocate and ask, what if the higher level tools reduce overall design time and eliminate a lot of those errors you end up patching in the metal layers? I fought the same battle with auto-generated C from simulink models, and really don't think that's the way to do much for production. But thats because the tool isn't go…

The OP makes an interesting point but it doesn't point out the main problem with high level hardware languages: these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality. The problem is that you will end up with a hardware that is less optimized than if you were to design it in Verilog.

I work at a very big semiconductor company and we did some trials with implementing the exact same hardware we had in Verilog but on an high level HDL and while development could be faster, we ended up with worse PPA (Power, Performance and Area). If you try to improve this PPA, you just end up bypassing the advantages of high level HDLs.

On top of that, it raises a lot of questions on verification: are you going to do verification (testbenches) in the Chisel code or in the generated Verilog code from Chisel? If you do it in Chisel, how do you prove that Chisel didn't introduce bugs in the generated Verilog code (which is what you will end up shipping to the foundry for tape out after synthesis and place & route)? If you do it in the generated Verilog code, how do you trace the bugs back to the Chisel code?

I do think that we need a new language but not for design. Verilog/System Verilog is fine for hardware design, we don't need to reinvent the wheel here. We will always end up in Verilog in our synthesis and quite frankly, we don't spend that much time writing Verilog for hardware design. Hardware design is 5 lines of code and that's it. The real cost of hardware development is the other side of the coin, which is hardware verification.

If hardware design is 5 lines of code, hardware verification is 500 lines. Writing testbenches and developing hardware verification environments and flows is essentially normal programming and we are stuck in System Verilog for that, which is a very bad programming language. Using System Verilog as a programming language is so prone to unintended bugs in your testbenches and bad programming constructs.

This is what we should try to improve, verification not design. We spend far too much time in hardware verification and a lot of that time is spent dealing with pitfalls from System Verilog as a programming language.

I wish people would be investing more thinking here rather than trying to make hardware design friendlier for programmers.

Re: Chisel: A Modern Hardware Design Language

#56

Post by codedokode »

I tried to use Verilog for a DIY project and found no way to control Verilog model from Python. Why is it like this? Do people really write tests directly in this awful outdated language instead of using Python?

I tried to use cocotb, but this is not what I want. It runs verilog interpreter and launches Python script from it, but I want the other way: I want to create a verilog model instance and access it in Python.

Also, I found that Verilog seems to have no built-in feature for modeling real delays. Let's say we have a gate, and when input signal changes, output should instantly go to "undefined" (x) state and only after a delay switch to a valid 0 or 1 value. It seems that verilog has no such type of realistic delay built-in. I found only "transport delay" and "elastic delay", both unrealistic. I had to create my own "delay gate" to simulate this (and made lot of mistakes doing this).

Re: Chisel: A Modern Hardware Design Language

#57

Post by codedokode »

sweden wrote: post #55
phkahler wrote: post #48

Earlier quoted context omitted.

Your stance seems well founded and very compelling. As an outsider to chip design ima play devils advocate and ask, what if the higher level tools reduce overall design time and eliminate a lot of those errors you end up patching in the metal layers? I fought the same battle with auto-generated C from simulink models, and really don't think that's the way to do much for production. But thats because the tool isn't go…

The OP makes an interesting point but it doesn't point out the main problem with high level hardware languages: these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality. The problem is that you will end up with a hardware that is less optimized than if you were to design it in Verilog…

Cannot one write tests in Python? Python seems much nicer to use language. Sadly, I found no library that would allow to create an instance of verilog model from Python and control it (cocotb doesn't allow this).

Re: Chisel: A Modern Hardware Design Language

#58

Post by [deleted] »

sweden wrote: post #55
phkahler wrote: post #48

Earlier quoted context omitted.

Your stance seems well founded and very compelling. As an outsider to chip design ima play devils advocate and ask, what if the higher level tools reduce overall design time and eliminate a lot of those errors you end up patching in the metal layers? I fought the same battle with auto-generated C from simulink models, and really don't think that's the way to do much for production. But thats because the tool isn't go…

The OP makes an interesting point but it doesn't point out the main problem with high level hardware languages: these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality. The problem is that you will end up with a hardware that is less optimized than if you were to design it in Verilog…

[deleted]

Re: Chisel: A Modern Hardware Design Language

#59

Post by BooneJS »

ninjha wrote: post #49
BooneJS wrote: post #45

These languages are fun. "Look ma, no verilog!" But the underlying problem with all of these DSLs is the fact that the EDA[0] industry interoperates on verilog. Period. Worse, at some point in the design cycle, post-synthesized gate-level verilog becomes the codebase. No upstream verilog changes are allowed because it can be difficult to get a precise edit (e.g. 2-input NAND into a 2-input AOI by changing a verilog f…

I think Chisel's main win is that it is great from an open-source research perspective. Taking advantage of the functional nature of Chisel enables a set of generators called Chipyard [0] for things like cores, networking peripherals, neural network accelerators, etc. If you're focusing on exploring the design space of one particular accelerator and don't care too much about the rest of the chip, you can easily get a…

Awesome! When I was an undergraduate all I could tape out was a small wafer of capacitors and correlate theoretical vs silicon.

Chisel is no doubt a developer velocity booster. And generating those components does help speed you along especially when they’re silicon proven.

But I’d wager that most industry silicon has a competitive edge to pay off the NRE, something bleeding edge that can’t get away from verilog interop.

Re: Chisel: A Modern Hardware Design Language

#60

Post by BooneJS »

sweden wrote: post #55
phkahler wrote: post #48

Earlier quoted context omitted.

Your stance seems well founded and very compelling. As an outsider to chip design ima play devils advocate and ask, what if the higher level tools reduce overall design time and eliminate a lot of those errors you end up patching in the metal layers? I fought the same battle with auto-generated C from simulink models, and really don't think that's the way to do much for production. But thats because the tool isn't go…

The OP makes an interesting point but it doesn't point out the main problem with high level hardware languages: these kind of languages don't allow you to describe the hardware you want exactly, they only allow you to describe their functionality and then they generate a hardware for said functionality. The problem is that you will end up with a hardware that is less optimized than if you were to design it in Verilog…

I worked at a startup company that created a DSL to generate verilog. We had the designers do unit testing in the DSL but “sign-off” verification was still UVM w/generated verilog. When a hidden bug costs millions of dollars, you can’t take the risk.
Post reply on HN