I was going through some reference design from Altera's Wiki and ran into the following piece of code:

always @* begin
   in_ready <= out_ready || ~out_valid;

My understanding is that having a flip-flop like that helps get more deterministic timing, synthesis tool can refuse to synthesize if out_ready || ~out_valid combinatorial delay exceeds the limit and timing requirements are not met etc. Other than that, that should be en equivalent of the following combinatorial description:

assign in_ready = (out_ready || ~out_valid);

What made me think about it is the larger piece of code that I am readying. Sometimes combinatorial logic is used to drive the "ready" output of some modules, but sometimes this style. I cannot really spot a functional difference and see an obvious explanation.

I've read somewhere that combinatorial logic is not welcome in FPGAs because of timing issues and synchronized design is always preferred, and this project specifically targets FPGAs. But the mixing is what confuses me. So two questions popped out in my head:

  1. When and why one solution should be preferred over another?
  2. Is there any difference in behavior (or analysis of the design) when the output of the module is "reg" versus when it is a "wire"?

Any help is appreciated. Thank you.


2 Answers 2


If you use a flip flop, then changes in the combinational logic will only "appear" on the output of the flop on a clock edge. In general, with combinational logic, you will get all sorts of spurious transitions while the logic is "settling" on it's eventual value. If spurious transitions are a bad thing in your overall design (most likely they are), you will want to "filter them out" using a flip flop in this way. These transient changes in combinational outputs when inputs change are generally called "hazards."

In terms of the hardware you are generating in both cases, you will get the same combinational logic generated in your FPGA in both cases (out_ready || ~out_valid). The difference is, in the one case you are simply aliasing the output net of the combinational logic with the name in_ready, whereas in the other case you are connecting the output of the combinational logic to the input of a clocked flip flop.

In summary, there's nothing wrong with combinational logic, and you'd be hard pressed to design something useful in an FPGA that didn't include a bunch of it. Running the output through a flip flop isolates the next "stage" (i.e. the consumer) of your logic from seeing the spurious transitions of that logic that happen inherently when the inputs change (this design pattern, incidentally, is what pipelining - e.g. in modern CPUs - is all about). Remember to think of FPGAs and digital logic as hardware when writing Verilog (because that's what they are after all)!

Also, on a sidenote, determinism is not something that is measured on a sliding scale - something either is or is not deterministic, end of story.

  • 2
    \$\begingroup\$ Just to note, the two code snippets will produce the same combinatorial logic since there is no @(posedge/negedge clk) statement in the first one. \$\endgroup\$
    – Oli Glaser
    Commented Jun 21, 2012 at 10:58
  • \$\begingroup\$ Thanks. What I don't understand is how clock is related to the flip-flop in this case as there is no clock mentioned in sensitivity list. To my understanding, something determined to be a clock if it appears in sensitivity list as pos/neg-edge triggered input and is not used anywhere on the right hand side expressions inside a corresponding block. Thus I have a feeling that there is absolutely no difference between two descriptions, except the register is used in one case and not the other. Or does synthesis tool trace origins and relate that block to clock(s) driving out_ready and out_valid? \$\endgroup\$
    – user8459
    Commented Jun 21, 2012 at 12:18
  • 3
    \$\begingroup\$ There is no difference in the two descriptions, just a different way of writing them. So there is no FF involved - if you synthesise and look at the results from your synthesis tool for both cases you should see the same thing. If you put always @(posedge clk) (you need a clk input to the module) you should see a FF along with the combinatorial logic. \$\endgroup\$
    – Oli Glaser
    Commented Jun 21, 2012 at 15:16
  • \$\begingroup\$ @OliGlaser: That is something I was not able to find in my books. Thank you very much. \$\endgroup\$
    – user8459
    Commented Jun 21, 2012 at 17:28

All flipflops are driven by combinatorial logic (although it might be very simple logic, like a wire!), you can't sensibly avoid combinatorial logic.

D-type flipflop

The logic drives the 'D' pin of the flipflop and the value is copied to the Q output on (usually) the rising edge of the clock input.

The reason it is recommended to ensure that each of your submodules within a large design has flipflops on its outputs is that it help to break the logic up into separate chunks which are independent of each other in terms of timing. You don't get surprised by a long chain of logic "appearing" when you cascade a bunch of supposedly independent modules.

Sometimes however, you can't afford to wait for the next clock cycle - ready/valid signals are often like that, and then you have no choice but to feed the combinatorial signal "raw" out to the consumer.

  • \$\begingroup\$ Thanks. This is what I thought, though I am not clear how clock is related to that particular construct as it is not being mentioned anywhere. Does synthesis tool trace drivers of out_ready and ~out_valid (and further) to determine clock related to the change, if any? What if there is no clock? \$\endgroup\$
    – user8459
    Commented Jun 21, 2012 at 12:23
  • \$\begingroup\$ @VladLazarenko: Sorry, my answer may have been a bit confusing - the clock is not related to the construct you've written. If you don't ask for a clock, you don't get one. If you want a flipflop, you need to use something like always @clk to tell the synthesiser only to change things when the clock does. \$\endgroup\$ Commented Jun 22, 2012 at 7:36

Your Answer

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