Can't use else in verilog always block
up vote
0
down vote
favorite
I am receiving this error from Quartus when trying to compile:
Error (10200): Verilog HDL Conditional Statement error at
time_of_day_FSM.v(166): cannot match operand(s) in the condition to
the corresponding edges in the enclosing event control of the always
construct
Here is some background. I am making a clock, and for this always
block, I want to increment and set certain values to resemble the behavior of a clock in the format of hh:mm:ss
. I have a clock source that goes high every millisecond, and am using a counter to set the secondPassed
reg.
I want the code in the block to update every time a second passes, like a clock, or KEY[2]
is pressed on my board (down = 0
), as this is what the user uses to increment the hours, minutes, or seconds when setting the clock time. Here is the always
block in question (sorry for the nested if statements, I can't think of a better way to do it):
// every second. Used just to keep time going. Independent of states.
always @(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else if(secondPassed == 1 || KEY[2] == 0) begin // I don't care about explicitly stating the conditions, as the sensitivity list covers that right?
if(sec0 == 9) begin
sec0 <= 0;
if(sec1 == 5) begin
sec1 <= 0;
if(min0 == 9) begin
min0 <= 0;
if(min1 == 5) begin
min1 <= 0;
if(hr1 == 1) begin
if(hr0 == 2) begin
hr0 <= 1; // go to 1 o'clock
hr1 <= 0;
end
else hr0 <= hr0 + 1;
end
else hr0 <= hr0 + 1;
end
else min1 <= min1 + 1;
end
else min0 <= min0 + 1;
end
else sec1 <= sec1 + 1;
end
else begin
sec0 <= sec0 + 1;
end
just_flashed <= ~just_flashed;
end // end big else
end // end always
My question is: Why does the Quartus compiler complain if I try to make the non-reset scenario JUST AND ELSE, like this:
// every second. Used just to keep time going. Independent of states.
always @(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else begin // this is causing the issue. compiler complains .
// same logic to drive clock as above
just_flashed <= ~just_flashed;
end // end big else
end // end always
I feel I have seen many examples where people simply use and else begin end for their code. My code seems to want my to EXPLICITLY restate the conditions of the sensitivity list for the else if. Any explanation? I am new to large verilog projects.
verilog block quartus
add a comment |
up vote
0
down vote
favorite
I am receiving this error from Quartus when trying to compile:
Error (10200): Verilog HDL Conditional Statement error at
time_of_day_FSM.v(166): cannot match operand(s) in the condition to
the corresponding edges in the enclosing event control of the always
construct
Here is some background. I am making a clock, and for this always
block, I want to increment and set certain values to resemble the behavior of a clock in the format of hh:mm:ss
. I have a clock source that goes high every millisecond, and am using a counter to set the secondPassed
reg.
I want the code in the block to update every time a second passes, like a clock, or KEY[2]
is pressed on my board (down = 0
), as this is what the user uses to increment the hours, minutes, or seconds when setting the clock time. Here is the always
block in question (sorry for the nested if statements, I can't think of a better way to do it):
// every second. Used just to keep time going. Independent of states.
always @(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else if(secondPassed == 1 || KEY[2] == 0) begin // I don't care about explicitly stating the conditions, as the sensitivity list covers that right?
if(sec0 == 9) begin
sec0 <= 0;
if(sec1 == 5) begin
sec1 <= 0;
if(min0 == 9) begin
min0 <= 0;
if(min1 == 5) begin
min1 <= 0;
if(hr1 == 1) begin
if(hr0 == 2) begin
hr0 <= 1; // go to 1 o'clock
hr1 <= 0;
end
else hr0 <= hr0 + 1;
end
else hr0 <= hr0 + 1;
end
else min1 <= min1 + 1;
end
else min0 <= min0 + 1;
end
else sec1 <= sec1 + 1;
end
else begin
sec0 <= sec0 + 1;
end
just_flashed <= ~just_flashed;
end // end big else
end // end always
My question is: Why does the Quartus compiler complain if I try to make the non-reset scenario JUST AND ELSE, like this:
// every second. Used just to keep time going. Independent of states.
always @(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else begin // this is causing the issue. compiler complains .
// same logic to drive clock as above
just_flashed <= ~just_flashed;
end // end big else
end // end always
I feel I have seen many examples where people simply use and else begin end for their code. My code seems to want my to EXPLICITLY restate the conditions of the sensitivity list for the else if. Any explanation? I am new to large verilog projects.
verilog block quartus
1
I guess it tries to identify the clock, which is a non-used 'edge' element. You have 2 unused and it gets confused. Try to remove KEY[2] from the sensitivity list.
– Serge
Nov 22 at 19:47
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I am receiving this error from Quartus when trying to compile:
Error (10200): Verilog HDL Conditional Statement error at
time_of_day_FSM.v(166): cannot match operand(s) in the condition to
the corresponding edges in the enclosing event control of the always
construct
Here is some background. I am making a clock, and for this always
block, I want to increment and set certain values to resemble the behavior of a clock in the format of hh:mm:ss
. I have a clock source that goes high every millisecond, and am using a counter to set the secondPassed
reg.
I want the code in the block to update every time a second passes, like a clock, or KEY[2]
is pressed on my board (down = 0
), as this is what the user uses to increment the hours, minutes, or seconds when setting the clock time. Here is the always
block in question (sorry for the nested if statements, I can't think of a better way to do it):
// every second. Used just to keep time going. Independent of states.
always @(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else if(secondPassed == 1 || KEY[2] == 0) begin // I don't care about explicitly stating the conditions, as the sensitivity list covers that right?
if(sec0 == 9) begin
sec0 <= 0;
if(sec1 == 5) begin
sec1 <= 0;
if(min0 == 9) begin
min0 <= 0;
if(min1 == 5) begin
min1 <= 0;
if(hr1 == 1) begin
if(hr0 == 2) begin
hr0 <= 1; // go to 1 o'clock
hr1 <= 0;
end
else hr0 <= hr0 + 1;
end
else hr0 <= hr0 + 1;
end
else min1 <= min1 + 1;
end
else min0 <= min0 + 1;
end
else sec1 <= sec1 + 1;
end
else begin
sec0 <= sec0 + 1;
end
just_flashed <= ~just_flashed;
end // end big else
end // end always
My question is: Why does the Quartus compiler complain if I try to make the non-reset scenario JUST AND ELSE, like this:
// every second. Used just to keep time going. Independent of states.
always @(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else begin // this is causing the issue. compiler complains .
// same logic to drive clock as above
just_flashed <= ~just_flashed;
end // end big else
end // end always
I feel I have seen many examples where people simply use and else begin end for their code. My code seems to want my to EXPLICITLY restate the conditions of the sensitivity list for the else if. Any explanation? I am new to large verilog projects.
verilog block quartus
I am receiving this error from Quartus when trying to compile:
Error (10200): Verilog HDL Conditional Statement error at
time_of_day_FSM.v(166): cannot match operand(s) in the condition to
the corresponding edges in the enclosing event control of the always
construct
Here is some background. I am making a clock, and for this always
block, I want to increment and set certain values to resemble the behavior of a clock in the format of hh:mm:ss
. I have a clock source that goes high every millisecond, and am using a counter to set the secondPassed
reg.
I want the code in the block to update every time a second passes, like a clock, or KEY[2]
is pressed on my board (down = 0
), as this is what the user uses to increment the hours, minutes, or seconds when setting the clock time. Here is the always
block in question (sorry for the nested if statements, I can't think of a better way to do it):
// every second. Used just to keep time going. Independent of states.
always @(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else if(secondPassed == 1 || KEY[2] == 0) begin // I don't care about explicitly stating the conditions, as the sensitivity list covers that right?
if(sec0 == 9) begin
sec0 <= 0;
if(sec1 == 5) begin
sec1 <= 0;
if(min0 == 9) begin
min0 <= 0;
if(min1 == 5) begin
min1 <= 0;
if(hr1 == 1) begin
if(hr0 == 2) begin
hr0 <= 1; // go to 1 o'clock
hr1 <= 0;
end
else hr0 <= hr0 + 1;
end
else hr0 <= hr0 + 1;
end
else min1 <= min1 + 1;
end
else min0 <= min0 + 1;
end
else sec1 <= sec1 + 1;
end
else begin
sec0 <= sec0 + 1;
end
just_flashed <= ~just_flashed;
end // end big else
end // end always
My question is: Why does the Quartus compiler complain if I try to make the non-reset scenario JUST AND ELSE, like this:
// every second. Used just to keep time going. Independent of states.
always @(posedge secondPassed, negedge KEY[2], negedge KEY[0]) begin
if(KEY[0] == 0) begin
hr1 <= 1;
hr0 <= 2;
min1 <= 0;
min0 <= 0;
sec1 <= 0;
sec0 <= 0;
end
else begin // this is causing the issue. compiler complains .
// same logic to drive clock as above
just_flashed <= ~just_flashed;
end // end big else
end // end always
I feel I have seen many examples where people simply use and else begin end for their code. My code seems to want my to EXPLICITLY restate the conditions of the sensitivity list for the else if. Any explanation? I am new to large verilog projects.
verilog block quartus
verilog block quartus
edited Nov 23 at 15:18
Stoogy
552422
552422
asked Nov 22 at 16:24
Caleb W.
4710
4710
1
I guess it tries to identify the clock, which is a non-used 'edge' element. You have 2 unused and it gets confused. Try to remove KEY[2] from the sensitivity list.
– Serge
Nov 22 at 19:47
add a comment |
1
I guess it tries to identify the clock, which is a non-used 'edge' element. You have 2 unused and it gets confused. Try to remove KEY[2] from the sensitivity list.
– Serge
Nov 22 at 19:47
1
1
I guess it tries to identify the clock, which is a non-used 'edge' element. You have 2 unused and it gets confused. Try to remove KEY[2] from the sensitivity list.
– Serge
Nov 22 at 19:47
I guess it tries to identify the clock, which is a non-used 'edge' element. You have 2 unused and it gets confused. Try to remove KEY[2] from the sensitivity list.
– Serge
Nov 22 at 19:47
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
You are mixing combinational logic and synchronous logic in the always
block and this is bad habit of coding. Generally, there are 2 main always
blocks in most designs.
A combinational:
always@(*) // * adds anything under this always block to sensitivity list.
begin // Which makes this always block combinational.
count_reg_d <= somelogic;
end
Then these combinational logic is assigned to proper registers in the sequental
always block:
always@(posedge clk, negedge rst)
begin
if(~rst)
count_reg_q <= 0;
else
begin
count_reg_q <= count_reg_d;
end
end
By coding this way you avoid mixed always blocks, and the code is much more readable and closer to hardware that is being synthesized. So if you update the always
blocks' sensitivity list properly the problems has to be solved.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
You are mixing combinational logic and synchronous logic in the always
block and this is bad habit of coding. Generally, there are 2 main always
blocks in most designs.
A combinational:
always@(*) // * adds anything under this always block to sensitivity list.
begin // Which makes this always block combinational.
count_reg_d <= somelogic;
end
Then these combinational logic is assigned to proper registers in the sequental
always block:
always@(posedge clk, negedge rst)
begin
if(~rst)
count_reg_q <= 0;
else
begin
count_reg_q <= count_reg_d;
end
end
By coding this way you avoid mixed always blocks, and the code is much more readable and closer to hardware that is being synthesized. So if you update the always
blocks' sensitivity list properly the problems has to be solved.
add a comment |
up vote
2
down vote
You are mixing combinational logic and synchronous logic in the always
block and this is bad habit of coding. Generally, there are 2 main always
blocks in most designs.
A combinational:
always@(*) // * adds anything under this always block to sensitivity list.
begin // Which makes this always block combinational.
count_reg_d <= somelogic;
end
Then these combinational logic is assigned to proper registers in the sequental
always block:
always@(posedge clk, negedge rst)
begin
if(~rst)
count_reg_q <= 0;
else
begin
count_reg_q <= count_reg_d;
end
end
By coding this way you avoid mixed always blocks, and the code is much more readable and closer to hardware that is being synthesized. So if you update the always
blocks' sensitivity list properly the problems has to be solved.
add a comment |
up vote
2
down vote
up vote
2
down vote
You are mixing combinational logic and synchronous logic in the always
block and this is bad habit of coding. Generally, there are 2 main always
blocks in most designs.
A combinational:
always@(*) // * adds anything under this always block to sensitivity list.
begin // Which makes this always block combinational.
count_reg_d <= somelogic;
end
Then these combinational logic is assigned to proper registers in the sequental
always block:
always@(posedge clk, negedge rst)
begin
if(~rst)
count_reg_q <= 0;
else
begin
count_reg_q <= count_reg_d;
end
end
By coding this way you avoid mixed always blocks, and the code is much more readable and closer to hardware that is being synthesized. So if you update the always
blocks' sensitivity list properly the problems has to be solved.
You are mixing combinational logic and synchronous logic in the always
block and this is bad habit of coding. Generally, there are 2 main always
blocks in most designs.
A combinational:
always@(*) // * adds anything under this always block to sensitivity list.
begin // Which makes this always block combinational.
count_reg_d <= somelogic;
end
Then these combinational logic is assigned to proper registers in the sequental
always block:
always@(posedge clk, negedge rst)
begin
if(~rst)
count_reg_q <= 0;
else
begin
count_reg_q <= count_reg_d;
end
end
By coding this way you avoid mixed always blocks, and the code is much more readable and closer to hardware that is being synthesized. So if you update the always
blocks' sensitivity list properly the problems has to be solved.
edited Nov 26 at 20:01
answered Nov 24 at 10:27
Talip Tolga Sarı
736
736
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53434962%2fcant-use-else-in-verilog-always-block%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I guess it tries to identify the clock, which is a non-used 'edge' element. You have 2 unused and it gets confused. Try to remove KEY[2] from the sensitivity list.
– Serge
Nov 22 at 19:47