Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

A Verilog Introduction for Hackers

By the in Technology
Sun Feb 29, 2004 at 09:23:14 AM EST
Tags: Hardware (all tags)

Designing your own chips, the silicon variety. That's something you do with millions, if not billions of dollars of equipment and large fabrication plants under ultraclean conditions. Well, isn't it? Actually, no. You can design your own chips at home with a PC using no more than about $50 of equipment and I'm going to tell you how with the absolute minimum of effort.

I'm going to make some basic assumptions: that you vaguely know a language with C like syntax and have a vague idea that digital electronics is about manipulating binary data represented in wires by a voltage level using logic gates.

You can't design your own components completely from the ground up at home, for that you do need a lot of expensive equipment. But what you can do is program what are known as Field Programmable Gate Arrays (FPGAs) or Complex Programmable Logic Devices (CPLDs). These are large arrays of logic gates connected by a complex network that allows you to connect any gate to any other pretty much however you want. In effect you design a logic circuit on a PC that is downloaded to a chip. You can use all the usual digital components that you expect to see as discrete components: adders, flip-flops, shifters and so on. Even better, you don't even have to get your hands dirty designing circuits with these things because you can implicitly design your circuit with a high level language and have it automatically turned into a downloadable circuit.

Now here's a caveat: I'm not in any way an expert at this subject. I have no electronics background and my knowledge comes from a few hours of tinkering here and there in the evening. But I'm hoping that even though this means I'll make lots of mistakes I'll at least be able to demonstrate that this stuff really isn't that esoteric and that anyone who has basic programming knowledge can turn their hands to it.

There are a number of FPGA and CPLD development boards available but the one I'm going to talk about in this example is the Digilent XCR.

These boards use components from the company Xilinx and they provide a free development system known as Webpack. You simply plug the board in into a PC, fire up the development system, and go.

Now comes the design bit. There are two popular high level languages used for digital design: VHDL and Verilog. To my inexpert eye there is no difference betwen them except for the parser at the front end. Verilog looks like C and VHDL looks like Ada and requires developers to write a morass of syntactic glue that apparently serves no purpose. So I'll talk about Verilog. In fact, here's some sample code for you to look at. This code can be synthesized (that's like compilation but it's not called that) and downloaded directly to the XCR board with the free Webpack software.

So cast your eyes over some sample Verilog code:

module xcrdemo(mclk,ld9,btn,swt,led,an,ssg);
input mclk;
output ld9;
input [3:0] btn;
input [7:0] swt;
output [7:0] led;
output [1:0] an;
output [6:0] ssg;

reg [2:0] clkdiv;
reg [3:0] cntr;
wire cclk;
wire [6:0] dig;

assign led = swt;
assign ld9 = btn[2] | btn[3];

assign an = btn[1:0];
assign ssg = dig;

assign dig = cntr=='b0000 ? 'b0111111 :
cntr=='b0001 ? 'b0000110 :
cntr=='b0010 ? 'b1011011 :
cntr=='b0011 ? 'b1001111 :
cntr=='b0100 ? 'b1100110 :
cntr=='b0101 ? 'b1101101 :
cntr=='b0110 ? 'b1111101 :
cntr=='b0111 ? 'b0000111 :
cntr=='b1000 ? 'b1111111 :
cntr=='b1001 ? 'b1101111 :

always @(posedge mclk)
clkdiv<= clkdiv+1;

assign cclk = clkdiv[2];

always @(posedge cclk)
cntr<= cntr+1;


Chances are you can already guess what most of this does. I have defined a module (in this case representing the CPLD chip on the board) and I've defined a bunch of inputs and outputs. You can probably guess which is which. The brackets are used to declare arrays. For example out [7:0] led; line tells you that led in fact represents 8 output wires coming out of the CPLD. Unlike software engineers hardware engineers like to think of arrays backwards, hence the decreasing range from 7 to 0. The wire lines define internal wires within the CPLD. They are used, as you might expect, to connect things to each other.

On the XCR the 8 swt inputs are connected to switches and the 8 led outputs connect to LEDs. So assign led = swt simply says that the state of the LEDs is equal to the state of the switches. In other words, each switch turns an LED on or off.

The assign dig line is more interesting. If you can read C you'll guess immediately that it maps 4 bit numbers to 7 bit numbers. ('b means that a binary number follows) In fact the 7 bit ssg output is connected to the 7 segments of an LED display and this line performs binary to seven-segment conversion.

An important thing to note about the assign lines is that they are continuous assignments. In C if you say a=b; it means "copy the contents of b into a". In Verilog it's more like a functional language and assign a=b; means "forever more the value of a is the same as the value of b". Every one of these assign statements is running simultaneously in parallel. That might give you a clue why you might want to use these devices rather than microcontrollers for certain situations - you can have all those adders, shifters and flip flops working in parallel unlike the traditional von Neumann type machines we normally use that only perform one or two instructions at a time. Imagine how fast you can run the game of life with a bunch of logic gates dedicated to every cell.

And that now brings us to sequential logic. What happens if you want your custom designed chip to perform things sequentially? That's where the always line comes in. always @(posedge mclk) means "whenever the value of mclk goes from 0 to 1 do the following". On the XCR board the mclk input is connected to a clock with a period adjustable from a few Hz to a few KHz.

Note how clkdiv was defined to be a reg instead of a wire. This means that it is a register that has a persistent state. This means that when clkdiv <= clkdiv+1 is executed (once per clock pulse) this 3 bit register is incremented - it's more like a C assignment. Similarly the register cntr is incremented every time bit 2 of clkdiv goes from 0 to 1.

There are some other lines in the code and you can try to guess what they do.

So among other things this board displays a 4 bit count incrementing over time, though it remains blank for 0xA to 0xF. The CPLD device on the XCR board is non-volatile. This means you can simply pop it out of its socket and add it to your own circuits. Just connect up power and ground and it'll do just what your Verilog code says.

With my XCR board I have implemented a complete an entire CPU with memory in about 50 lines of code and on their DXL board I have made my own Pong game that plugs straight into a monitor with the FPGA directly controlling the voltage levels of the VGA in. This stuff is surprisingly straightforward and you get to learn a lot about how electronic devices really work at a low level.

So there you have it in a nutshell - digital design through Verilog. I'll just add one more thing about the code: to completely define how this code maps to the hardware there is another file that simply lists which pins on the chip correspond to which of the named input and output ports. The syntax is usually easy to decode once you've seen the example that comes with whichever board you decide to purchase. So go and get designing already! Even if you don't make a career of it or make a useful device for the home you'll have a deeper appreciation of just what exactly is happening inside your PC at any moment.

Further Information
There is a wealth of low cost development boards out there. Besides the Digilent boards you might like to try:

  1. The FPGAProto which comes with the verilog source to turn it into a complee 16 bit CPU. You can then hack the verilog to add your own instructions or custom I/O circuitry.
  2. The Pluto board.
  3. The BurchED.
  4. And a variety of boards are always available on Ebay.
There are many digital designs out there on the web. Example projects out there (some downloadable to synthesize on your own hardware) include:
  1. Atari 2600 on a chip.
  2. Various arcade games.
  3. Chess!
  4. Cracking DES
  5. A wealth of CPUs and computer hardware at at opencores.
  6. And the ubiquitous Pong game.
PS You don't have to use real hardware. Simulators for Verilog and VHDL exist. I've played a little with Icarus Verilog. The free commercial packages such as Webpack also come with (crippled) simulators. Watch out with simulators though - they allow you to write code at an abstract level that can be simulated but not immediately implemented in hardware. In effect Verilog doesn't just give a way to describe circuits but it also allows you to write code to simulate a circuit whose actual implementation you haven't figured out yet.

PPS One last thing: whenever I edit this story scoop incorrectly converts < in the source back to <. Sorry if it's messed up.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


Related Links
o Scoop
o Xilinx
o Webpack
o FPGAProto
o Pluto
o BurchED
o available
o Ebay
o 2600 on a chip
o arcade games
o Chess
o Cracking DES
o wealth
o opencores
o Pong
o Icarus Verilog
o Also by the

Display: Sort:
A Verilog Introduction for Hackers | 80 comments (65 topical, 15 editorial, 2 hidden)
What's going on? (none / 2) (#1)
by the on Fri Feb 27, 2004 at 09:35:31 PM EST

I previewed that and all the code came out nicely. But when I submitted it looked quite different with some of the HTML being garbled. Is scoop's formatting buggy?

The Definite Article
Eh? (none / 2) (#3)
by the on Fri Feb 27, 2004 at 10:02:09 PM EST

The plot thickens. Now it looks fine again (apart from losing the indenting which was there in preview) without me doing a thing. Hmmm...

The Definite Article
[ Parent ]
Quite clearly, (1.50 / 4) (#8)
by For Whom The Bells Troll on Sat Feb 28, 2004 at 04:04:43 AM EST

your article isnt definite?

The Big F Word.
[ Parent ]
Yes. [nt] (none / 1) (#21)
by Aaron Aaronnson on Sat Feb 28, 2004 at 08:13:59 PM EST

[ Parent ]
Do you use proxomitron or other popup killer? (none / 0) (#47)
by localroger on Sun Feb 29, 2004 at 05:46:43 PM EST

Proxomitron mangles some of Scoop's code. I have to bypass it when posting to K5.

What will people of the future think of us? Will they say, as Roger Williams said of some of the Massachusetts Indians, that we were wolves with the min
[ Parent ]
Cute (none / 0) (#12)
by Psychopath on Sat Feb 28, 2004 at 05:07:43 PM EST

I really like the article and it whets the appetite to try it out! This story will go into my personal text archive :)

Are this PIC chips also FPGAs or CPLDs? Or are they something different?

The only antidote to mental suffering is physical pain. -- Karl Marx
Another question.. (none / 0) (#13)
by Psychopath on Sat Feb 28, 2004 at 05:10:10 PM EST

Are there some free (or at least cheap) simulators for a thing like that available?

And yes, I noticed my mistake in my comment. These, not This :O
The only antidote to mental suffering is physical pain. -- Karl Marx
[ Parent ]
PIC chips... (none / 0) (#16)
by the on Sat Feb 28, 2004 at 06:20:49 PM EST

...are basically just microcontrollers - ie. simple CPUs with some extra I/O hardware and built in RAM and flash memory. There is a free simulator...I'm going to mention it in the next version of the story.

The Definite Article
[ Parent ]
Does that mean.. (none / 0) (#17)
by Psychopath on Sat Feb 28, 2004 at 06:32:35 PM EST

..that PICs are not as flexible but perhaps a bit easier to start with?
The only antidote to mental suffering is physical pain. -- Karl Marx
[ Parent ]
They're a different kind of thing (none / 1) (#19)
by the on Sat Feb 28, 2004 at 06:53:26 PM EST

If your goal is to actually build a simple piece of hardware immediately then a PIC chip is a good way to go. Actually, I prefer the Atmel AVR RISC chips. Try this for an introduction. If you want to work at a much lower level and require lots of high speed and complex I/O, then CPLDs or FPGAs are better.

For example - it is possible to implement a video game by connecting a PIC or an AVR directly to VGA in on a monitor. But it's extremely difficult to get the video timing right as every instruction takes a different amount of time and you're generating the signal for every single pixel in software. On an FPGA or CPLD you can make the video hardware run in parallel with the game logic and save yourself having to worry about how the game logic interferes with the video timing.

The Definite Article
[ Parent ]

Thanks! (none / 0) (#20)
by Psychopath on Sat Feb 28, 2004 at 07:23:52 PM EST

Thank you for the explanation as well as for the link to the other k5 story!
The only antidote to mental suffering is physical pain. -- Karl Marx
[ Parent ]
Microcontrollers vs programmable logic (3.00 / 4) (#22)
by BenJackson on Sat Feb 28, 2004 at 08:14:17 PM EST

A PIC has built in flash (for programs and data) and a little RAM and a ton of nice peripherals (depending on the chip any of a number of serial busses, analog/digital converters, PWM out, counters, timers, even USB). They are packed with features that save you external components, like built-in power-on/reset timers (to delay startup until power is stable), brown-out detection, internal clocks of various flavors, internal pullups for some inputs, etc.

PICs come in easy to prototype DIP packages from 8 to 40 pins. The modern 8 pin ones are particularly neat, they manage to have 6 IO pins plus power and ground because they can (at your option) handle many functions internally (clock, reset) that would otherwise require pins. PICs work at a wide range of voltages, and don't even really require good power regulation for many applications.

A FPGA is a blank slate. Most don't even have flash memory and will require a few external components just to start (some flash, a clock, a reset circuit, maybe some RAM, well regulated power, etc). You can make them do just about anything, including act like a CPU (eg Xilinx MicroBlaze/PicoBlaze cores). If you go that route you can even add new instructions to your CPU. They require vastly more power than PICs. Since they're programmable hardware there are many types of busses you can include support for (assuming you can write it or acquire a core for it). Some types of peripherals just can't be emulated this way, although there are tricks.

Most FPGAs come in very prototype-unfriendly packages. It's not feasible to get one running on a breadboard (as you could with a PIC). Most have 100 or more closely spaced pins (or totally inaccessible balls on the bottom). Even if you etched your own board you will need a lot more electronics expertise to interface successfully with an FPGA. You will want to buy a dev board to play with one.

CPLDs are 'glue logic' type chips. They have flash programmability, but very very few 'flops' (flip-flops). A big CPLD might have on the order of 50-100 (say 1-2x the pin count) as compared to an FPGA that might have thousands or tens of thousands. You can theoretically do anything on a CPLD that you can on a FPGA (though the FPGA may have specialized helpers like adders that will be done 'manually' in a design when fitted to a CPLD). However, even tiny designs (for example a PS/2 port, available on opencores) are a challenge to squeeze into even a medium-large CPLD.

[ Parent ]

Books? (none / 0) (#26)
by Psychopath on Sat Feb 28, 2004 at 08:50:32 PM EST

Thank you for your torough explanation.
So would it be correct to say CPLDs are "stripped down" version of FPGAs? More or less like FPGAs, but not as powerfull, more limited?

Do you have any book recommendations on that topic? Actually I don't really mind whether about FPGAs or CPLDs or PICs or Atmels - just in that direction, prefereably for beginners.
The only antidote to mental suffering is physical pain. -- Karl Marx
[ Parent ]
Check out piclist.com (none / 0) (#29)
by BenJackson on Sat Feb 28, 2004 at 11:01:54 PM EST

For getting started with PICs or AVRs try piclist.com or avrfreaks.com. If you want a small investment and plan to make blinky lights, that's the way to go.

So would it be correct to say CPLDs are "stripped down" version of FPGAs? More or less like FPGAs, but not as powerfull, more limited?
There are many internal differences, but they are largely hidden from you by the "fitter", the program which takes your high level design (say in Verilog or VHDL) and translates it into hardware-specific settings. A CPLD is a "complex" PLD, or "programmable logic device", like a GAL or PAL (gate/programmable array logic). You might use an FPGA to simulate a whole new CPU design, or bus interface chip, or as a specialized co-processor. A CPLD's role would be more along the lines of providing address decoding logic on a motherboard, or replacing several 74-series components.

A PIC is mostly used in embedded devices. Remote controls, kitchen appliances, garage door openers, medical devices, etc.

[ Parent ]

Gotchas. (3.00 / 12) (#27)
by crankie on Sat Feb 28, 2004 at 08:56:01 PM EST

Nice introductory article. I used to write FPGAs (in VHDL) for a living. Given the fact that this is dubbed "an introduction for hackers", I'd like to add a few points of my own that refer specifically to things that can catch you off-guard if you come from a software background.

First, and probably most importantly, is the reset signal. On power-up, the FPGA will assert a reset line. It is vitally important that this be used to place every item in a known state. Uninitialised flip-flops can wreak havoc in what might seem like an otherwise straight-forward design.

Next is the matter of glitches. Take the following example in pseudocode:

A = X;
B = Y;
X = NOT Y;
C = A XOR B;

Now, from this, C is a tautology. Any sensible person would assume the C will be a constant, never changing value of 1. And they would be wrong. If Y changes, value, then as a result, X will change value. But this is hardware and non-sequential, but parallel evaluation occurs. Each time a signal changes, there is a propagation delay before the signals that depend on this signal are updated. This delay is not something that can be easily quantified. Indeed, the same code section will synthesise differently if the compilation is given different initial conditions. If we assume initially that it takes 1ns for every transition, then what will happen is as follows:

Y changes.
1ns later, X changes.
During that 1ns when X and Y are out of sync, the inputs to the circuit which drive signal C are the same.
C will glitch low for 1ns.

So it's quite important that you ensure that unexpected glitches don't screw you up. This is particularly important for code such as

always @(posedge C)

As this glitch will be caught by this statemeent and will have unwanted knock on effects. There are several ways to avoid such nasties. If there is sufficient interest, I may do a separate write up on such techniques. They're a bit beyond the scope of a comment though.

Other topics of interest include building effective state machines, maximising the possible operating frequency of the circuit, understanding how your code maps to the underlying hardware, functional simulation versus timing based simulation etc. Like I said, if people are interested in this, I'll do a more complete separate write-up.

"The great thing about hardcore socialists is the silence they emit once they start earning a decent wage." - tombuck
Please do. -nt (none / 0) (#31)
by tzanger on Sun Feb 29, 2004 at 09:55:29 AM EST

[ Parent ]
indeed a common intitial misperception (none / 1) (#34)
by X3nocide on Sun Feb 29, 2004 at 12:01:50 PM EST

I too fell to the variables gotcha. The trick is not to think of them as variables but as signals. Signals constantly revaluated and conviently named. If I recall correctly, VHDL has a type "SIGNAL" for this, and typically this is what one wants.

Its been quite some time since the class they have us take on basic design; I'd have continued further but the next course in sequence wanted engineering physics 2.

[ Parent ]

Registers are like variables (none / 0) (#54)
by the on Mon Mar 01, 2004 at 10:04:47 AM EST

The real gotcha, I think, is to note that a signal can only be set from one place. When writing software we're so used to the idea that a variable's value can be set anywhere. For example consider a simple CPU implementation. You might want to set the address bus for various reasons: to set the address of the next instruction you're going to read from RAM, to set the address of the next address you're going to read into a register, to set the address of the next address you're going to write from a register and so on. With a hardware design language all of these have to be set from the same place and that means you have to think about your overall structure in a quite different way.

The Definite Article
[ Parent ]
Not quite. (none / 0) (#55)
by crankie on Mon Mar 01, 2004 at 10:11:44 AM EST

The signal can be set in two difference places, provided that the items driving the signal don't interfere with each other i.e. one driver tri-states its output before the other driver attempts to drive a value onto the signal.

Then there's also the world of pain that is open-collector outputs...

"The great thing about hardcore socialists is the silence they emit once they start earning a decent wage." - tombuck
[ Parent ]
When I tried placing tri-states... (none / 0) (#56)
by the on Mon Mar 01, 2004 at 02:06:23 PM EST

...in my designs they were rejected bat synthesis. I'm guessing that you can only have tri-states on the I/O lines for the low end components I am using. Or I think there was an option to fake them using two two-state wires to represent one three-state wire.

The Definite Article
[ Parent ]
Tri-states .... (none / 0) (#58)
by taniwha on Mon Mar 01, 2004 at 05:46:41 PM EST

As a rule tristate on-chip is evil (floating nodes can and will result in power problems and even thermal runaway).

I've done enough chips now to know not to trust synthesis tools in this area. Better to build a pad model that models the external pad structures and hand instantiate each and every pad (then you can move them into pad-ring blocks for physical laytout). Signals that might go to the pad include data in, data out, tristate enable etc etc Flops in pads are also a good idea and a great way to manage cross-die skew

[ Parent ]

Now you're getting too advanced for me... (none / 0) (#59)
by the on Mon Mar 01, 2004 at 05:54:33 PM EST

Maybe you'd like to write a sequel to my story as hardware engineers seem to keep this stuff secret from software engineers. :-)

The Definite Article
[ Parent ]
They'll tell you if you want them too.... (none / 0) (#62)
by gte910h on Tue Mar 02, 2004 at 12:09:48 PM EST

but its not the type of simple thing you learn over coffee. Its not elegant like the interiors of a compiler (which I've explained to hardware guys over lunch). Its messy like the 80's accounting system that half in COBOL and half in FORTRAN-77 for some godforsaken reason.

[ Parent ]
hardware vs software (none / 2) (#78)
by taniwha on Wed Mar 10, 2004 at 05:52:54 PM EST

but I am a software engineer (sort of) .... I live in this strange inbetween world, I have 10 years chip design experience, 15 doing software (mostly kernel and networking stuff) ... oh yeah and I've written a couple of verilog compilers ....

I find that describing this stuff to software engineers is pretty easy (given a nearby white board), I once had a bunch of software guys finding transistors and unfolding the logic in a gate library on a plot on the wall after 5 minutes of "here's a transistor, when there's a voltage here nothing flows, the rest is wires"

In my experience the hardware people are equally as mystified by the software guys (and a bit aghast at their usual 'flippant' approach to testing and bug fixing). I find it hard to explain that most big software systems are orders of magnitude more complex than big hardware ones. I think that this is because most hardware guys are up to their eyes in the complexity and see it in detail while the software guys sort of ride over it as abstraction.

By the way I heartily reccomend a stint at hardware design to kernel people - after the second chip all those kernel timing races become obvious and red flags start going up in all the right places while you code.

[ Parent ]

Ah, the simplicity of transistors. (none / 0) (#80)
by crankie on Thu Mar 11, 2004 at 04:44:31 PM EST

I work in analogue electronics now. How I miss the simplicity of thinking of them as just plain on or off.

"The great thing about hardcore socialists is the silence they emit once they start earning a decent wage." - tombuck
[ Parent ]
Tri-state on chip (none / 0) (#60)
by TheOnlyCoolTim on Mon Mar 01, 2004 at 07:44:44 PM EST

Do you mean having the chip use tri-state lines internally? I'm just curious about this, I don't really know much about this stuff yet. They want me to learn all sorts of chemistry and physics and stuff first.

"We are trapped in the belly of this horrible machine, and the machine is bleeding to death."
[ Parent ]

Correct (none / 0) (#61)
by dn on Mon Mar 01, 2004 at 09:27:13 PM EST

If you don't drive a tri-state line to a proper logic level, it floats to some intermediate voltage. That turns on the transistors in all the receivers listening to it, and quite likely a lot of transistors downstream too. In an FPGA with a million transistors, power consumption can get completely out of hand.

IIRC, some FPGAs have holding latches, high-resistance flip-flops which pull the tri-state line to a valid logic level, but can easily be overpowered by the real line drivers. That minimizes the time spent in the intermediate state.

    I ♥

[ Parent ]

yes (none / 0) (#77)
by taniwha on Wed Mar 10, 2004 at 05:19:03 PM EST

searching for 'floating nodes' and unexpected power drains is a normal part of bringing up a new chip. You also have to be carefull during scan since logic which might normally circumvent this can get bypassed

[ Parent ]
I'm interested. --nt (none / 0) (#41)
by aragorn on Sun Feb 29, 2004 at 01:38:09 PM EST

[ Parent ]
i'm interested too... n/t (none / 0) (#51)
by Danse on Sun Feb 29, 2004 at 09:30:27 PM EST

An honest debate between Bush and Kerry
[ Parent ]
Interested! nt (none / 0) (#71)
by pyro9 on Fri Mar 05, 2004 at 10:19:25 PM EST

The future isn't what it used to be
[ Parent ]
Simulation (none / 1) (#32)
by Wouter Coene on Sun Feb 29, 2004 at 11:21:23 AM EST

For people more into VHDL (mainly used in Europe, and IMO a bit more readable than Verilog), SymphonyEDA has an excellent VHDL simulator of which a free edition exists.

For more in-depth simulation, there's an addon to Xilinx' WebPACK called ModelSim, which can simulate a synthesized component. The main disadvantage of this is that your model and your testbench have to be synthesizable.

Usefulness? (none / 2) (#33)
by treat on Sun Feb 29, 2004 at 11:51:37 AM EST

Can I do something useful with an FPGA? Will certain algorithms run (much) faster than on a general purpose CPU?

I've only heard of people using FPGAs to prototype designs that will be put to silicon. This is for cost savings with high volume.

Nothing I'm doing will be built with high volume. Even if an FPGA is cheaper than a general purpose CPU, it won't be by much. To be useful for me, I would need a project that is intractable on a general purpose CPU, due to performance or other considerations.

I'm all for doing things for learning and fun. But the choice of design has to make good engineering sense.

Re: Usefulness? (none / 0) (#35)
by Wouter Coene on Sun Feb 29, 2004 at 12:30:27 PM EST

Can I do something useful with an FPGA? Will certain algorithms run (much) faster than on a general purpose CPU?

Algorithms that can be easily implemented using binary logic, can be paralellized and aren't actually too complex for a simple FPGA are amongst the options. For example, someone has written a pipelined DES implementation which is a lot faster than the average CPU (sorry, can't seem to find the URL at the moment). This is probably also doable for stuff such as AES.

Another option is to build your own CPU and no longer be bothered by crappy existing CPU implementations :)

[ Parent ]

Yes, you can. (3.00 / 4) (#36)
by crankie on Sun Feb 29, 2004 at 12:31:55 PM EST

FPGAs are, as you rightly point out, often used for prototyping projects that utlimately get put into custom silicon in the form of an ASIC (Application Specific Integrated Ciruit). Indeed, the major FPGA vendors, including Xilinx and Altera, have a process in place for specifically migrating from an FPGA to an ASIC using their own silicon foundries. Having said all of that, the volume required for this to become cost effective is quite high.

The major benefit of an FPGA is not so much as a replacement for a CPU but as a replacement custom IC. The FPGA that I spent most time working on was designed primarily for implementing a very specific algorithm which, in earlier versions of the product had been implemented in software. The FPGA solution was well in excess of an order of magnitude faste. Primarily, this was due to it's ability to run operations in parallel.

Another example of very specific algorithm acceleration using FPGAs can be found in an Altera chip. I've been out of the loop for a while so I can't remember the exact details, but Altera provided a massive FPGA within which you could embed a RISC processor using a pre-coded core. The really cleaver thing about this processor was that its assembly language had 5 user-definable op-codes. In order to accelerate your algorithm, you had the ability to define a logic circuit which could then be plugged into the processor core and so used as a user-defined opcode. If done correctly, a task which would have taken many clock cylces using standard ops could be done in a single clock cycle using a user-defined op.

"The great thing about hardcore socialists is the silence they emit once they start earning a decent wage." - tombuck
[ Parent ]
Xilinx Virtex II (none / 0) (#39)
by crazycanuck on Sun Feb 29, 2004 at 12:59:47 PM EST

the Virtex II can have up to 4 embedded PowerPC cores running at 400 MHz

[ Parent ]
Altera vs Xilinx (none / 0) (#43)
by crankie on Sun Feb 29, 2004 at 04:49:18 PM EST

Yes, I've looked at the Virtex II. Xilinx decided to embedd the PowerPC cores as hard cores built into the silicon with FPGA logic connected to them. To do this, they had to use, IIRC, IBM's fab. As a result, they tended to be a bit more pricey than the Altera chip which Altera could build in their own fab. Also, with the Virtex II, you have the PowerPC(s) whether you want them or not, thus reducing flexibility.

On the other hand, the hard-core approach i.e. embedding an actual processor rather than the soft-core approach i.e. synthesising a processor with FPGA logic, does run faster. It's swings and roundabouts. Depends on what you need from the system.

"The great thing about hardcore socialists is the silence they emit once they start earning a decent wage." - tombuck
[ Parent ]
IBM fabs (none / 0) (#46)
by crazycanuck on Sun Feb 29, 2004 at 05:20:40 PM EST

the advantage of doing stuff in IBM's fabs is that Xilinx has FPGAs build in 90 nanometer technology...

[ Parent ]
90nm (none / 0) (#74)
by dmlandry on Mon Mar 08, 2004 at 10:57:10 PM EST

Just FYI, the Virtex II Pro parts are designed in 130nm. The Spartan 3 series is 90nm. Both of these parts are being primarily fabbed by UMC. IBM is having a hard time providing parts to Xilinx when and as much as they want them.

[ Parent ]
you don't get it (3.00 / 4) (#37)
by crazycanuck on Sun Feb 29, 2004 at 12:56:28 PM EST

an FPGA and a general purpose CPU are two very different things.

what you're basically asking is "will my blender do things faster than my oven?"

a general purpose CPU is a processing unit with general instructions. it's not optimised for a specific operation. it executes arithmetic and logical instructions and I/O. it's a hardwired chip. you can't change it. it's also fast for what it does, which is general purpose stuff.

an FPGA, on the other hand, is a re-configurable chip. it's more like a look-up table.
an FPGA can be used to implement a general purpose CPU, but it will run slower than an ASIC. That's not the purpose of an FPGA.

take signal processing, for example. you can write a C program that implements a fourier transform, or you can write VHDL code that describes the digital hardware needed to do a fourier transform. the FPGA will then implement the digital logic. the hardware (FPGA) fourier transform will be faster than the general purpose CPU fourier transform. of course if you were to build an ASIC DSP that implements the same logic as the FPGA, the ASIC would be faster.

the advantage of the FPGA is that it can be reconfigured on the fly. for example routers use several FPGAs and they can change routing algorithms in the field. if you need to modify the way your router functions, you can remotely turn it off for a minute, upload the new configuration file and restart the router.

[ Parent ]

Things you could do with an FPGA or CPLD (none / 2) (#42)
by the on Sun Feb 29, 2004 at 01:56:23 PM EST

FPGAs and CPLDs are great for large volumes of I/O. With a microcontroller you have a bottleneck coming from the (at most) one instruction you can execute per clock cycle. For example it's easy to build a simple frame buffer that connects straight to a VGA monitor with an FPGA. If you wanted to add a basic VGA frame buffer to a Palm or Pocket PC it wouldn't be too hard with an FPGA. If you wanted to control a large number of servos (say 30) with a small package an FPGA would be ideal too. If you wanted to crack DES quickly a $1000 FPGA board on a PCI card would probably be a great way to go. They're a great way to go in combination with a microcontroller. If you wanted a microcontroller to talk to many different peripherals asynchronously then an FPGA can provide what you need. You could probably get an ethernet port, a buffered PS/2 port, a rudimentary VGA frame buffer, a serial port onto a single small FPGA without too much trouble.

I decided to play with these devices just for educational value. You rapidly discover it's not the same as software engineering, even if the languages look like programming languages, and it opens your mind to a new way of looking at problems.

The Definite Article
[ Parent ]

Plug for Altera (none / 1) (#38)
by philwise on Sun Feb 29, 2004 at 12:58:22 PM EST

Altera have a freely downloadable version of their very nice IDE, Quartus II. It is limited to the cheaper end of the product line, but includes all the chips most people are likely to want to use. It only works under Windows but the full version work under Linux too.
(presenter) "So, altogether now, what are we?"
(audience) "We are all Free Thinkers."
VHDL (none / 1) (#40)
by crazycanuck on Sun Feb 29, 2004 at 01:04:36 PM EST

I know VHDL and not Verilog.
What is this "useless glue logic" of which you speak?

(BTW: a VHDL model is required for any chip/system submitted to the US military. that's how VHDL started, in the DOD)

VHDL is extremely verbose (none / 1) (#44)
by the on Sun Feb 29, 2004 at 04:55:07 PM EST

I played with VHDL for on and off for a few months and every time I had to write some code I had to look up in a reference guide all the syntax required to implement even the simplest task. After I had written one piece of Verilog I was able to write countless more without having to think "I wonder what the syntax is for this".

Rewrite my sample code above as VHDL and see how much more text you need to type. You have to define an ENTITY and then a separate ARCHITECTURE. Many of the operators need to be written as fully expanded text which I personally find hard to read. Compare VHDL: d_in : IN STD_LOGIC_VECTOR(7 DOWNTO 0); to input [7:0] d_in;. I can parse the latter at a single glance. I have to scan the former like reading a novel! And in VHDL you are forced to type the same variable names over and over again when you implement and instantiate modules.

But at the end of the day they seem to be isomorphic.

The Definite Article
[ Parent ]

input vs std_logic_vector (none / 1) (#45)
by crazycanuck on Sun Feb 29, 2004 at 05:18:34 PM EST

std_logic_vector(7 downto 0) defines an array of size 8 of type std_logic_vector.

std_logic_vector is a vector type of std_logic.
std_logic can take many values besides 1 and 0, for example U (uninitialised), X (undefined, when multiple drivers exist on a bus), Z (high impedance) etc.
You could change std_logic_vector to bit_vector, for example, which can only take values 1 and 0.
or you could replace it with Signed, or Unsigned, which behave differently in arithmetic

what type is "input" ?

being too verbose is better than being too cryptic.

[ Parent ]

You say tomato I say tomato (none / 0) (#48)
by the on Sun Feb 29, 2004 at 06:17:29 PM EST

what type is "input" ? I'll give you a clue. This is an input to a digital electronic device that uses two voltage levels to represent binary data. :-)

being too verbose is better than being too cryptic. It's all down to taste. I don't find verilog cryptic at all because I come from a C background. VHDL suits many other people better. I like vi. You might like emacs. If you're a hacker with a C background and what to hack something together Verilog is great.

Seriously though - I come from a school of thought that says that compact is better than verbose. I'm a mathematician. The history of mathematics is partly the history of people finding more and more compact ways to say the same thing. I could write a long essay on the payoff that this brings. A nice example is the reduction of Maxwell's original full page of equations of electromagnetism to the modern formulation as two equations : dF=0 and d*F=J. I can 'see' what the latter means. The original is a verbose mess that means nothing to me.

The Definite Article
[ Parent ]

if it takes 2 values (none / 1) (#49)
by crazycanuck on Sun Feb 29, 2004 at 06:35:51 PM EST

then how do you know, in a simulation, that you made a mistake and one signal is being assigned from multiple sources (multiple bus drivers)?

how do you make a tristate if it can only have 2 levels?

[ Parent ]

Must resist being baited...must...resist... (none / 1) (#50)
by the on Sun Feb 29, 2004 at 08:04:21 PM EST

how do you make a tristate if it can only have 2 levels?
Verilog is strongly typed with a variety of types and signal levels. which are all well documented. It just has easy to use defaults if you want to hack something together. (Hence the title of the article.) There is a brief description here for what the Xilinx synthesizer does though I know that that is a simplified representation of what's actually a more complex system.

When I try to drive a signal with multiple sources in either VHDL or Verilog I get an error message from the synthesizer. That's the sum total of my knowledge in this area.

As I say, I'm no expert, just a hacker who set out to achieve some basic goals and completed them successfully. But I think Verilog and VHDL provide much the same facilities, they just represent their descriptions differently.

But don't trust anything I say as I've just implemented some basic projects. I'm just hoping this article prompts people to learn this stuff 'cos it's kinda fun (and easier than some electrical engineers make it out to be) and if they find they eventually prefer VHDL then good for them - I've prompted them to learn a new skill.

The Definite Article
[ Parent ]

'useless' (none / 0) (#52)
by garlic on Mon Mar 01, 2004 at 07:48:12 AM EST

Useless is relative here. It's useless to you because you aren't trying to have a behavioral architecture and a back-annotated architecture for the same entity, or multiple configuration files or the like. I agree, for the newcomer, it's a little confusing as to why it would be done that way. I also agree, that VHDL and verilog are basically equivelent.

HUSI challenge: post 4 troll diaries on husi without being outed as a Kuron, or having the diaries deleted or moved by admins.
[ Parent ]

OpenSores (1.00 / 6) (#53)
by dimaq on Mon Mar 01, 2004 at 09:14:55 AM EST

the author is welcome to mention that nearly all the software one might use to make the cycle of design, verification and synthesis is proprietary and runs on propriatary operating systems. and that *all* of usable software is/does.

The Xilinx tools... (none / 0) (#57)
by the on Mon Mar 01, 2004 at 02:30:04 PM EST

...run under Wine. They've apparently said they were going to develop Linux native tools but I don't think they've materialized yet. The sad thing is that the Windows code is largely just a port of what was clearly once Unix code.

The Definite Article
[ Parent ]
Actually ... (none / 0) (#75)
by jbuck on Tue Mar 09, 2004 at 06:24:12 PM EST

For ASIC design, Linux is much more heavily used than Windows (as is Solaris). FPGA design, Windows use is more widespread, but even there, most tools are now available for Linux.

[ Parent ]

a list of tools available for linux please? (none / 0) (#79)
by dimaq on Thu Mar 11, 2004 at 05:55:03 AM EST

[ Parent ]
VHDL and programming mindset (none / 1) (#63)
by Paul Hodson on Tue Mar 02, 2004 at 03:37:14 PM EST

Interesting article. For quite a while I've been interested in learning Verilog (I do all my FPGA development in VHDL), and a little kick in the right direction is always welcome.

One thing I very much like about VHDL is how it is different from most programming languages (Ada aside). It forces that the programmer adopt a different mindset when writing logic, which to me is a great thing since "hardware programming" is very different from software programming.

When you're "writing" hardware (as is the case for FPGAs and other reconfigurable devices), you have to design your code such that it operates in parallel, or you have to at the very least be aware of what will operate in parallel or in sequence. VHDL, being a structurally and syntactically different language from C and others, already starts the process of converting the mindset. I find its differences very refreshing.

You'll find Verilog is pretty much the same... (none / 0) (#64)
by the on Tue Mar 02, 2004 at 03:50:39 PM EST

...from the point of view you're describing. While Verilog has C-like syntax and VHDL has Ada-like syntax they really do much the same thing, as far as I understand.

The Definite Article
[ Parent ]
You'll find BASIC is pretty much the same as C (none / 0) (#65)
by thoglette on Wed Mar 03, 2004 at 08:55:31 AM EST

..they really do much the same thing, as far as I understand.
<Troll> Yeh, and BASIC does pretty much the same thing as C </troll>

While the differences appear religious, in their standard forms VHDL is a significantly more powerful language. (Structured types, anyone?)

Yes, the flip side is you do need to grok more concepts. And '87 has some quirky non-orthoganalities in the syntax (I can never remember where to use a plain "END;", where to use "END my_thing;", and where to use "END language_construct")

However the pivotal chip-synthesis tool vendors have traditionally supported VHDL poorly (eg. records on ports) so much VHDL code ends up looking like Verilog. (We used to have a series of preprocessors converting concise RTL code forms into stuff that XYZ's synthesiser could digest)

To it's credit, the Verilog community has managed to convert more good ideas into start-ups than the VHDL group (eg. superlog). While in my own working environment we significantly extended 1076 (we needed to generate reusable, known-good code fast) and I never got involved in the language forums - something I deeply regret.

The real problem in ASIC/FPGA and digital systems engineering is verification and particularily what's known as the verification gap: the massively increasing distance between available chip real estate and the productivity of the average ASIC engineer. A major shift in behaviour is going to have to happen - equivalent to the move from C/C++ to Perl/Python. (Even at pennys for the hour you can't hire enough engineers to do a 45nm chip from the ground up and expect it to work).

But if you really want to "hack" use SystemC - all the problems of C++ are available to you and you get to ignore things like synchronisation and unclocked logic :-)

[ Parent ]

No troll at all (none / 0) (#66)
by the on Wed Mar 03, 2004 at 12:52:11 PM EST

C and Basic are conceptually pretty well identical. You have a bunch of statements executed in order. Sometimes you can even use the same syntax, eg. a=b+c, and it means the same thing. Languages like Haskell, Pascal and Prolog aren't just syntactically different, they're completely different conceptually. If you say a=b+c in Haskell or Prolog you mean something quite different from what you mean in Basic, C or Verilog.

So yes, Verilog lacks structs, but conceptually I don't see a great difference between the languages.

The Definite Article
[ Parent ]

Conceptually, yes. Structurally, no (none / 0) (#68)
by Paul Hodson on Thu Mar 04, 2004 at 01:51:11 AM EST

My point in my original post was that VHDL looks very different from most standard programming languages, which is a feature I very much like.  Not that Verilog is quite like C, but it much more closely resembles it than does VHDL.

The thing is, yes, conceptually the languages are quite similar.  The basic goals for designing in VHDL are the same as those for designing in Verilog: You want to program custom hardware on an FPGA.  The way the languages go about doing this is different.  There are different capabilities available and very different syntaxes, among other things.

Each language has its merits.  Going back to my original point, one of the things I most love about VHDL is how it forces me as a hardware programmer to change the way I think about designing.  I'm a fan of the language (that likely comes as no surprise) but I definitely want to learn more about Verilog and SystemC, too.  It never hurts to know more.

[ Parent ]

But VHDL *does* look just like a regular language (none / 0) (#69)
by the on Thu Mar 04, 2004 at 09:32:20 AM EST

Take a look at this multiplier. That's regular Ada programming, not VHDL!

The Definite Article
[ Parent ]
Most (none / 0) (#70)
by Paul Hodson on Thu Mar 04, 2004 at 02:03:49 PM EST

Since, conveniently enough, I'm only familiar with Ada in passing, I have the luxury of neglecting it.  You're right, though.  That's why I said "Ada aside" in my main post.  To the best of my knowledge, it isn't a common enough language to get a lot of people confused between hardware programming and software programming when looking at raw code.

Alas, to the detriment of my original point, Ada is so similar to VHDL in terms of syntax that it makes Verilog and C look only distantly related.  Again, however, since Ada is fairly uncommon (so far as I know), this shouldn't be a problem for most people.

[Thanks for your interesting points, by the way.]

[ Parent ]

VHDL for synthesizeable code (none / 1) (#67)
by khayman on Wed Mar 03, 2004 at 01:43:40 PM EST

I find the syntax imposed by VHDL help people coming from a sw background making synthesizeable code.

FPGA versus CPLD... (none / 0) (#72)
by Cryptnotic on Fri Mar 05, 2004 at 10:40:55 PM EST

One problem with FPGA's is that when you power them up, they're blank. When you're developing, this is fine since you'll be downloading a configuration from your PC onto the FPGA for testing. When you're making a product, it's a bit of a problem and increases the cost of your design. Some FPGA's will automatically configure themselves via something like a serial EEPROM, so you put an EEPROM onto the board and the FPGA configures off of that. PLD's (Programmable Logic Devices) or CPLD's (In-system Configurable PLD's) are another option, but they are nowhere near the density of FPGA's. On the other hand, they are cheaper. If all you need is a couple of logic gates or flip-flops, then that's what you'd use. No one uses discrete logic anymore. Well, that's not entirely true. Discrete logic chips are dirt cheap (3 cents for a NAND gate maybe?). But if you need more than a few of them or you need some configurability, then you'll use a PLD variant.

Not quite true (none / 0) (#73)
by crankie on Sat Mar 06, 2004 at 11:21:09 AM EST

While most FPGAs are indeed programmed at boot time (which can be an awful bitch in certain applications I might add) there are FPGAs that are flash based and retain there config through power cycles, though, to be fair, they tend to a bit smaller and occasionally blur the line between FPGA and CPLD. There are also FPGAs that are OTP (One-Time Programmable), such as those offered by QuickLogic.

Of course, the major problem with these is development. You have to have a very solid simulation enviornment and even then, the chances of getting it right first time are kinda slim. Also, because they come in BGA (Ball Grid Array) packages with many hundreds of connections, replacing them is a chore. In general, for the purpose of prototyping, a socket is needed, which takes up a bit more PCB area than the actual chip, meaning that you'll probably have to spin two different PCBs, one for development and one for production. Also, when last I used them, these sockets tended to be a tad unreliable at times. Hopefully, they've progressed a bit since then,

"The great thing about hardcore socialists is the silence they emit once they start earning a decent wage." - tombuck
[ Parent ]
Flash Based FPGAs (none / 0) (#76)
by doubled on Wed Mar 10, 2004 at 01:18:14 PM EST

In addition to the Quicklogic OTP FPGAs mentioned by my neighbor ACTEL makes flash based FPGAs (see their ProAsic and ProAsic+ series) that are live at power up. FPGAs are preferable to CPLDs in some uses due to a much higher number of resources (gates/registers/embedded ram) available.

[ Parent ]
A Verilog Introduction for Hackers | 80 comments (65 topical, 15 editorial, 2 hidden)
Display: Sort:


All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!