Live data from Hacker News

Why hardware development is hard: Verilog is weird

danluu.github.io

21–30 of 54 posts

Re: Why hardware development is hard: Verilog is weird

#21

In school we learned VHDL. I found it EASY to adapt. However you have to ditch the notion you are working with a programming language. So either build your own CPU in VHDL specifically optimized for you problem. Or "code" it like you would build hardware! This means taking a different look at things: for example storing in an array: you create a bus: address bus, of the width you need, data-bus of data width you need…

VHDL for FPGA's is easy but in the real world you need to deal with things like latency, PLLs, et al. There are few academic programs that make students aware of the trials and tribulations in modern hardware design.

Re: Why hardware development is hard: Verilog is weird

#22

I'm having a hard time reading this article, considering he starts off with false information like: "The problem is that Verilog was originally designed as a language to describe simulations, so it has constructs to describe arbitrary interactions between events. When X transitions from 0 to 1, do Y. [...] But then someone had the bright idea of using Verilog to represent hardware." Verilog was made from the start wi…

From Wikipedia:

"Originally, Verilog was intended to describe and allow simulation; only afterwards was support for synthesis added."

http://en.wikipedia.org/wiki/Verilog#History

Re: Why hardware development is hard: Verilog is weird

#23

Earlier quoted context omitted.

Generate statements are your friend.

VHDL generics and generate work nicely for 1d cases, but for 2d cases (systolic arrays), it's difficult to make the scripting really work without hard-coding a bunch of corner cases. Another example is that defining barrel shifters is impossible to parameterize, because you need to hardcode the mux cases (see the Xilinx datasheet[1]). That's kind of insane, considering that bit-shifting is a very common and basic ope…

Well, I suppose you could say assembly is an analog of writing hdl that is very structural.

I haven't done it myself, but generates can be nested. You'd have to check to see if your tools support it or not though.

With the xilinx example, I'm not sure what you mean. Is it choosing to do multi-level muxing vs a naive muxing solution? I'd start by just writing a simple behavioral version, and only if that didn't meet performance constraints would I bother doing anything structural about it.

It's late and maybe I'm just not thinking it through. I'll take a stab at some of this and maybe it'll be clearer to me.

Re: Why hardware development is hard: Verilog is weird

#24
post #12

IMO the syntax of Verilog isn't so problematic. Adhering to a simple style guide will avoid most gotchas. The author does make a passing reference to the real problems though: 1. Simulation is many orders of magnitude slower than the same code running in production (and you see code in production only after many months and dollars). You don't face this slowdown when writing software. 2. Compared to software, there is…

You can overcome 2 by building a software that parametrizes your hardware.

Just like a core wizard, you can build a Python scripts that output the Verilog/VHDL code according to the desired settings. Not only accelerates the process, but may also prevent bugs on the long run.

Re: Why hardware development is hard: Verilog is weird

#25
> The aversion to Haskell is so severe that when we discussed a hardware style here at Google, one person suggested banning any Haskell based solution

...curious, but why would folks in this field even care about what programming language is this based on? Theoretically abusing the concept, wouldn't you just use something Brainfuck based if you found a nice way to describe your hardware using some BF based software and DSL? Most attributes of programming languages that we software guys care about seem irrelevant at this level, so Haskell or C or Lisp, why would it matter?

Re: Why hardware development is hard: Verilog is weird

#26
post #25

> The aversion to Haskell is so severe that when we discussed a hardware style here at Google, one person suggested banning any Haskell based solution ...curious, but why would folks in this field even care about what programming language is this based on? Theoretically abusing the concept, wouldn't you just use something Brainfuck based if you found a nice way to describe your hardware using some BF based software a…

Well, because some languages are harder. Haskell is a tough nut to crack (especially the "Monad" thing, but the type system also gives some question marks as well)

Yeah, functional languages are closer to what hardware does, but more importantly, they may be close but not close enough

As the example showed, you have several side effects. Combinational logic (http://en.wikipedia.org/wiki/Combinational_logic) is a very good match to functional languages, however Sequential logic is "very different" (from an analysis point of view)

Re: Why hardware development is hard: Verilog is weird

#27
post #2

The problem is that Verilog/VHDL isn't a "programming language" in the sense that C, Lisp, Haskell, or Python are programming languages. So approaching them with a programming language mindset is asking for a lot of pain and misunderstanding. HDLs like Verilog and VHDL describe digital circuits, not algorithms and instructions for manipulating data. If C code is akin to instructions for getting to a grocery store and…

And the fact that logic takes so long to synthesize and simulate really has little to do with Verilog's deficiencies; if anything it's a limitation of the register-transfer level abstraction that's currently used to design digital hardware.

If that's the case, then why are Chisel and bluespec much faster to simulate despite having less investment in tooling?

Re: Why hardware development is hard: Verilog is weird

#28

Earlier quoted context omitted.

Generate statements are your friend.

VHDL generics and generate work nicely for 1d cases, but for 2d cases (systolic arrays), it's difficult to make the scripting really work without hard-coding a bunch of corner cases. Another example is that defining barrel shifters is impossible to parameterize, because you need to hardcode the mux cases (see the Xilinx datasheet[1]). That's kind of insane, considering that bit-shifting is a very common and basic ope…

Why not using a higher level language like confluence, or some other tool which help you generate the verilog boilerplate for this kind of situation?

Re: Why hardware development is hard: Verilog is weird

#29
Chip vendors often give you a way to instantiate on chip hardware (memories, latches, etc).

I found the path of least resistance (and highest performance) was to figure out what circuit I wanted, then basically use Verilog to wire these primitives together to make it. By causing verilog to use an actual memory block, rather than a stack of flipflops, you would yield a nice performance increase also.

The trouble is that doing that isn't vendor neutral, and the whole approach probably wouldn't be any good if you were targeting ASIC. It was just 'alright at college'.

In 'real' pro verilog development, do people do this?

Re: Why hardware development is hard: Verilog is weird

#30
Ya' know, I've noticed a LOT of posts here pointing to new blogs with only one (in this case) or few articles and all have the same site theme, with the black header at the top.

I don't know what that means or why it is but I'm saying it's been at least a dozen over the last couple of months.

Post reply on HN