What is the maximum limit of signals in sensitivity list of always block?

Question

I am working on a project with multiple signals required in the sensitivity list. I want to know is there any maximum limit of signals that can be present in the sensitivity list of the always block in the Verilog code?

Answer 1

There is no limit as far as the Verilog language is concerned. However, more signals in your sensitivity list implies more combination logic which could be a limiting factor in meeting the timing requirements of the synthesized logic it represents.

BTW, you should not be explicitly listing signals in your sensitivity list. Instead you should be using implicit sensitivity with always @* or always_comb in SystemVerilog.

Answer 2

The Verilog language itself does not have a limit, but software and hardware does have limits; even with always @*. Over 10 years ago I worked on an unusual BFM that did hit the limit for some simulators. Depending on the simulator it ranged between 2¹⁶-1 bits and 2³⁰-1 variables. Modern simulators could have higher limits but there hasn't been much demand for it; so maybe no changes. It is rare for a single always block to need to be sensitive to more than 65535 bits and still meet timing and resource requirements. It is possible that your simulator/synthesizer/etc. could have a lower software/hardware limit but odds are you will not reach it with reasonable code.

For synthesizable combinational logic, the only legitimate reason to specify the sensitivity list would be if you are required to follow the IEEE1364-1995 standard or pre-IEEE standard. Legacy systems and some school assignments are the main things that require this. Since IEEE1364-2001 became widely supported, it preferred to use always @* (or the synonymous always @(*)) with Verilog. Better still is to use SystemVerilog's always_comb.

For combinational logic inside non-synthesizable BFMs, it would be needed if you need to exclude signals/edges that would have been picked up by @*. Or you are trying to include something that isn't picked up by @*; such as event type variables. Both conditions are corner cases. For the most part, implicit selectivity should be used for combinational logic even inside non-synthesizable BFMs.