In SystemVerilog, always_comb blocks must always specify the value of all the signals within them for all possible case branches to avoid latches.

However, are these latches generated if one of those variables is assigned to its current value?

In other words, having something like:

always_comb begin
   case (cs)
   2'b00: {a, b} = {some_signal, 0};
   2'b01: {a, b} = (a, 1};
   2'b10: {a, b} = {0, 0};

Will the above generate a latch because the state 01 assigns a to its previous value?

  • \$\begingroup\$ Yes. Why else would you do this? \$\endgroup\$
    – Dave Tweed
    Jun 22 at 12:46
  • \$\begingroup\$ Sorry, I have edited the question to clarify. What I want precisely is to avoid latches, because I'm aware they are discouraged. \$\endgroup\$
    – Martel
    Jun 22 at 13:00
  • \$\begingroup\$ Please edit the question to explain what you trying to achieve (XY Problem?). The line you mention results in a latch for a and the lack of an output for cs=11 results in latches for both a and b. The block explicitly defines these latches, so it becomes a matter to understand what is actually supposed to be implemented: if the module is supposed to implement storage, it probably should be implemented with FFs. \$\endgroup\$
    – devnull
    Jun 22 at 13:39
  • 1
    \$\begingroup\$ You should simulate it and synthesize it, then update your question if you don't understand the result. \$\endgroup\$
    – toolic
    Jun 22 at 22:38

1 Answer 1


2'b01: {a, b} = (a, 1};

This will result in combinatorial loop on a because you are feeding back the output of the combi logic (say \$a =f(\text{cs}, \text{some_signal})\$) back to its input without any register in between (Making the combi logic function \$a=f(\text{cs}, \text{some_signal}, a)\$. A path like this cannot be verified for timing by a Timing Analyzer, and its behavior is undefined.

Will the above generate a latch because the state 01 assigns a to its previous value?

You have not defined what should the combi logic do if cs = 11 inside the case statement. So Synthesiser will add latches on a and b to hold their previous values in case cs = 11. This is assumed to be the intent of the designer by Synthesiser.

Something like this is synthesised on a for example:

enter image description here

The construct always_comb in SV, unlike always @(*) in Verilog, is strictly used to model combinatorial logic. So if the RTL within it is inferring latch, it should be notified at the compile stage and flagged as error.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.