I'm trying to construct a structural implementation of a circuit that consists of a d flipflop, it has inputs x and y, x and y are exclusive or'd and that result is exclusive or'd with the current state, and used as the input to the d flip flop. and it'll use the result state from the flipflop in the next run, etc. But I'm not too sure how to construct it.
The circuit looks like so:
module dff(D,clk,q);
input D,clk;
output q;
reg q;
always # (posedge clk)
begin
q<=D;
end
endmodule
I'm pretty sure the d flip flop code is correct but when I try to test this my d and state values are just x for some reason. When I put in different x and y values in my testbench nothing happens, "state" and "d" just always says it has value "1'hx" in the simulation. Why is this happening and how do I actually assign an value to them?
All signals in verilog simulation are initialized to 'x'. So are the values of A and D. Your second xor is applied to xoy ^ A. Since A is x, the result of this xor is always x. you need to break this loop, as oldfart suggested.
The usual way for doing it is to introduce a reset in the flop, synchronous or asynchronous. Here is an example of a synchronous reset flop:
always #(posedge clk)
if (reset)
q <= 0;
else
q <= D;
So, now, if you set your reset to '1' for at least one posedge of clk and then set it to '0', you will break the loop by pushing a non-'x' value in the data path.
You do not clear your D-FF. The output is X at the start and as you use that in a feedback loop it stays X.
This: wire state=1'b0; does not clear you FF. You have to clear 'q'.
Related
When exactly are the variables inside an always-block in Verilog updated?
E.g. if the reg C is changed multiple times in an always-block: does the value of it always change? Or is the value only "physically written" to the reg at the end of the always-block?
Would it be better to use an extra intermediate register which is only actualized at the end of the always-block? Would it make any difference?
reg C;
always #(*)
C = 0;
C = A;
C = 1;
C = B;
end
Other example:
If I have a module with an always block as follows, could the multiple assignments of the output exhibit sort of a glitch, where the output quickly goes to 0 before getting the value of B? Does it make a difference if I use blocking (=) or non-blocking (<=) assignments?
module example1 (output C, input A, input B);
always #(*)
begin
C = 1’b0;
if (A==1)
C = B ;
end
endmodule
Example with intermediate register to avoid unwanted change of the output.
module example1 (output C, input A, input B);
reg intermediateReg;
always #(*)
begin
intermediateReg = 1’b0;
if (A==1)
intermediateReg = B ;
end
C <= intermediateReg;
endmodule
In the examples you provided the code behaves identically to the 'c' code. The variable gets re-assigned new values and the last one wins. In verilog this is true for blocking (=) or non-blocking (<=) assignments, but not for the mix of them.
As in 'c' it is up to the compiler optimization technique. It can eliminate unneeded assignments, so only the last one is relevant.
In your first example the value of 'C' will be 'B' at the end of the block. The value of 'C' in the second example will either be 0 or B, depending on A.
Now, for the purpose of a simplicity of explanation, mixing of blocking and non-blocking assignments will cause the last 'non-blocking' assignment win. The reason is that all nba's are executed after the block is finished.
always #(*) begin
C <= A;
C = B;
end
The value of C will be A at the end of the simulation cycle.
As for the question about using intermediate values, there is no difference. You use them as needed. The simulation compiler or synthesis will optimize your code in any case. The last example is absolutely normal, except that it does not change anything at all. It behaves the same way as this, which is more explicit and more readable in my opinion. The only problem is that you incorrectly use nba assignments int combinational logic (which i fixed).
always #(*)
begin
if (A==1)
C = B ;
else
C = 1'b0;
I guess there is another silent question in your post, will the intermediate value cause events on 'C', the answer in this case is no. There will be no events produced by the always block till it finishes its execution (or till it hits a delay or starts waiting on an event). So, only the last value is relevant.
In a testbench code you can see a situation like that:
always #* begin
C = A;
C = B;
#5 C = D;
end
In the above case The value of C will become B. The execution of the always block will stop for #5 delays. During that time other blocks will see the value B. In #5 ticks, the value will be changed to D.
If you want to know what blocking and non-blocking assignments do in standard Verilog (like you would have in simulation), you can easily look that up.
If you're talking about hardware, the type of hardware you get will depend on what's in the sensitivity list, not type type of assignments you use. The type of assignment will affect the combinational logic that is synthesized from your code. Assuming you aren't doing anything unsynthesizable, the logic you get should be equivalent to what the Verilog standard specifies but won't be a 1:1 direct mapping of your code.
So, no, adding intermediates won't necessarily help with glitches in the hardware. There will be other code and timing specifications, etc. for dealing with stuff like that.
I have an inverter with X input when my testbench start. So my output is X too.
Can i force my output is 1 or 0 when my input is X?
Thank you.
Sure you can. If your inverter is a module instance, simply force the wire that is tied to the output. If it is just an assign statement, just force the wire that's being assigned to.
module tb();
reg l_a;
wire l_q;
invtr i0(.q(l_q), .a(l_a));
initial begin
$vcdpluson;
#10;
force l_q = 1'b0;
#10;
release l_q;
#10;
l_a = 1'b0;
#10;
l_a = 1'b1;
#10
$finish;
end
endmodule
module invtr (output wire q,
input wire a);
assign q = ~a;
endmodule
The force of the output happens at time 10ns and the release happens at time 20ns. During this time the value is 0.
No.
An X value is the result of an error; it does not represent any well-defined value. Performing any kind of operation on such a value will also result in an unpredictable value -- another X.
You will need to figure out what is causing this error and fix it.
Not possible for an inverter. Providing an input X will always inherently give an output X.
I am having a strange problem with Verilog HDL.
I found in my code that if I multiply a variable by two, but then
assign that value to the same variable, it gets all messed up.
Sometimes, the simv program even crashes. I originally needed to do this,
because I had a for loop for shifting or rotating a certain amount. But,
then I found that not only shifting the same variable did not work, but
also, addition, subtraction, multiplication, or division does not work either.
So in my code example, if you set a to 16'b0001_0000_1010_0101, and b to 3,
then you get an output of 16'b0000_0000_0000_0000. Just note that I am ignoring b for now... I should get 16'b0010_0001_0100_1010... but something is going wrong.
So, this is my code file test.v:
// ALU module.
module test(in1, in2, out1);
input [15:0] in1;
input [15:0] in2;
output reg [15:0] out1;
// Variables for shifting right and for rotating left or right.
reg [15:0] shiftedValue;
always#(in1, in2)
begin
assign shiftedValue = in1;
assign shiftedValue = shiftedValue * 2;
assign out1 = shiftedValue;
// This display value is correct!
// but it's still wrong in the test bench.
$display("out1 == %b", out1);
end
endmodule
module testStim;
reg [15:0] a;
reg [15:0] b;
wire [15:0] c;
// create ALU instance.
test myTest(a, b, c);
initial
begin
a = 16'b0001_0000_1010_0101;
b = 3;
#10
$display("op1In == %b, op1Out == %b", a, c);
$finish;
end
endmodule
This is the output after running simv (I stripped out the erroneous garbage...):
out1 == 0010000101001010
op1In == 0001000010100101, op1Out == 0000000000000000
Thanks,
Erik W.
You have done what is called as procedural continuous assignment.
The difference between regular continuous assignments and procedural continuous assignments is this:
Continuous assignment can only drive wire/net data type. Procedural assignment can drive only reg data type and not nets.
Continuous assignment should appear outside procedural blocks(always, initial etc), while latter must be inside procedural blocks.
Continuous assignment executes each time the right hand side expression changes. Procedural assignment depends on sensitivity list of always block.
As soon as the always block ends, the effect of assign statement is removed. You must add deassign statement to retain the values (which I think is not the real intent) or Just remove assign statement from the code. As shown below:
shiftedValue = in1;
shiftedValue = shiftedValue * 2;
out1 = shiftedValue;
More information about assign, deassign is available at this, this and this links.
I have Altera DE2-115 FPGA and I try to self-learn Verilog. I decided to make a smoke detector and whenever it smells smoke the buzzer rings (the smoke detector outputs a digital signal).
Here is my trial :
module fire(flag,clock,reset,fire,fire_state,firealarm);
input clock, reset, flag, fire;
output [2:0] fire_state;
output firealarm;
wire fire;
reg [2:0] fire_state;
assign firealarm = (fire_state == 1) ? (flag ? 0 : 1) : 0;
always # (posedge clock)
fire_state<= fire ? 1: 0;
end module
But it doesn't run and I think there are a lot of logic errors in this code, any help please? :)
endmodule is one word, you need to remove the space.
Almost all simulators these days support verilog-2001 or greater so I would encourage the use of the modern port style (ANSI) and not the old verilog 1995 style.
Your port list goes from:
module fire(flag,clock,reset,fire,fire_state,firealarm);
input clock, reset, flag, fire;
output [2:0] fire_state;
output firealarm; wire fire;reg[2:0] fire_state;
to :
module fire(
input clock,
input reset,
input flag,
input fire,
output reg [2:0] fire_state,
output firealarm
);
I have placed each port on a new line with it direction, this makes it much easier to maintain code, it also make it a lot more readable and therefore minimises the chance of typos in connections.
You have used this syntax a lot (flag?0:1), where you using a boolean to select a boolean there is no need to do this and makes it more difficult to read. If you need to invert it then is a bitwise invert (~). However it is not clear what you are using flag for.
for comparrisons and assignments you should be including the width.
assign firealarm = (fire_state == 3'b1)? (~flag) : 1'b0;
This could also be written out in a combinatorial always block:
always #* begin
if (fire_state==3'b001) begin
firealaram = ~flag;
else begin
firealaram = 1'b0;
end
end
fire is 1 bit, fire_state is 3 bits.
always # (posedge clock) begin
fire_state <= {2'b0, fire};
end
I'm coming from a Verilog-95 background, and I'm trying to figure out what Verilog-95 hoops I don't have to jump through anymore.
The obvious way to write a flip flop with async set and reset in Verilog-95 is:
always #(posedge clk or negedge resetb or negedge setb) begin
if (!resetb) q <= 0;
else if (!setb) q <= 1;
else q <= d;
end
This works in synthesis. But, this doesn't work in simulation if we ever assert both resetb and setb, and then de-assert resetb before de-asserting setb, since there's no posedge trigger for either of those signals. We need to add the following (which varies depending on your synthesis tool), to get simulation to match synthesis:
// synopsys translate_off
always #(resetb or setb)
if (resetb && !setb) force q = 1;
else release q;
// synopsys translate_on
Is there a SystemVerilog construct that will let you do this without this extra junk? Better yet, is there a straightforward way to do it in Verilog-95?
Flip-flops with multiple asynchronous controls are best avoided. The timing checks necessary to ensure they function properly are complex and easy to mess up. If you really need to use them, then it's probably best to instantiate them by hand where needed. If you let your synthesis tool infer them, it may use them in places you don't intend, which increases the risk that the timing checks don't get done properly.
One final aside, there is a similar simulation-synthesis mismatch issue with all asynchronous flops, if the active edge of reset is at time zero and is simulated before the flop is initialized to x, and the clock isn't running in reset. I believe some simulators have special cases to ensure the logic is not initialized in this order.
That said, I had luck moving the priority logic outside the sequential always block. Note I'm using active-high signals for simplicity.
assign s_int = s && !c;
always #(posedge clk or posedge s_int or posedge c) begin
if (c)
q <= 1'b0;
else if (s_int)
q <= 1'b1;
else
q <= d;
end
This is something I wish SystemVerilog had improved. If you want to allow both being low at the same time, then stick with the current method.
The other option is to create a design rule stating the asynchronous signals can not be active at the same time and enforce the rule with an assertion. Assertions are suppose to be ignored by synthesizers, so translate_off/on should not be be necessary.
Here is an example using an inline assertion:
always_ff #(posedge clk, negedge resetb, negedge setb) begin : dff_asyncRbSb
if (!resetb) q <= 0;
else if (!setb) q <= 1;
else q <= d;
asrt_setrst : assert(resetb||setb)
else $error("resetb and setb can not be low at the same time.");
end : dff_asyncRbSb
I don't know any SV, so this isn't an answer, but the issue here is that
Verilog (and, I think, SV) event expressions are basically broken. The problem
is that, when you have multiple conditions in an event expression:
event_expression ::=
expression
| hierarchical_identifier
| posedge expression
| negedge expression
| event_expression or event_expression
| event_expression , event_expression
then there's no bullet-proof way to determine which expression caused the
event, since the only thing you can do is to check the current state of the
expression. So, if you've got #(posedge clk, posedge rst), for example, you
look at the current levels of clk and rst and hope this is sufficient to do
the job. In general, it isn't, but your example is the only practical case (I
think) that causes a problem.
VHDL handles this by having signal attributes, which let you determine whether
a signal has caused an event. In VHDL, you get an event when any signal in
your sensitivity list changes, and you then check their 'event attribute to
determine whether they fired the process. No confusion, no posedge or negedge,
and it all works.
I've just had a quick look at the SV LRM, and SV attributes appear to be the
same as Verilog attributes, so I think you're out of luck.
with no edge defined, the assertion and de-assertion of reset and set signals should be able to trigger this code in simulation.
always_ff should be able to create a flop at synthesis.
Below code is compilation clean using synopsys VCS tool.
always_ff #(posedge clk, resetb, setb) begin
if (!resetb) q <= 0;
else if (!setb) q <= 1;
else q <= d;
end
Try this:
always_ff #(posedge clk or negedge resetb or negedge setb)
systemverilog uses always_ff for clock triggered logic and always_comb for combo logic