
How to Write Safe Verilog: Become a PL Troll - luu
http://danluu.com/pl-troll/
======
NoodleIncident
This is a fascinating glimpse into a world I know less than nothing about. I
don't anticipate ever needing to code in Verilog, but I'll try to keep this in
mind and look for other places where a little effort can save a lot of time.

I wonder what this has to say about type systems in general. Projects like
Clojure's core.typed let you add static typing as a library where you feel
like you need it, but then you don't get the benefit of statically checking
everyone's code, all of the time. Perhaps a company policy on what functions
need to be typed would do the trick, but at that point the compiler might as
well enforce it for you.

~~~
thesz
Hardware programming is THE area where you need static types _always on_.

Basically, you have to write everything in goto statements, no while's or
for's. You also have to check that size always match, otherwise you will have
errors. You also have to check that you do not accidentally drive one input
from two outputs, otherwise you will also get errors.

As you discover errors through very slow simulation (small circuit takes about
4 days of simulation for measly 2 seconds and it stays about 60% of time idle,
e.g., not doing much), you really need to face any possible errors ASAP.

Another option is code generation from some high level model, but then you can
miss something important like critical path delay or latency (in clock ticks)
and you have to bring that information into the model. While this can be done
in Clojure or Python or something alike, it is not a panacea, not even close
to that.

~~~
robomartin
> Hardware programming is THE area where you need static types always on.

It's not "hardware programming". It's hardware design. It's no different from
connecting raw gates and chips on a breadboard. This is a very important
distinction that is often glossed-over in HN conversations.

Verilog is a tool with which you explicitly or by inference DESCRIBE hardware.
You are not programming hardware. That's software.

At some level this concept of static types is nonsensical. You have registers
made up of flip-flops that move data around from circuit block to circuit
block. That's it. Data types, in many ways, are software constructs, they
don't really exist in hardware.

One would not look at a breadboard full of chips or an old-school PCB with
latch and flip-flop chips and discuss static data types. Maybe you'll talk
about fixed with data busses that implement this or that encoding, but that's
about it.

One could argue that a specialized floating point processor has a data type.
That's one way to interpret it. Another way is to say that it has a, say, 64
bit architecture that, by convention, is interpreted in order to be able to
represent floating point numbers within certain constraints. If by that we
mean "static data type" then, well, I suppose I can go with that.

~~~
thesz
Take, for example, Avalon streaming interfaces:
[http://www.altera.com/literature/manual/mnl_avalon_spec.pdf](http://www.altera.com/literature/manual/mnl_avalon_spec.pdf)

Yes, it is a bunch of flip-flops and gates, but in the end the interface with
"empty" signal is different from interface without it. The same is for error
signal.

To connect those sinks and sources properly you have to match types. E.g., you
have to deal with the absence of "empty" on one end.

Otherwise you will surely make some obvious mistake.

And, finally, Avalon streaming interface is a tuple: type ASI a = (SOP, EOP,
a) data SOP = NoSOP | SOP -- SOP and EOP equivalent to boolean data EOP =
NoEOP | EOP

And parameter "a" can be anything - raw value without empty or error, tuple of
value and empty, tuple of value and error, triple of value, empty and error.
They all are different. Even if their connection is no-op, like inventing
"always good" value for error field, this no-op should be specified.

Otherwise, you make discovery of the error very distant.

------
bhb916
As someone who spends 40 hours a week (and 60 - 70 lately) coding Verilog for
FPGAs I'm always excited when something domain-specific hits the front page. I
have no idea what a PL Troll is, though, so I think I missed the point of the
entire post. Anyone care to elaborate? Google is not helpful.

~~~
lincolnq
A programming languages troll would be someone who suggests using obscure
programming languages or techniques (you should use Agda here, you should
write a type checker) to solve systems problems "because it's safer"
regardless of practicality.

Source: being a PL troll :)

------
azernik

      EDA tools vary in license costs, from a few thousand
      dollars per machine license per year, to half a million
      per core license per year. Timing tools aren’t all the way
      at the top end, but they’re not cheap.
    

I have never in my life _touched_ software this expensive. It's interesting to
me how this warps workflows - e.g. automated testing tools can only test one
build every two days, not because running in parallel is computationally
expensive, but because licensing is too expensive in cash terms. Given the
zero marginal costs (to software vendors) of existing customers running extra
copies, this sounds completely insane to me.

~~~
StringyBob
I use these types of software day to day. The true price is veiled behind
multi milkion dollar contract negotiations. You should see the inverse
relationship between price and lack of bugs.

What's more of a challenge is trying to use techniques like continuous
integration when your compile time is a week!

~~~
robomartin
> What's more of a challenge is trying to use techniques like continuous
> integration when your compile time is a week!

And your simulation time is another week.

And interpreting the results could be another week.

I've worked on designs where you can only do one iteration per day to on
iteration per week. It really slows down development to a crawl.

You learn very quickly to segment designs and validate everything as far as
humanly possible before even dreaming of simulating/compiling larger
functional blocks.

These are ways in which modern hardware design is vastly different and vastly
more expensive than any comparable software development workflow.

The cost of hardware tools is pretty much insignificant when you consider the
entire process. Buying a $50,000 signal analyzer might save you weeks or
months of development and debug time. You can't launch into these kinds of
startups with a $15K investment over a summer.

------
iso-8859-1
Anyone who needs a Verilog with proper typing should check out Bluespec. It
has the Haskell type system and it transpiles to Verilog. Due to type
inference, it doesn't need to be verbose. Don't let my refernce to "Haskell"
scare you, you decide yourself how general your code is. If you don't want to
worry about monads, you don't need to.

~~~
smilekzs
His previous post mentioned that.

------
tcas
"In high speed designs, it’s an error to use a signal that’s sourced from
another module"

How else are you supposed to get I/O from one module to another, say a 32bit
data bus? Also, what's the definition of high speed here?

"unless you like random errors"

And very hard to diagnose errors until you realize that you messed up your
clock domains.

~~~
aortega
Spent the last 2 years doing high-speed comm designs on FPGAs. (I don't know
if 5 Gbps currently count as high speed though). The tools are quite mature
and will mostly prevent you from doing stupid things.

Somewhere here I saw a comment saying that you must time your design taking in
account the logic delay or will get weird errors, but that's impossible. The
tool chain (both quartus and Xilinx ISE) will report the max clock speed with
a big bold red font if you try to go faster.

There's a step in every design flow called DRC (Design rule-checker),
basically a bunch of warnings if you do dumb things with anything including
the high-speed transcievers. You must pay attention to the warnings.

Neverd did any ASIC but I know they have about 10X the testing and simulation
that FPGA have. I would believe you don't get random errors if you follow the
standard design flow and tests.

~~~
MichaelSalib
_Neverd did any ASIC but I know they have about 10X the testing and simulation
that FPGA have._

My spouse designs CPUs for a major CPU manufacturer (you've used them). She is
responsible for physical design for one tile (there are many tiles, each of
which has other physical designers). Her single tile, by itself, is
substantially larger than almost all ASIC designs in the world today. At that
scale, most of the standard FPGA design tools don't even work. Designing in
that space is substantially different than FPGA or even ASIC design.

~~~
sliverstorm
The third type after FPGA and ASIC, sometimes called "full custom". Related to
ASIC, but distinct.

[http://en.wikipedia.org/wiki/Full_custom](http://en.wikipedia.org/wiki/Full_custom)

------
robomartin
Being that HN is permeated by software developers it might be important to
point out that Verilog code is not software but rather hardware description.
The developer --in this case typically an EE-- either explicitly or through
inference describes circuit structures with something that looks like a C-like
programming language.

Concepts such as modules don't translate directly into the software world. A
module is a grouping of circuit elements. The criterial for grouping them can
be varied. One typically creates modules for functional blocks that are easy
to plug into the overall circuit. And, much like a subroutine, the other
motivation is when one must use the circuitry multiple times. The difference
is that a subroutine is called and exited. A module instantiation creates real
and permanent circuitry on the chip (ignoring FPGA reconfiguration
techniques).

I've been working with HDL's for quite some time. Frankly, every attempt I've
seen to get away from hardware development and making it look like software
development is crippled in some way or another. I equate this to the idea of,
for example, tools that allow you to write mobile apps using something other
than the native language and framework of the platform. It works. Until it
doesn't.

As far as the article is concerned, no issues with any of it. It's an
interesting approach. That said, I've never used anything similar to this and
can't remember the last time I had such problems. This isn't criticism. Just
one data point.

~~~
VLM
Three minor additions to what should become a HN FAQ every time there's a
vaguely FPGA/ASIC article:

This is hardly official and not a perfect analogy but github is to software
devs as opencores.org is to FPGA devs. Thats why when you go to github and
search for Verilog and only get 259 hits for stuff written in Verilog you're
going to the wrong place.

The other FAQ is verilog looks like C because C looks like the incredibly
orthogonal PDP-11 addressing modes chart. So pretty much if you can imagine it
as an addressing mode, the PDP-11 could do it, so thats explains the weird
compatibility between something that looks like C and something that can
define the hardware of a CPU. Its not a perfect analogy but it kind of
describes why the HDL look very C like rather than Ruby like, for example. If
you could build it out of basic logic gates in 1970 using TTL chips, its
probably supported by the old PDP-11 and therefore in C.

Finally you need a FAQ for old timers that home-scale FPGA / CPLD stuff has
collapsed in price over the last decade or two. Yes, in 1990 you needed four
figures to do anything so no one did anything at home. Now you need at minimum
a $50 board and a (multi-gig) free download. Its maybe 3dB more expensive than
fooling around with arduino stuff. The small scale stuff doesn't scale well to
larger stuff; I think its "weird" when a simple gray code decoder or
quadrature decoder takes a minute to synth, so yes doing a complete CPU does
take a long time to synth even on fairly high end hardware. Back to the old
days of batch computing, sorta.

~~~
robomartin
Over the years I've accumulated a pile of dev/reference boards. In my world
you eventually have to migrate to application specific hardware. This is where
it quickly leaves the home/hobby domain, the tools get more expensive and the
required knowledge-base expands. I am mostly talking about the challenges of
high speed design.

The minute you get into the hundreds of MHz and into GHz and thousand pin
devices you've entered a domain that is far away from what casual hackers can
handle.

Yet, I do agree with you. Today, free compilers from Xilinx and Altera support
devices that ten years ago required their multi-thousand dollar suites. Free
or low-cost PCB design tools are out there. All of this of course, comes with
compromises. Free simulation tools don't compare to paid tools. Free and low
cost EDA software packages don't have all the tools you really need to
efficiently manage high speed design of complex boards with larger devices.
Signal integrity alone has dedicated (and very expensive) tools that you
almost can't do without in certain domains.

None of this is to say that it is impossible for someone to play with the
technology but it certainly ain't like playing with software.

~~~
VLM
Yes good point. Probably add another one to the standard HN FPGA FAQ that
doing / learning X at home is pretty easy, as long as its not prefixed by
"GHz" or "really fast".

------
simias
This reads more like a succession of notes rather than a coherent article to
me, I had some trouble understanding what the author was getting at. It's
still worth reading IMO, but I doubt people who have no background on hardware
design understood what TFA was talking about.

Also, I really don't understand what the author meant by "PL troll". Writing
static code checkers is trolling nowadays?

------
sliverstorm
_In high speed designs, it’s an error to use a signal that’s sourced from
another module_

Not sure if I agree here, at least in these absolute terms. Sometimes you
cannot afford to unnecessarily capture every I/O signal, and it is indeed not
always necessary.

------
hclee
In ASIC RTL, two really important things should be considered. DFT
implementable and synthesis friendly. Verilog with those two can only compete.
In that sense, ARM is one of the best at it.

I am not sure if a static checker meant 'lint' but Verilog writer can be
better being good at static check and static checker at next end.

------
jahagirdar
Most of the typechecking described in the article is now done by standard off
the shelf linters e.g. Atrenta Spyglass

