Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Honored Contributor I
1,650 Views

What's the difference between these two pieces of simple code?

Do you think there is a difference in functionality between these codes? 

always @(posedge clk) begin A<=0; if (sel==0) A<=in_u; else A<=in_v; end 

 

always @(posedge clk) begin if (sel==0) A<=in_u; else A<=in_v; end always@(posedgeclk) A<=0;
0 Kudos
10 Replies
Highlighted
Honored Contributor I
4 Views

Yes. The first one will select between in_u and in_v. 

In the second one A will be X when the selected input is 1 (and in synthesis, you'll get a multiple driver error)
0 Kudos
Highlighted
Honored Contributor I
4 Views

But how come the first one will not get an error since I am also assigning 0 to A initially. For the second case, I am just doing the same thing, but moving the resetting part to another sequential clock process.

0 Kudos
Highlighted
Honored Contributor I
4 Views

 

--- Quote Start ---  

But how come the first one will not get an error since I am also assigning 0 to A initially. For the second case, I am just doing the same thing, but moving the resetting part to another sequential clock process. 

--- Quote End ---  

 

 

They are not the same, because the assignment to A in the first always block is always overriden, so A can only be in_u or in_v 

In the second one, A is always assigned to 0, but it is also always assigned to in_u or in_v. In this case, if the selected signal is 1, then the 1 drives against 0 to give X
0 Kudos
Highlighted
Honored Contributor I
4 Views

Okay, so that simply means: 

1) Assignment in different 'always' blocks --> they are evaluated in parallel, resulting in multiple driver error 

2) Assignment in the same 'always' block --> they are evaluated in sequential, where it will reset initially before going into a MUX
0 Kudos
Highlighted
Honored Contributor I
4 Views

 

--- Quote Start ---  

Okay, so that simply means: 

1) Assignment in different 'always' blocks --> they are evaluated in parallel, resulting in multiple driver error 

2) Assignment in the same 'always' block --> they are evaluated in sequential, where it will reset initially before going into a MUX 

--- Quote End ---  

 

 

You need to understand the underlying hardware. 

1) It generates 2 bits of logic that have both outputs wired together. Each always block creates some logic. 

2) Yes - but there is no reset occuring, because the assignment to 0 is overriden and thus ignored.
0 Kudos
Highlighted
Honored Contributor I
4 Views

Ill just clarify: 

 

always @(posedge clk) begin A<=0; if (sel==0) A<=in_u; else A<=in_v; end  

 

is identical to this: 

 

always @(posedge clk) begin A<=in_v; if (sel==0) A<=in_u; end
0 Kudos
Highlighted
Honored Contributor I
4 Views

I tried both pieces of code on Vivado. Strange enough, they both passed!

0 Kudos
Highlighted
Honored Contributor I
4 Views

 

--- Quote Start ---  

I tried both pieces of code on Vivado. Strange enough, they both passed! 

--- Quote End ---  

 

 

Not really strange - they are functionally identical.
0 Kudos
Highlighted
Honored Contributor I
4 Views

 

--- Quote Start ---  

Not really strange - they are functionally identical. 

--- Quote End ---  

 

 

I was referring to the code in my initial post. Code# 2 failed in Quartus due to multiple driver error, but passed in Vivado
0 Kudos
Highlighted
Honored Contributor I
4 Views

Was the project set up correctly? Was A removed?

0 Kudos