Coding and Synthesis With Verilog
Coding and Synthesis With Verilog
2.2 Multiplexers
2.2.1 Multiplexer using a procedure
// 1. using an always always@(a or b or sel) if (sel == 1b1) c = a; else c = b;
a c
1 b 0
sel
a c
1 b 0
sel
default: d = c; endcase
c b a
0 0 1 1 d
c b a
0 0 1 1 d
a[0] a[1]
2.6 Comparators
// 1. using a wire wire d; assign d = (a == c);
a[3:0] 4 c[3:0] 4
d 1
10
clock
clock
11
// 2. asynchronously resettable D flip flop // (active high async reset) always @ (posedge clock or posedge reset) if (reset) q <= 1b0; else q <= d;
reset d q
clock
12
// 3. asynchronously resettable D flip flop // (active low reset) always @ (posedge clock or negedge reset) if (~reset) q <= 1b0; else q <= d;
reset d q
clock
13
q d enable clock
// 2. D flip flop with gated clock wire gclk = (clock && enable); always @ (posedge gclk) q <= d;
clock enable
gclk
14
2.10 Latches
// 1. latch always @ (enable or d) if (enable) q = d;
d e enable
reset d e enable q
15
enable
16
2.12 Counter
3 bit asynchronously resettable counter which counts 0, 1, 2, 3, 4, 5,
// 3 bit asynchronously resettable // partial range counter always @ (posedge clock or posedge reset) if (reset) count <= 3b0; else if (count == 3b101) count <= 3b0; else count <= count + 3b001;
=
3b101 clock
17
module enabled_shift_reg (clock,enable,data_in,data_out); input clock; input enable; input [3:0] data_in; output [3:0] data_out; reg reg reg reg [3:0] [3:0] [3:0] [3:0] data_out; shift_reg_1; shift_reg_2; shift_reg_2;
always @ (posedge if (enable) begin shift_reg_1 shift_reg_2 shift_reg_3 data_out <= end endmodule
clock)
18
12 b 5 6 d e
Note that the * and + and - signs give you unsigned arithmetic. If you need signed arithmetic, you may need special instaces recognizable to the synthesis tool. Adding two ve bit numbers gives a siz bit result (the extra bit is the carry out bit). The multiplication of two number means that the output is twice the width of the inputs.
wire [5:0] c = a + b; wire [11:0] e = c * d;
19
Take care of indentation. Develop your own identation guidelines and stick to them. Make sure others can read them. It helps readability and debugging greatly if it is done properly. Comment code properly. The theory about good commenting is that you should be able to remove all functional code and the comments remaining should almost document the block you are designing.
// example of bad comments // add a and b together always @ (a or b) c = a + b; // Good commenting // 8 bit unsigned adder for data signals a and b // output is sent to UART2 always @ (a or b) c = a + b;
Dont make the code any more complicated than it needs to be. Your priorities should be correctness, then readability and nally code efciency.
October 18, 2001 20
21
output values
stop
22
23