Debugging of Verilog Hardware Designs on Alteras DE2 Boards

This tutorial presents some basic debugging concepts that can be helpful in creating Verilog designs for imple-
mentation on Alteras DE2 boards. It shows how Quartus II tools can help in the debugging task.
The reader is expected to be familiar with the RTL Viewer and Signal Tap II Logic Analyzer tools included in
Alteras Quartus II software. Also, a basic knowledge of simulation is needed.
Contents:
Example Circuit
Quartus II Tools for Use in Debugging of Hardware Designs
Debugging Concepts
Sources of Errors in Verilog Designs
Design Procedure
1
Designers of digital systems are innevitably faced with the task of debugging their imperfect initial designs.
This task becomes more difcult as the systemgrows in complexity. The debugging process requires determination
of possible aws in the designed circuits. This tutorial introduces some basic debugging concepts that can help
in designing of circuits specied in Verilog HDL. The tutorial focuses on the debugging of digital hardware. A
related tutorial, Debugging of Application Programs on Alteras DE2 Boards, deals with the debugging of software
programs that are run by Alteras Nios II processor implemented on a DE2 board.
To clarify the concepts used in debugging, we will show how these concepts may be applied to an example
circuit.
1 Example Circuit
To make the tutorial easy to follow, we use a relatively simple digital circuit. Our circuit is a tester that can be
used to test the reaction time of a person to a visual stimulus. The user initiates the test by pressing and releasing
a pushbutton key, KEY
1
. After some delay (of at least four seconds) the circuit turns on a light. In response, the
user presses another key, KEY
3
, as quickly as possible, which results in turning the light off and displaying the
ellapsed time in hundredths of a second on the 7-segment displays on the DE2 board.
A block diagram of the circuit is given in Figure 1. The circuit is designed in hierarchical manner, where a
number of subcircuits are used to implement the simple tasks. This is a good design practice and the resulting
circuit is easier to understand and debug.
Since the pushbutton keys on the DE2 board produce a logic value 0 when pressed, we have chosen to create
inverted signals with more meaningful names as follows:
reset = !KEY
0
request_test = !KEY
1
stop_test = !KEY
3
When the request_test signal goes to 1, the run signal is activated, which enables the counter circuit that generates
the start_test signal after a delay of about four seconds. The start_test signal activates the test_active signal which
causes the green light, LEDG
0
, to be turned on. At this point the four-digit binary-coded-decimal (BCD) counter
starts counting in one-hundredth of a second. It is enabled by a pulse (one clock cycle in duration) produced
every one-hundredth of a second by the counter circuit called hundredth. The four BCD digits, BCD0 to BCD3,
are decoded by the BCD-to-7-segment decoder circuits and displayed on the 7-segment displays, HEX0 to HEX3.
The clear signal, which is generated when either reset or stop_test signal is activated by pressing the respective
pushbutton, brings the control signals run and test_active to 0, which freezes the BCD count at its present value.
The Verilog code for the top-level module, which corresponds to the block diagram in Figure 1, is given in
Figure 2. The module is called the reaction_tester. It instantiates modules for each of the subcircuits shown in
Figure 1. The statements are numbered for ease of reference in the discussion below. The subcircuits are specied
as shown in Figures 3 to 13.
2
Clear
ff_in
Q
control_ff
Clear
ff_in
Q
control_ff
Clear
Enable
Start
delay_counter
KEY
1
KEY
0
KEY
3
run_signal foursec_delay
LEDG
0
Clock
Clear
Enable
BCD_counter
bcdcount
Load
pulse_500k
hundredth
hundredth_sec
sec_100th
bcd
3 0
display
0 6
bcd7seg
digit0
bcd
3 0
display
0 6
bcd7seg
digit1
bcd
3 0
display
0 6
bcd7seg
digit2
bcd
3 0
display
0 6
bcd7seg
digit3
BCD0
BCD1
BCD2
BCD3
HEX0
HEX2
HEX3
HEX1
test_active
test_signal
clear
run
start_test
reset
stop_test
request_test
enable_bcd
Figure 1. The reaction-tester circuit.
3
1 module reaction_tester (CLOCK_50, KEY, HEX0, HEX1, HEX2, HEX3, LEDG);
2 input CLOCK_50;
3 input [3:0] KEY;
4 output wire [0:6] HEX0, HEX1, HEX2, HEX3;
5 output wire [0:0] LEDG;
6 wire [3:0] BCD3, BCD2, BCD1, BCD0;
7 wire reset, request_test, stop_test, clear, sec_100th;
8 wire run, start_test, test_active, enable_bcd;
9 assign reset = !KEY[0];
10 assign request_test = !KEY[1];
11 assign stop_test = !KEY[3];
12 assign clear = reset | stop_test;
13 assign enable_bcd = test_active & sec_100th;
14 assign LEDG[0] = test_active;
15 control_ff run_signal (CLOCK_50, request_test, clear, run);
16 control_ff test_signal (CLOCK_50, start_test, clear, test_active);
17 hundredth hundredth_sec (CLOCK_50, enable_bcd, sec_100th);
18 delay_counter foursec_delay (CLOCK_50, clear, run, start_test);
19 BCD_counter bcdcount (CLOCK_50, request_test, enable_bcd, BCD3, BCD2, BCD1, BCD0);
20 bcd7seg digit3 (BCD3, HEX3);
21 bcd7seg digit2 (BCD2, HEX2);
22 bcd7seg digit1 (BCD1, HEX1);
23 bcd7seg digit0 (BCD0, HEX0);
24 endmodule
Figure 2. Verilog code for the top-level module of the example system.
The subcircuit in the control_ff modules is dened in Figure 3. It generates an output signal that goes high
when the data input ff_in goes high, and then maintains this signal, even if ff_in becomes low again, until it is
cleared by a signal on the Clear input. Note that while the inputs may be asynchronous (being connected to
pushbutton switches), the operation is synchronized by the clock signal. A circuit generated from this code is
displayed in Figure 4.
module control_ff (Clock, ff_in, Clear, Q);
input Clock, ff_in, Clear;
output reg Q;
always @(posedge Clock)
if (Clear)
Q <= 0;
else
Q <= ff_in | Q;
endmodule
Figure 3. Code for the control_ff circuit.
D Q
Clock
0
1 0
Clear
ff_in
Q
Figure 4. The control_ff circuit.
4
Figure 5 presents the code for the delay counter module, delay_counter. This is a 28-bit up-counter. Its most-
signicant bit, b
27
, goes to 1 after about four seconds. It is used as the start_test signal. The code produces the
circuit in Figure 6. Note that the counter is implemented as a 28-bit register (represented by the ip-op symbol),
and an adder which increments the contents of the register by 1.
module delay_counter (Clock, Clear, Enable, Start);
input Clock, Clear, Enable;
output wire Start;
reg [27:0] delay_count;
always @(posedge Clock)
if (Clear)
delay_count <= 0;
else if (Enable)
delay_count <= delay_count + 1;
assign Start = delay_count[27];
endmodule
Figure 5. Code for the delay_counter circuit.
D Q
0
1
0
1
0
Clock
Clear
Enable
1
Register
Adder Start
Figure 6. The delay_counter circuit.
Figure 7 gives the code that denes the hundredth subcircuit. This is a down-counter which generates an output
pulse whenever the contents reach the value 0. To produce the interval of one hundredth of a second, the counter is
repeatedly loaded with the value (7A120)
16
which corresponds to 500,000. The output of this circuit, sec_100th,
allows the BCD counter to be incremented 100 times each second as long as the green light is on. The circuit is
shown in Figure 8. This counter is implemented as a 20-bit register (represented by the ip-op symbol), and an
adder which decrements the contents of the register by 1.
module hundredth (Clock, Load, pulse_500k);
input Clock, Load;
output wire pulse_500k;
reg [19:0] count_500k;
always @(posedge Clock)
if (Load)
count_500k <= 20h7A120;
else
count_500k <= count_500k 1;
assign pulse_500k = (count_500k == 20h00000);
endmodule
Figure 7. Code for the hundredth circuit.
5
D Q
0
1
7A120
Clock
1
Register
Adder
Compare
to 0
FFFFD
Load
pulse_500k
Figure 8. The hundredth circuit.
The BCD counter is specied by the code in Figure 9. The circuit for each of the four BCD digits is dened in
the module BCD_stage. Four versions of this circuit are instantiated in the module BCD_counter. Figures 10 and
11 depict the circuits synthesized from the modules BCD_counter and BCD_stage, respectively.
module BCD_counter (Clock, Clear, Enable, BCD3, BCD2, BCD1, BCD0);
input Clock, Clear, Enable;
output wire [3:0] BCD3, BCD2, BCD1, BCD0;
wire [4:1] Carry;
BCD_stage stage0 (Clock, Clear, Enable, BCD0, Carry[1]);
BCD_stage stage1 (Clock, Clear, (Carry[1] & Enable), BCD1, Carry[2]);
BCD_stage stage2 (Clock, Clear, (Carry[2] & Carry[1] & Enable), BCD2, Carry[3]);
BCD_stage stage3 (Clock, Clear, (Carry[3] & Carry[2] & Carry[1] & Enable), BCD3, Carry[4]);
endmodule
module BCD_stage (Clock, Clear, Ecount, BCDq, Value9);
input Clock, Clear, Ecount;
output reg [3:0] BCDq;
output reg Value9;
always @(posedge Clock)
begin
if (Clear)
BCDq <= 0;
else if (Ecount)
begin
if (BCDq == 4b1001)
BCDq <= 0;
else
BCDq <= BCDq + 1;
end
end
always @(BCDq)
if (BCDq == 4b1001)
Value9 <= 1b1;
else
Value9 <= 1b0;
endmodule
Figure 9. Code for the BCD_counter circuit.
6
BCD_stage
Clear
Enable
BCD
3 0
Value9
stage0
BCD_stage
Clear
Enable
BCD
3 0
Value9
stage1
BCD_stage
Clear
Enable
BCD
3 0
Value9
stage2
BCD_stage
Clear
Enable
BCD
3 0
Value9
stage3
Clock
Clear
Enable
BCD0
BCD1
BCD2
BCD3
Figure 10. The BCD_counter circuit.
D Q
0
1
0
1
0
1
0
0
Clock
Clear
Ecount
1
BCD
3 0
Value9
Register
Adder
Compare
to 9
Figure 11. The BCD_stage circuit.
Each digit of the BCD counter is converted into a seven-bit pattern suitable for display on a 7-segment display
on the DE2 board. This is accomplished by using the circuit bcd7seg, which is specied by the code in Figure 12.
7
Note that the comment in the code shows the labeling of the segments that corresponds to the implementation on
the DE2 board.
module bcd7seg (bcd, display);
input [3:0] bcd;
output reg [0:6] display;
/*
*
* | 0 |
* 5 | | 1
* | |
*
* | 6 |
* 4 | | 2
* | |
*
* 3
*/
always @(bcd)
case (bcd)
4h0: display = 7b0000001;
4h1: display = 7b1001111;
4h2: display = 7b0010010;
4h3: display = 7b0000110;
4h4: display = 7b1001100;
4h5: display = 7b0100100;
4h6: display = 7b1100000;
4h7: display = 7b0001111;
4h8: display = 7b0000000;
4h9: display = 7b0001100;
default: display = 7bx;
endcase
endmodule
Figure 12. Code for the BCD-to-7-segment decoder circuit.
Figure 13 gives a circuit that may result from the code in Figure 12. Each segment of the 7-segment display
is driven by a signal generated by a simple decoder from the four bits of a BCD digit. The gure shows only a
part used to drive two of the segments, display
0
and display
6
. Each decoder realizes the assignment indicated in
Figure 12. Note that the segments of a 7-segment display are illuminated when a ground signal, logic 0, is applied
to them. They are turned off when a high-voltage signal, logic 1, is applied.
While Figure 13 shows specic decoder circuits, it is important to keep in mind that the Quartus II compiler
may synthesize different looking circuits but with the same functionality.
We will use our example circuit to illustrate the debugging process. To get the most out of this tutorial, create
a new Quartus II project, compile the circuit, and follow the discussion by performing the various tasks on your
design. All of the les involved in the design are provided with this tutorial.
Before starting the discussion of debugging, we will consider some Quartus II tools that make the debugging
task easier.
8
BCDq
0
BCDq
3
BCDq
1
BCDq
2
display
0
display
6
Figure 13. The bcd7seg circuit.
2 Quartus II Tools for Use in Debugging of Hardware Designs
The Quartus II software includes many tools that are useful for a variety of purposes. We will discuss three types
of tools: Netlist Viewers, SignalTap II Logic Analyzer, and Simulator. While their use is broader, we will restrict
our discussion to their utility as debugging aids.
2.1 Netlist Viewers
The Netlist Viewers provide a graphical indication of a synthesized circuit. A register transfer level (RTL) view
of a designed circuit, generated after the initial synthesis, can be seen by using the RTL Viewer. A view of the
nal implementation, obtained after technology mapping, is available through the Technology Map Viewer. If a
designed circuit involves a nite state machine, a diagram of this FSM can be examined by means of the State
Machine Viewer.
2.1.1 RTL Viewer
The RTL Viewer provides a block diagram view of a circuit, at the level of registers, ip-ops and functional
blocks that constitute the design. The displayed image is the circuit generated after the analysis and initial synthesis
steps. It is not necessary to wait for the rest of the compilation process to be completed, which includes placing
9
and routing the designed circuit. Using the project with our example circuit, activate the initial synthesis process
by clicking on the Start Analysis and Synthesis icon in the toolbar. Should this icon not be displayed in
the toolbar, it can be found by selecting Processing > Compiler Tool. Upon performing the synthesis, select
Tools > Netlist Viewers > RTL Viewer to reach the window depicted in Figure 14. This shows a portion of the
designed circuit. The rest of the circuit can be examined by scrolling through this window. The view of the circuit
can be enlarged or reduced by means of the Zoom Tool. The complete circuit is given in Figure 15.
Figure 14. The RTL Viewer.
Figure 15. The complete RTL view of the reaction-tester circuit.
Double-clicking on any block of the displayed circuit will reveal a more detailed structure of this block. For
example, doing this on the block labeled "control_ff:run_signal" produces the image in Figure 16. This is the
circuit that we anticipated in Figure 4.
10
Figure 16. The RTL Viewer presentation of the control_ff circuit.
The RTL Viewer is a very useful debugging aid. It allows the designer to quickly see the structure of the
circuit that is being designed. It shows the connections between functional blocks. Names of the signals on the
connecting wires can be seen by hovering the mouse over the wires, which makes it easy to trace the signals.
The displayed diagram includes only those circuit blocks that are driven by valid inputs and produce outputs that
connect to other blocks or pins on the FPGA device. Thus, if an expected block is missing, it is very likely that
the Verilog specication of the corresponding inputs or outputs is incorrect.
Since the RTL Viewer displays the circuit obtained after the initial synthesis (without needing to perform a
complete compilation), it takes relatively little time to see the effect of any changes that are made in the design.
2.1.2 Technology Map Viewer
The Technology Map Viewer can be used to examine a circuit that was compiled. It displays not only the structure
of the circuit, but it also indicates the details of logic cells that are used to implement the various parts of the
circuit. It is activated by selecting Tools > Netlist Viewers > Technology Map Viewer. Figure 17 shows a
portion of the displayed image for our example circuit. Double-clicking on a particular block displays the details
of the block.
The displayed image indicates how the designed circuit is implemented in a specic technology. On the DE2
board this is the technology of the Cyclone II FPGA.
2.1.3 State Machine Viewer
The State Machine Viewer can be used to examine the implementation of FSMs that are a part of a designed
circuit. It is accessed by selecting Tools > Netlist Viewers > State Machine Viewer.
The FSM implementation is depicted in both graphical and tabular forms. The encoding of states is also
presented.
11
Figure 17. The Technology Map Viewer.
2.2 SignalTap II Logic Analyzer
A traditional Logic Analyzer is an instrument that can display waveforms that correspond to signals obtained by
connecting probes to various points in an implemented circuit. For an FPGA device, it is only possible to gain
such access to external pins. However, Quartus II software includes a software-implemented tool that acts as a
virtual logic analyzer, which allows the user to examine signals that are going to occur anywhere within a circuit
implemented in an FPGA chip. It is called the SignalTap II Logic Analyzer. Its use is described in the tutorial
SignalTap II with Verilog Designs.
Figures 18 and 19 indicate how the analyzer may be used on our example circuit. We chose to look at several
signals that are affected by the start_test signal going to 1. As seen in Figure 18, a positive edge of this signal is
enabled as the trigger that causes the analyzer to take a snapshot of signal activity. Figure 19 shows the waveforms
that occur at trigger time. Observe that the test_active signal goes to 1 in the next clock cycle (as expected). Also,
observe that the contents of the hundredth counter, called count_500k in Figure 7, are decremented by 1 in each
clock cycle.
It is important to know that the Quartus II Compiler will not necessarily preserve the exact names of signals
in combinational logic as dened in a Verilog design le. Also, when the Node Finder is used to nd signals
that the designer wants to include in the Setup window of the SignalTap II Logic Analyzer, many signals that
are not registered or found on the FPGA pins may not be listed. It is possible to force the listing of a particular
signal under its original name by means of the "synthesis keep" option. For example, we can ensure that the run,
start_test, test_active and enable_bcd signals will be preserved and listed by changing the statement in line 8 in
Figure 2 to read
wire run, start_test, test_active, enable_bcd /* synthesis keep */;
Using the synthesis keep option may result in a slightly different circuit being synthesized. The circuit will have
the same functionality as the intended circuit, but it may have a slightly different timing behavior. Therefore, upon
successful completion of the debugging (or simulation) task, the modications inserted to invoke the synthesis
keep option should be removed.
12
Figure 18. The Setup window of SignalTap II Logic Analyzer.
Figure 19. The Data window of SignalTap II Logic Analyzer.
13
2.3 Simulators
The tools discussed above are very useful in determining whether or not a given circuit appears to have the desired
structure and functionality. To test the expected functional correctness and performance of the designed circuit it
is useful to simulate the circuit. For example, a circuit that performs extensive arithmetic operations may appear
to to be designed correctly in terms of the components it contains, but a small error in detail (which could be
difcult to detect using either a netlist viewer or the logic analyzer) can cause wrong results to be produced
when a particular operation is performed. Functional simulation provides an excellent vehicle for ascertaining
that the circuit performs correctly as far as its functionality is concerned. It is also important to ensure that the
timing behavior of the circuit meets the specication requirements, which can be determined by means of timing
simulation.
A complete simulation of our example circuit would require a large number of clock cycles, making it difcult
to produce an informative display. However, we can perform a meaningful simulation by scaling down some
parameters. For example, let us reduce the delay_counter circuit to be a 4-bit counter so that the start_test signal
will go to 1 after a delay of 8 clock cycles. Let us also reduce the hundredth counter to be a 3-bit counter into
which the value 4 is loaded whenever the Load signal is active. A functional simulation of this scaled-down circuit
is shown in Figure 20.
We applied the input signals that correspond to the pushbutton keys. The observed behavior of the simulated
circuit is correct. The BCD counter evaluates correctly the number of sec_100th pulses that occur before the
KEY
3
signal goes to 0 (which corresponds to pressing of the pushbutton). The BCD-to-7-segment decoders also
correctly decode the BCD digits, which is easily veried by examining the displayed patterns.
The simulation indicates that our circuit produces a slightly inaccurate result. Before the test starts, the hun-
dredth counter runs in a counting span of 8 clock cycles, as shown by the sec_100th signal in Figure 20. During
the test this span becomes 4 cycles, because this is the value repeatedly loaded into the counter. However, at the
very beginning of the test the counter may contain the value 7, which means that it will take 8 clock cycles before
the BCD counter starts counting. This means that our tester circuit may be wrong by 1/100th of a second. If we
could not tolerate this inaccuracy, we would have to modify the circuit.
Figure 20. The result of functional simulation.
Quartus II software includes the simulation tools. They are described in the tutorial Quartus II Simulation
with Verilog Designs. We encourage the user to use the ModelSim simulator, particularly when large circuits are
involved.
14
3 Debugging Concepts
Debugging of complex logic circuits can be difcult. The task is made easier if one uses an organized approach
with the aid of debugging tools. The debugging task involves:
Observing that there is a problem
Identifying the source of the problem
Determining the design changes that have to be made
Changing and re-implementing the designed circuit
Testing the corrected design
3.1 Observing a Problem
Often it is easy to see that there is a problem because the designed circuit does not match the designers expecta-
tions in an obvious way. For example, a graphical image of the circuit displayed by the RTL Viewer may indicate
that there are missing logic blocks and/or connections.
Consider an error where line 13 in Figure 2 reads
assign enable_bcd = test_active;
Compiling the design and testing the resulting circuit would showthat the circuit simply does not work. Examining
the designed circuit with the RTL Viewer gives the image in Figure 21. It is apparent that there is no output from
the block hundredth_sec. The reason is that the Compiler recognized that the signal sec_100th is not used as an
input anywhere in the rest of the circuit, hence it omitted this signal. Making this observation the designer would
quickly discover the error in line 13.
Figure 21. The erroneous circuit displayed by the RTL Viewer.
As another example, suppose that the designer assumes erroneously that the elements of a Verilog vector that
refers to the segments of a 7-segment display are labeled as going from 6 to 0, which would mean that line 4 in
Figure 2 would read
output wire [6:0] HEX0, HEX1, HEX2, HEX3;
15
Compiling the design would result in a circuit that seems to respond properly to pressing of the input keys, but
generates a strange-looking output on the 7-segment displays. Observing this behavior, the designer may suspect
that there is something wrong with the display of BCD digits. A possible test is to see if the BCD counter generates
a plausible result, which is easily accomplished by using the SignalTap II Logic Analyzer. Figure 22 shows an
image that we obtained by triggering on the clear signals rising edge (going from 0 to 1), which happens in
response to KEY
3
being pressed causing the timer to stop counting. The logic analyzer display indicates that the
BCD value should be 0023. However, the 7-segment displays depict the two least-signicant digits as 5E and
the two most-signicant digits as upside-down letters AA. The latter fact provides an immediate clue because
the difference between the inverted A and the expected 0 is in segments labeled 0 and 6 in Figure 12, which are
reversed. This should lead to a quick detection of the error that we created.
Note also that Figure 22 indicates that the control signals appear to work correctly. One clock cycle after the
active edge of the clear signal, the start_test and test_active signals go to 0. The sec_100th and enable_bcd signals
are both equal to 0, because they are equal to 1 only during one clock cycle in a 1/100 second period.
Figure 22. Using the SignalTap II Logic Analyzer to observe the output of the BCD counter.
A complex circuit may be difcult to debug. The circuit implementation may appear to contain all necessary
components, it may appear to function properly, but the results it produces do not exhibit the expected behavior.
In such cases, the rst task is to identify the source of the problem.
3.2 Identifying the Problem
Designers intuition (which improves greatly with experience) may suggest some tests that could be tried. Other-
wise, it is necessary to adopt an organized procedure. A golden rule is to rst test small portions of the circuit,
which should be easy to do if the circuit is designed in modular fashion. This is referred to as the divide-and-
conquer approach.
Our example circuit is constructed in modular fashion. Each module in Figure 1 can be tested separately by
using the SignalTap II Logic Analyzer. It is also useful to compile, simulate and test each module on its own,
before it is included in the bigger circuit.
It may be helpful to functionally exercise only a portion of a designed circuit, which can show whether or
not this portion is working correctly. For example, we can test the BCD counter and the 7-segment displays by
16
isolating this part from the rest of the circuit and providing separately-controlled inputs to this subcircuit. One
way of doing this is to use a manual clock instead of the system clock, which would allow us to see the changes
(on the 7-segment displays) that take place during the counting process. To accomplish this, we can change line
19 in Figure 2 to read
BCD_counter bcdcount (KEY[2], request_test, 1b1, BCD3, BCD2, BCD1, BCD0);
Now, KEY
2
is used as a manual clock and the counter is enabled at all times (by connecting 1 to the enable input).
Then, pressing KEY
2
repeatedly will step the counter in the upward direction which should be observable on the
displays. Note that the BCD counter can be cleared by pressing KEY
1
, but only when an active clock signal edge
arrives (as a result of pressing KEY
2
) because the BCD_counter module uses synchronous clear.
4 Sources of Errors in Verilog Designs
The Quartus II Compiler can detect many errors in Verilog les that specify a given circuit. Typical errors include
incorrect syntax, undeclared inputs or outputs, improper use of variables and incorrect sizes of vectors. The
compiler stops compilation and displays an error message. Such errors are usually easy to nd and correct. It is
much more difcult to nd errors in a circuit that appears to be correctly specied but the specication does not
result in a circuit that the designer hoped to achieve. In this section we will consider some typical errors of this
type.
Some common errors in Verilog designs are:
Inadvertent creation of latches
Omission of signals
Not assigning a value to a wire
Assigning a value to a wire more than once
Missing begin-end blocks in an always statement
Improper use of blocking and nonblocking assignments
Wrong denition of a signal vector
Incorrectly specied FSM (e.g. wrong or invalid next state)
Incorrect timing where the output signal of a given circuit is off by one clock cycle
Careless use of clocks
Inadvertent latches are created by the Compiler if the designer fails to specify the action needed for all cases in
constructs where a certain number of cases are expected to be specied in what is supposed to be a combinational
circuit (e.g. in if-else and case statements).
If the designer fails to use some signals in a Verilog design le, the Compiler will ignore these signals com-
pletely and may even omit the circuitry associated with these signals.
Failure to include the begin and end delimiters in a multi-statement always block will cause only one statement
to be considered valid.
Careful use of blocking and nonblocking assignments is essential. It is dangerous, and not advisable, to use
both types of assignments in the same always block. To describe a combinational circuit in an always construct,
it is best to use blocking assignments. For sequential circuits, one should use nonblocking assignments.
Incorrect denitions of signal vectors lead to problems, as illustrated in section 3.1.
Errors in the specication of an FSM may lead to a variety of undesirable consequences. They can cause
wrong functional behavior by reaching wrong states, as well as wrong timing behavior by producing incorrect
output signals. A common error results in an output signal that is off by one clock cycle.
It is particularly important to use clocks carefully. For example, a slower clock may be derived by using a
counter to divide down the main system clock. Timing problems may arise when signals generated in a circuit
controlled by one clock are used as inputs to a circuit controlled by a different clock. Whenever possible, all
17
ip-ops should be driven by the same clock. For instance, if a given counter has to be incremented/decremented
at a rate that is slower than the system clock rate, it is best to drive the counter with the system clock and use a
slower changing enable signal to make the counter count at a slower rate. We used this approach in our example
circuit to control the BCD counter.
5 Errors Due to Wrong Interpretation of DE2 Board Characteristics
Inadequate understanding of the DE2 board can lead to design errors. Typical examples include:
Wrong pin assignment
Wrong interpretation of the polarity of pushbutton keys and toggle switches
Timing issues when accessing various chips on the board, such as the SDRAM memory
If pins are not assigned correctly, the circuit will not exhibit the desired behavior. This may be easy to detect
when obviously observable input and output signals are involved. If the designer species a wrong assignment for
a pushbutton key, then pressing this key will probably have no effect. If the connection to a 7-segment display is
not made at all, the display will show the pattern 8. This means that all seven segments are driven by a logic 0
signal, because a segment lights up when connected to ground voltage. The Quartus II Compiler causes all unused
pins to be driven to ground by default. (Of course, this default choice can be changed (in the Quartus II project) by
specifying a different option for the unused pins.) The easiest way of ensuring that the pins are correctly assigned
for the DE2 board is to import the pin-assignment le DE2_pin_assignments.csv.
Pushbutton switches produce logic 0 when pressed. Toggle switches generate logic 1 when in the up position
(towards the middle of the board).
If the design involves access to the SDRAM chip, it is necessary to adhere to strict timing requirements, as
explained in the tutorial Using the SDRAM Memory on Alteras DE2 Board with Verilog Design.
6 Design Procedure
It is prudent to follow a design procedure that tends to minimize the number of design errors and simplies the
debugging task. Here are some suggestions that are likely to help:
Design the circuit in a modular, hierarchical manner.
Use well-understood and commonly-used constructs to dene circuits.
Test each module, by simulating it, before it is incorporated into the larger circuit.
Dene and test portions of the nal circuit by connecting two or more modules.
Construct the complete circuit and test it through simulation. Both functional and timing simulation should
be done.
Download the compiled circuit into the FPGA on the DE2 board and test it.
It is prudent to write Verilog code in a style that allows one to easily visualize the circuit specied by the code.
It is also useful to make the code easily understandable for other people.
Copyright c 2008 Altera Corporation. All rights reserved. Altera, The Programmable Solutions Company, the
stylized Altera logo, specic device designations, and all other words and logos that are identied as trademarks
and/or service marks are, unless noted otherwise, the trademarks and service marks of Altera Corporation in
18
the U.S. and other countries. All other product or service names are the property of their respective holders.
Altera products are protected under numerous U.S. and foreign patents and pending applications, mask work
rights, and copyrights. Altera warrants performance of its semiconductor products to current specications in
accordance with Alteras standard warranty, but reserves the right to make changes to any products and services at
any time without notice. Altera assumes no responsibility or liability arising out of the application or use of any
information, product, or service described herein except as expressly agreed to in writing by Altera Corporation.
Altera customers are advised to obtain the latest version of device specications before relying on any published
information and before placing orders for products or services.
This document is being provided on an as-is basis and as an accommodation and therefore all warranties, rep-
resentations or guarantees of any kind (whether express, implied or statutory) including, without limitation, war-
ranties of merchantability, non-infringement, or tness for a particular purpose, are specically disclaimed.
19