All of my experience belong to general purpose programming languages e.g; c/c++ etc where each instructions are executed one after the other but it seems in VHDL/Verilog, all the instructions are executed at once (parallel processes)

Just wondering if there is any resource out there for programmer of general languages to understand how VHDL work?

Reference: http://en.wikibooks.org/wiki/Programmable_Logic/Parallel_Execution

  • \$\begingroup\$ The VHDL manual? Surely there is a manual out there somewhere! \$\endgroup\$ – Olin Lathrop Feb 10 '13 at 23:31
  • 6
    \$\begingroup\$ nope, there isn't a VHDL manual out there. I've looked at many, many VHDL books and they all suck. It's incredible. They're all written by academics and teach the same way.. how to do things the wrong way, the unsynthesizable way. \$\endgroup\$ – akohlsmith Feb 10 '13 at 23:47
  • \$\begingroup\$ @Olin - Andrew is right, there really aren't many decent HDL books out there focused on good FPGA design practice and synthesisable code. I remember thinking exactly the same thing for Verilog. I think it maybe due to both (IIRC) languages not being originally intended for this purpose, rather just simulation. Later support for synthesis was added. \$\endgroup\$ – Oli Glaser Feb 11 '13 at 2:20
  • 3
    \$\begingroup\$ The closest is still Ashenden's "Designer's Guide to VHDL" (either a new edition, or the old one supplemented by "VHDL-2008 - just the new stuff") \$\endgroup\$ – Brian Drummond Feb 11 '13 at 12:35
  • 2
    \$\begingroup\$ My lecturer at university has written a short book called "VHDL for Synthesis" which was essentially the course textbook. It's short and straightforward, with lots of examples that are all synthesisable. It's available here: lulu.com/gb/en/shop/david-binnie/vhdl-for-synthesis/ebook/… \$\endgroup\$ – Al Bennett Feb 11 '13 at 14:58

With HDL languages, you have to understand you are describing hardware, not software. I think this is fundamental to "getting the hang of it". The order of the code in your module doesn't matter, it all happens at once.
It's not so bad once you get going - after you have designed a few simple modules (e.g. counter, adder, mux, etc) your mind should adapt naturally to the process.

The best book I have read to get going with HDL is Pong Chu's "FPGA protoyping by Verilog examples" (I use Verilog, but there is also a VHDL version of this book) It mostly focuses on the synthesisable stuff, which is what you want to know for FPGAs, aside from e.g. testbench code which has a chapter devoted to it also. (I'm assuming that you are interested in using HDL for FPGAs/CPLDs)

Aside from that, a couple of good 'net resources I have bookmarked over time are:


Edaboard PLD forum

ASIC World

With the above links (particularly the first) and the book, you should be "up to speed" in a short time.

|improve this answer|||||
  • 1
    \$\begingroup\$ Pong Chu might be OK on Verilog, but I saw a fairly disgusting (but technically correct) piece of VHDL full of beginner's stylistic mistakes posted here recently; it was lifted from the Pong Chu book! I suspect the problem is that he was writing Verilog in either language. \$\endgroup\$ – Brian Drummond Feb 11 '13 at 12:31
  • \$\begingroup\$ @BrianDrummond - Ah okay, thanks for the info - I have only read the Verilog book, which is very good (although I don't use his Verilog style as it's a bit long winded for a large project, the book is certainly worth reading when starting out) \$\endgroup\$ – Oli Glaser Feb 12 '13 at 8:35
  • \$\begingroup\$ I Like chus books. but the general idea is that you are not writong a program, you are designing a circuit. Think about how the logic gates work, how they respond to inputs in relation to each other, and how wires behave. That's what youbare doing in your code. Now, sim testbench is more of a program, bur can still be partially like circuit design. But design code you intend to build in fpga or silicon is all circuit design. I had to get out of programing mindset to really get this stuff. \$\endgroup\$ – billt Jun 30 '15 at 21:30

"All instructions are executed at once" is not quite how it is either...

I think a very good description of how the scheduling of "instructions" (as seen as "the updates of values") can be found here:


Once you have grasped how signal and variable updates work, you can concentrate on describing what you want to happen in smaller chunks, with signals communicating between them

Make sure you synthesise often as well as simulate at this stage, as you will them discover which bits of the language can't be put into a chip. In addition, you will also discover what sorts of coding-styles produce long chains of logic which will "get in the way" of getting a working chip. Hardware types will like to say things like "you must learn to think in hardware terms". They forget how difficult this is unless you can already do it - but taking your code, synthesising it and looking at the results in the schematic viewer is probably how we all actually learnt it many years ago, and it will work for you too.

(Another thing that non-electronics types overlook until it bites them is that at the pins of the device you need to be aware of synchronising signals into the internals of the chip. There's other questions about that around here somewhere!)

|improve this answer|||||

I found a beneficial way of getting procedures expressed in VHDL was to consider the finite state machine. By visualizing your algorithm as states in a FSM, you can start to re-shape your code into something that can be executed all-at-once, and only gets executed step-by-step by virtue of the FSM.

I'm not saying you need to build a state for each line of similarly functional C++ code (though that would theoretically work), but you can start grouping things like assignments and calculations, and hand them off to a state to be executed simultaneously when the FSM enters that state.

Now, your "program" becomes a FSM, which, in VHDL is a big case-switch type statement (based on the state of the FSM), and some logic for how the state needs to be updated to go to the next state for your algorithm.

Hope this helps!!

|improve this answer|||||
  • \$\begingroup\$ Note that an FSM is a lot of combinational logic (what will all the next output signals be and what will the next state be) plus a relatively small amount of sequential logic to capture the new current state, new output values, etc. when the clock edge comes. \$\endgroup\$ – billt Feb 12 '13 at 1:41
  • \$\begingroup\$ In hardware, true. And that is indeed the end result on the FPGA or whatever you use. But defining all that logic explicitly isn't necessary with the modern compilers available these days. All you'd really need is a little testing logic (if..then, not AND OR) to decide what to store as your next intended state. Working from a hardware standpoint, it makes sense, but the question asks for things in terms of c/c++, going from sequential programming to VHDL, not hardware to VHDL. \$\endgroup\$ – bythenumbers Feb 14 '13 at 20:15

In C or C++, Java etc. you are essentially creating a sequence of events to happen in order. Understand that in an HDL you are only doing a sequential program in the testbench, in order to get a timed sequence of signal values.

The good part of coding in HDL is actually designing a circuit netlist, not a program. Think of a case or switch block as a multiplexor. Inputs are wires, outputs are wires, in the middle is combinational logic. on silicon or on a breadboard, a wire does not wait it's turn to be told what to do. A 74xx nand gate does not wait to be told what to do. It's always a nand gate, and it's always nanding, so long as power is on. A multiplexor always multiplexes. An inverter always inverts. Then flops always flop on any clock edge, and a latch always latches on it's enable. Same as if you drew a schematic. Modules and Entities are the same as a heirarchical schematic. It made a lot more sense to me when I stopped thinking of it as a program and started to see the circuit instead.

My favorite reference is Chu's RTL Hardware Design Using VHDL. Even Verilog people would benefit from the concept stuff, but it's all VHDL syntax. http://www.amazon.com/gp/aw/d/0471720925/ref=mp_s_a_1?qid=1360628255&sr=8-1&pi=SL75

|improve this answer|||||

VHDL and Verilog were originally designed as languages to describe hardware for simulation. They were later re-used as languages to describe hardware for synthisis.

There are two strategies to describing hardware, behavioural and structural. In behavioural description we use program code to describe how our hardware behaves. In structural description we describe our peice of hardware in terms of smaller peices of hardware.

Most practical designs will use a mixture of both. So you have small behavioural blocks (always blocks in verilog, processes in VHDL) within an overall structural design.

Normally we have two main types of behvaioural block. "combinatorial" blocks define a combinatorial function of their inputs. Logically they are run when any input changes and they have no memory.

Sequential blocks are normally written to define what happens after the clock edge in terms of what happened before the clock edge. This is how we manage to maintain a determinisitic design even though all blocks triggered by the same clock edge run in a nondeterministic order in the simulator and at the same time in the synthisized hardware.

If you plan to synthisize your code then you need to think about what things mean structurally even when defining them behaviourally, because the first thing the synthisizer is going to do is translate your behavioural description to a structural one. Loops will be unrolled, arithmetic and logic statements will become arithmetic and logic hardware blocks. Flow control statements will become multiplexers (potentially very wide ones).

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.