Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

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;

10 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    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
    
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

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

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- Quote Start ---

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

    --- Quote End ---

    Not really strange - they are functionally identical.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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