The last few weeks I’ve been musing about how FPGAs and Verilog are working their way into many embedded systems. I mentioned last time that it is much simpler to describe logic in a high-level language like Verilog (or VHDL) instead of drawing huge schematics. The wires required to hook up even a small CPU would quickly look tangle like a pretzel – or maybe a plate of spaghetti (not to mention real life wires; see Steve Chamberlin’s Big Mess ‘o Wires computer, for example).
I also mentioned that you have to build a crystal radio before you can start working on a multichannel digital stereo system. To that end, this time I want to show you what some very simple logic circuits in Verilog look like.
A Verilog “program” consists of modules. Modules can contain other modules or basic Verilog statements. Typically, a Verilog program has one of two possible purposes. In some cases, an engineer writes Verilog to simulate a system. A simulation often has commands that you use to write data to a file, for example. It might have specific timing delay information. Frequently, the main part of a simulation looks suspiciously like a C program where the test fixture (or test bench) steps through a sequence of commands.
Other Verilog modules are made for synthesis. That is, some tool is going to parse the Verilog and generate an electronic circuit from it and then further process that circuit to create the programming file for an FPGA. This is, of course, highly vendor-specific and not all tools support all the same synthesis constructs. In general, you will have to use a very particular subset of Verilog if you expect your code to be synthesizable. Frequently, a test bench will instantiate synthesizable modules to test. That’s ok. The Verilog simulation can do anything. The synthesis is where certain operations won’t work.
Keep in mind, though, there’s no official way to tell which kind of module you are looking at. If you know what synthesis tool you are using and you know what statements are not allowed for synthesis using that tool, then the presence of forbidden commands means the module is not synthesizable (by that tool). Even then, some synthesizers simply ignore certain constructs, so it can still be hard to tell if the developer intended the module to be dual-purpose or not.
To start, let’s consider a simple circuit that uses two AND gates, each with two inputs. In Verilog, there are at least two ways to accomplish this task. First, you need a module statement that defines the inputs and outputs:
module and_test(output y, input in1, input in2, input in3);
This is the “new” style of writing modules (analogous to ANSI C). Older versions used a more K&R C-like style, and you may still see examples of that on the Internet.