what is the difference berween these two cases?

[yuzhicai]

I met two cases like following:

1.
always @ (a or b or c or d)
if (a && b)
out <= c;
else if (a)
out <= d;
else
out <= 1'b0;

2.
always @ (a or b or c or d)
if (a && b)
out <= c;
else if (a && ~b)
out <= d;
else
out <= 1'b0;

what is the difference between these two cases. Which is the better?

 

[hunter694]

Hi,

case 2 takes 1 AND gate more than case 1 to achieve the same result. so that's a drawback.

however, if you are using this code for simulation you have to be on your guard since if 'b' goes to 'x' it will always match the first condition if a == 1

Regards,
Hunter

 

[yuzhicai]

I simulated these two cases with VCS.
In case 1, out is always equal to d. But the case 2 is normal. Why?

 

[masai_mara]

I think the previous reply explains it. In the first case the value of b dosent matter for the out to take 'd'. so basically it will be optimized and you'll have a anded with d being selected.

 

[seseandy]

because your code will generate combinational logic and to follow good coding style,you should use blocking assignment,instead of non-blocking assignment.

 

[reddy]

In both the cases you should use Blocking, as it is combinational implememtation.
As per your doubt, in Case1, a=1 and b!=1. In this case, b can have x/z. So, you are always c=d. But in Case2, you are externally checking for b to be equal to 0. This definitely makes difference.
You try out the exact scenerio now, and let me too know if am confusing u!!!

thanks,
-reddy

 

[reddy]

In both the cases you should use Blocking, as it is combinational implememtation.
As per your doubt, in Case1, a=1 and b!=1. In this case, b can have x/z. So, you are always c=d. But in Case2, you are externally checking for b to be equal to 0. This definitely makes difference.
You try out the exact scenerio now, and let me too know if am confusing u!!!

thanks,
-reddy

 

[xmizi]

Let me see if I can explain clearer:

Since you're using non-blocking, in Case 1, even if both a and b are 1, c is not assigned to out immediately, c is just scheduled to assign to out later, so when it comes to "else if (a)", obviously it is satisfied, so d is again scheduled to be assigned to out, so finally no matter what, you'll get out = d. But in Case 2, the second "else if (a && ~b) avoid that senario, so it is normal.
Try always use blocking assignment in combinational logic.