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

Verilog Is Weird

danluu.com

Post reply on HN
Print view View original

31–40 of 131 posts

Re: Verilog Is Weird

#31

Post by pjc50 »

Taniwha wrote: post #24

I think that really the hard part of learning to design chip stuff really is other stuff - understanding where/how to use storage (flops) and combinatorial logic - and simultaneity: how to handle things that happen at the same time. Initially you really need a strong understanding of digital logic (not a language), in particular pipelines. Once you have that stuff in your head you can turn to verilog (or vhdl or what…

> Once you have that stuff in your head you can turn to verilog (or vhdl or whatever) and learn how to map these ideas into the language

Yes, and per the other comment this is a huge limitation of them - you don't have Javascript authors saying "you need to work out what you want in this other paradigm and then translate it". You occasionally see people writing C this way though, by working out what they want from the assembly and working backwards, which tends to get wrecked by UB or the optimizer at some security-critical point.

If the main point of the language is to generate flops, flops should be an explicit primitive!

> Verilog is an early object oriented language - modules are objects

Maybe, but IMO a more useful place to apply object orientation would be interfaces, which are nets not modules. I should be able to instantiate "AXI bus" somewhere and connect things to it.

Re: Verilog Is Weird

#32

Post by jstanley »

Taniwha wrote: post #24

I think that really the hard part of learning to design chip stuff really is other stuff - understanding where/how to use storage (flops) and combinatorial logic - and simultaneity: how to handle things that happen at the same time. Initially you really need a strong understanding of digital logic (not a language), in particular pipelines. Once you have that stuff in your head you can turn to verilog (or vhdl or what…

> "always X" just means loop waiting for X

I think this is actually not right. There's not any kind of loop that is running, it's triggered by signal edges. That's the fundamental difference between hardware and software that makes hardware difficult for software people. Everything happens simultaneously.

Re: Verilog Is Weird

#33

Post by hobofan »

butlerm wrote: post #28
misnome wrote: post #26

Earlier quoted context omitted.

I wonder if this is similar reasons to why lots of CS papers seem to never have the date on?

Some academic types seem to believe that no paper should ever bear a date other than the date of formal publication. Not quite sure why that is, the date of a draft seems like incredibly helpful information to me.

Yes, especially when trying to reconstruct the timeline and context of related research, to help understand the methodology and implicit (lack of) reasoning. With time context one can often go from "why would they do it like that?" to, "given that X wasn't discovered at the time, it makes sense that they did it like that".

Re: Verilog Is Weird

#34

Post by gchadwick »

adrian_b wrote: post #30
cyber_kinetist wrote: post #22

Earlier quoted context omitted.

Wow, didn't know that Bluespec was open sourced. I used in my Computer Architecture class for assignments 6 years ago, and my experience was that it was much much better than Verilog (the type system was far better) but there was too little learning material/documentation out there on the Internet.

Bluespec was not open sourced. There is now an open-source Bluespec compiler based on the little public information that is available about Bluespec. So it is likely that it is not compatible with the full Bluespec, even if can synthesize published examples of Bluespec. There are some research papers and the code at: https://www.cl.cam.ac.uk/~djg11/wwwhpr/toy-bluespec-compiler...

Bluespec was open sourced slightly over two years ago:

https://twitter.com/bluespec/status/1225184669978841090 https://github.com/B-Lang-org/bsc

Indeed seems Bluespec Inc. has pivoted to RISC-V CPU IP. No obvious mention of BSV on their webpage (https://bluespec.com/)

Re: Verilog Is Weird

#35

Post by tails4e »

jstanley wrote: post #32
Taniwha wrote: post #24

I think that really the hard part of learning to design chip stuff really is other stuff - understanding where/how to use storage (flops) and combinatorial logic - and simultaneity: how to handle things that happen at the same time. Initially you really need a strong understanding of digital logic (not a language), in particular pipelines. Once you have that stuff in your head you can turn to verilog (or vhdl or what…

> "always X" just means loop waiting for X I think this is actually not right. There's not any kind of loop that is running, it's triggered by signal edges. That's the fundamental difference between hardware and software that makes hardware difficult for software people. Everything happens simultaneously.

I think the loop term is OK, it's just gated by the event sensitivity list for each iteration. If you have an always without a sensitivity list then it is a while(1) equivalent.

Re: Verilog Is Weird

#36

Post by rad_gruchalski »

mjw1007 wrote: post #12
jwilk wrote: post #7

(2013) according to https://danluu.com/ .

It's remarkably strange that someone who appears to be blogging semi-professionally thinks it's reasonable to publish an article of this sort without a date attached. Maybe Verilog doesn't change much, but statements like "Commercial vendors are mostly moving in the other direction" and "There have been a number of attempts [...] but they've all fizzled out" are date-sensitive.

It was submitted by mrintellectual.

Re: Verilog Is Weird

#37

Post by m1kal »

anyfoo wrote: post #6

Oh boy, this is a sore subject for me. It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a drastically mismatched paradigm for hardware design, where circuits are combined and "everything happens in parallel". It becomes even more obvious when you have tried a functional alternative, for example Clash (which is essentially a Haskell subset that compiles…

SV and VHDL are nasty languages, but as you said, they are "industry standard". Chisel and Haskell-based approaches are better but virtually nobody adopts them.

I tried to go in another direction, to make design code shorter by using Clojure syntax. The result is here: https://github.com/m1kal/charbel and works for simple modules. I don't expect wide adoption, but we need to look for new directions instead of sticking to the methods and languages from the 80s.

Re: Verilog Is Weird

#38

Post by q3k »

adrian_b wrote: post #30
cyber_kinetist wrote: post #22

Earlier quoted context omitted.

Wow, didn't know that Bluespec was open sourced. I used in my Computer Architecture class for assignments 6 years ago, and my experience was that it was much much better than Verilog (the type system was far better) but there was too little learning material/documentation out there on the Internet.

Bluespec was not open sourced. There is now an open-source Bluespec compiler based on the little public information that is available about Bluespec. So it is likely that it is not compatible with the full Bluespec, even if can synthesize published examples of Bluespec. There are some research papers and the code at: https://www.cl.cam.ac.uk/~djg11/wwwhpr/toy-bluespec-compiler...

bsc, the bluespec compiler, has been open sourced under the MIT license. It's the real deal, the same bsc that has been used in the industry for years now.

I've been using it in my own personal projects for something something like two years.

Re: Verilog Is Weird

#39

Post by q3k »

gchadwick wrote: post #20
anyfoo wrote: post #6

Oh boy, this is a sore subject for me. It's pretty obvious that Verilog and VHDL, modeled after C and Ada respectively, both imperative languages, follow a drastically mismatched paradigm for hardware design, where circuits are combined and "everything happens in parallel". It becomes even more obvious when you have tried a functional alternative, for example Clash (which is essentially a Haskell subset that compiles…

Verilog definitely sucks but I think the problem with new HDLs (Clash, Bluespec, Chisel etc) is they don't necessarily make the hard bits of hardware design easier, they just help with the tedious stuff that whilst annoying ultimately doesn't take up much of your time. For example a good type system definitely makes module interfaces cleaner, saves you having to dig through warnings/lint reports to find stupid errors…

I've tried pretty much every 'NeoHDL' out there, and so far Bluespec was the one that actually made me feel like it's a step in the right direction, instead of more of the same.

Its atomic transaction based modelling maps superbly well into hardware clock cycles, and after using it for a while you learn to visualize quite well what shape of RTL will be generated. Plus its standard library provides some really powerful _and practical_ interfaces/implementations that make building things fast and safe. Oh, and a lot of things you would generalize with fairly heavy-handed and bespoke abstraction in things like Chisel/Spinal/Migen/Amaranth just map directly into Bluespec's type system constructs, making interacting with existing codebases much less of a reverse engineering effort.

The Bluespec SystemVerilog syntax is a bit... quaint, but if you're used to (System)Verilog you know the deal. I personally want to spend some time soon learning the Bluespec Classic/Haskell instead, but that's mostly because I already know some Haskell...

Overall, highly recommend giving it another shot. It made me enjoy writing HDL code again after years of frustration with other offerings. It's one of the few languages out there that actually make me feel 10x as productive thanks to the strict type/runtime semantics.

Re: Verilog Is Weird

#40

Post by Koshkin »

rowanG077 wrote: post #21
jiggawatts wrote: post #13

Earlier quoted context omitted.

One thing I don't quite understand about using Haskell for circuit design is that at a first glance it also seems like pure functional programming has an impedance mismatch with what the circuitry physically does. (For reference, I've programmed in Haskell extensively before.) For example, much of Haskell directly or indirectly relies on recursion -- but this nearly nonsense when talking about silicon! There's no cal…

Why do you feel there is a mismatch? Any digital circuit can be modeled with a pure function that transforms an input stream of values to an output stream of values. And that is actually precisely what Clash does. Regarding recursion. I believe Clash does support a limited form of recursion. Namely if you prove every recursive call leads to the problem size strictly decreasing. e.g. recursion on a vector of size n mu…

> Why do you feel there is a mismatch?

Can this be because in digital circuits state (memory) plays an important role, while its treatment in a (pure) functional language is not straightforward?

Post reply on HN