I have a question about this piece of verilog code:

  reg [31:0]ain = 3;
  reg aout = 0;
  reg bout = 0;
  always @(posedge clk)// A
      if (ain == 3)
          aout = ~aout;
  always @(posedge clk)// B
      if (aout == 0)
          bout = ~bout;

Basically this has 2 always@(posedge clk) blocks(a and b) where the second uses a variable set in the first. Now assume this entire thing isn't optimized away and ain could have more values maybe.

I'm wondering what version or time of aout block B would use, since both blocks run at the same time. Would it be undefined behavior as A and B run at the same time? Or will B always use the value of aout that was set by A previous clock cycle? Or would it completely depend on whether A can complete before B?

The reason I want to know is because I want to create a riscv cpu where the instruction fetch and decoder and such are separated(instead of all combined like I have now) so that I can have it execute more instructions per second.

Also, what would be the best approach if I wanted to make sure B used the aout of A in the previous cycle?(So the result A set aout to at the end of previous clk)


Edit: It appears my question might be a bit vague so I will try and clarify. Currently my understanding(which I think is correct) is that A and B will be executed at the same time(in parallel), meaning that aout will change during the execution of A. However, B is trying to use the aout register for it's own logic. So my question is, will aout change value before or after it is used in the if by B? Or does it depend on whether the A block finishes before the if in block B? I need to know this so I can make sure that when I have more variables that I wont try to use the output from a half executed block.

  • 4
    \$\begingroup\$ Does this answer your question? Why we need non-blocking assignments in Verilog? \$\endgroup\$
    – dave_59
    Aug 4, 2020 at 22:06
  • \$\begingroup\$ No, I know about non blocking and blocking assignment. What I mean is 2 seperate always@'s, and when they will read and write their results. Basically, does the snippet in the op cause a "race condition" as it's called in programming language or will it "save" the old variable values and use that in the new cycle? Edit: I updated the op \$\endgroup\$
    – user237250
    Aug 4, 2020 at 23:47
  • 1
    \$\begingroup\$ If you understood the need for non-blocking assignments, you would not have this question. It is eactly to prevent race conditions. \$\endgroup\$
    – dave_59
    Aug 5, 2020 at 2:46

2 Answers 2


Choice of programming language aside, you have logic that feeds a clocked register. In any real device the register will save the value that was present on its input just prior to the clock edge.

Most FPGAs on the market have zero (or even negative) hold time requirements on the registers. This guarantees that no changes at the output of any register can be saved by another register until the next clock cycle. I suspect this is true for most ASIC technologies as well.

So the if statement in the first process must use the value of "ain" just prior to the clock edge. The second process must use the value of "aout" just prior to the clock edge.

Therefore the second process won't see any changes made by the first process until the next clock cycle.


Always keep the circuitry/schematic in mind when coding HDL. The code you wrote is just a description of the circuitry you want.

*** --->|    |--aout--***-->|    |--bout-->
        |    |              |    |
        |_CK_|              |_CK_|
          ^                   ^

(I omitted other signals for simplicity.)

I assume the above is what you want to design. The 2 DFFs function in parallel. So the idea is: for the same active clk edge, bout register update its output using aout which is generated at the former clk edge. The same is done for aout register. Although this still has to be guaranteed by timing analysis to avoid any hold time violation.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.