I am new to Verilog language and want to do some practices to get familiar with it. And I encountered this problem on HDLbits: DFF8ar
This problem asks me to create 8 D flip-flops with active-high asynchronous reset. I use a case statement to handle the areset signal:
module top_module (
input clk,
input areset, // active high asynchronous reset
input [7:0] d,
output reg[7:0] q
);
always #(posedge clk or posedge areset) begin
case (areset)
1'b1: q <= 8'b0;
default: q <= d;
endcase
end
endmodule
And to my surprise, the circuit it generated ignores the clk signal:
But, if I switch the case statement to an if-else statement, the result will be correct:
always #(posedge clk or posedge areset) begin
if (areset)
q <= 8'b0;
else q <= d;
end
I don't know the reason behind it even after doing some research. Does if-else statements and case statements have some fundamental difference? Any help is appreciated!
Synthesis places some special restrictions on the normal Verilog language.
Synthesis tools recognize specific Verilog coding patterns, but your case code does not match any of those patterns, whereas your if/else code does. There should be documentation with your tool set that shows what syntax is supported for synthesis. When you ran the synthesis, there may have been warning or error messages; check for any log files.
Although the 2 coding styles may behave the same in simulation, you need to restrict yourself to supported syntax for synthesis.
Related
I understand that always block can be used to implement procedural and sequential logic.
Will the gate-level realization of the following two codes be the same? If yes, what is the correct way of describing this continuous-time logic?
a.
module func(input a, input b , output reg o);
always #(a,b)
o=a&b;
endmodule
b.
module func(input, a, input b, output o);
assign o = a & b;
endmodule
In (a), 'o' is a reg type and in (b) it is a wire. What does this difference mean?
What are the required 'always' block properties for the synthesis tool to implement a FF? I know the following will result in a FF:
always #(posedge clk or negedge rst)
[...]
But, I'm looking for a more in-depth understanding.
Your (a) and (b) codes are functionally equivalent. This means that they will simulate the same way and they will infer the same logic when synthesized.
They use 2 different styles of modeling: (a) uses a procedural assignment because it uses an always block, whereas (b) uses a continuous assignment because there is no always block and it uses the assign keyword.
In this simple case, there is no "correct" way; they are 2 different styles to achieve the same functionality. For such simple logic, it is preferable to use (b) because it uses less code and it is easier to understand. However, if your combinational logic were more complicated, the procedural approach might be easier to understand.
In (a), the o signal must be a reg type since it is assigned inside a procedural logic block. There is no such requirement for continuous assignments. In this case, defining a reg type does not result in a flip-flop. A reg only infers a flip-flop when the always block describes sequential logic
Synthesis tools look for specific types of patterns in Verilog code to infer sequential logic. The following will infer flip-flops with an asynchronous reset:
always #(posedge clk or negedge rst)
if (!rst) ...
else ...
The following will infer flip-flops with an synchronous reset:
always #(posedge clk)
if (!rst) ...
else ...
These are just a couple examples.
I understand that always block can be used to implement procedural and sequential logic.
Will the gate-level realization of the following two codes be the same? If yes, what is the correct way of describing this continuous-time logic?
a.
module func(input a, input b , output reg o);
always #(a,b)
o=a&b;
endmodule
b.
module func(input, a, input b, output o);
assign o = a & b;
endmodule
In (a), 'o' is a reg type and in (b) it is a wire. What does this difference mean?
What are the required 'always' block properties for the synthesis tool to implement a FF? I know the following will result in a FF:
always #(posedge clk or negedge rst)
[...]
But, I'm looking for a more in-depth understanding.
Your (a) and (b) codes are functionally equivalent. This means that they will simulate the same way and they will infer the same logic when synthesized.
They use 2 different styles of modeling: (a) uses a procedural assignment because it uses an always block, whereas (b) uses a continuous assignment because there is no always block and it uses the assign keyword.
In this simple case, there is no "correct" way; they are 2 different styles to achieve the same functionality. For such simple logic, it is preferable to use (b) because it uses less code and it is easier to understand. However, if your combinational logic were more complicated, the procedural approach might be easier to understand.
In (a), the o signal must be a reg type since it is assigned inside a procedural logic block. There is no such requirement for continuous assignments. In this case, defining a reg type does not result in a flip-flop. A reg only infers a flip-flop when the always block describes sequential logic
Synthesis tools look for specific types of patterns in Verilog code to infer sequential logic. The following will infer flip-flops with an asynchronous reset:
always #(posedge clk or negedge rst)
if (!rst) ...
else ...
The following will infer flip-flops with an synchronous reset:
always #(posedge clk)
if (!rst) ...
else ...
These are just a couple examples.
what is right way to make latch in verilog?
When i try synthesizing both ways on vivado i get latch generated in both the cases.i am trying to understand do we use blocking statement or non-blocking statement?
i) always #(enable,input)
begin
q <= input;
end
ii) always #(enable,input)
begin
q = input;
end
Use blocking assignments.
For synthesis, only use non-blocking assignments for edge sensitive sequential logic.
None of the ways you provided should be used to make latches.
Commonly used programming pattern looks like the following:
always #*
if (en)
q <= inp;
This might be a basic question to ask, but I have seen it many places and have not been able to figure out why this is the case.
always #(posedge clk)
a_temp <= so;
assign a = a_temp;
What's the intent of using the extra assign statement here?
There seems to be a common misunderstanding on how verilog types work, that is if a modules port is connected to a wire, which it has to be, then the port should be defined as a wire inside the module. So you often get :
module example (
output wire a_wire
);
reg a_reg;
always #(posedge clk) begin
a_reg <= so;
end
assign a_wire = a_reg;
endmodule
Which could just be:
module example (
output reg a_reg
);
always #(posedge clk) begin
a_reg <= so;
end
endmodule
At the next level of hierarchy a_reg is still connected to a wire.
Interface Spec
Another technique that might be used with more experienced designers is to fix the interface. So that others wiring the block up have a fixed point of reference, and not having to deal with a designers constant name changes. This allows the designer to use the most appropriate (semantic) name for the signal making the code more readable while not being tied to the chosen interface name.
I'm a bit confused about what is considered an input when you use the wildcard #* in an always block sensitivity list. For instance, in the following example which signals are interpreted as inputs that cause the always block to be reevaluated? From what I understand clk and reset aren't included because they dont appear on the right hand side of any procedural statement in the always block. a and b are included because they both appear on the right hand side of procedural statements in the always block. But where I'm really confused about is en and mux. Because they are used as test conditions in the if and case statements are they considered inputs? Is the always block reevaluated each time en and mux change value? I'm pretty much a noob, and in the 3 Verilog books I have I haven't found a satisfactory explanation. I've always found the explanations here to be really helpful. Thanks
module example
(
input wire clk, reset, en, a, b,
input wire [1:0] mux,
output reg x,y, z
);
always #*
begin
x = a & b;
if (en)
y= a | b;
case(mux)
2'b00: z = 0;
2'b01: z = 1;
2'b10: z = 1;
2'b11: z = 0;
endcase
end
endmodule
Any signal that is read inside a block, and so may cause the result of a block to change if it's value changes, will be included by #*. Any change on a read signal used must cause the block to be re-evaluated, as it could cause the outputs of the block to change. As I'm sure you know, if you hadn't used #* you'd be listing those signals out by hand.
In the case of the code you've provided it's any signal that is:
Evaluated on the right hand side of an assignment (a and b)
Evaluated as part of a conditional (en and mux)
...but it's any signal that would be evaluated for any reason. (I can't think of any other reasons right now, but maybe someone else can)
clk and reset aren't on the sensitivity list because they aren't used. Simple as that. There's nothing special about them; they're signals like any other.
In your example, the following signals are included in the implicit sensitivity list:
a
b
en
mux
clk and reset are not part of the sensitivity list.
This is described completely in the IEEE Std for Verilog (1800-2009, for example). The IEEE spec is the best source of detailed information on Verilog. The documentation for your simulator may also describe how #* works.
The simplest answer depends on if you are writing RTL, or a testbench. If you are writing RTL then you should try to forget about the concept of Sensitivity lists, as they don't really exist. There is no logic that only updates when an item on the list is triggered. All sensitivity lists can do in RTL is cause your simulation and actual circuit to differ, they don't do anything good.
So, always use "always #*" or better yet "always_comb" and forget about the concept of sensitivity lists. If the item in the code is evaluated it will trigger the process. Simple as that. It an item is in an if/else, a case, assigned to a variable, or anything else, it will be "evaluated" and thus cause the process to be triggered.
But, just remember, in digital circuits, there is no sensitivity list.