About a syntax in Verilog

We write always (*) in Verilog. I have the following questions about it:

1. Is this always (*) construct only be allowed for combinational always statement?

2. Does this * here only signify all the signals at the right hand side of the assignment operator? Does it signify something else also?

1 yes
2 yes

if we need all input in the sensitivity list then we only write (*) ,always it applicable for combinational circuit.

"always @(*) " states that incase of any change in "any" input , execution will enter always block ... including * in sensitivity list , means including all inputs by default , you need not to specify all inputs ... but this works for combinational ckts only ...

whereas in sequential ckts , you have clock n other type of asynchronous , synchronous set , reset etc. etc. signal too .... so you need to specify this in sensitivity list , you can't write * here ... ur ckt specifcation will determine which signal to include ...

jeet_asic or tiwari.ankur

You wrote "always @(*) " states that incase of any change in "any" input , execution will enter always block". What do you mean by any inputs here? Do you want to mean by any input any of the inputs to the modules? Or, does your any input mean the signals or inputs at the right hand side of the assignment statements inside the combinational always statement. Because all inputs of a module may not be the signals or inputs at the right hand side of the assignment statements inside the combinational always statement.

sun_ray
thanks for remind
all input inside module is applicable for this.......

jeet_asic or tiwari.ankur


Do you want to mean that the * will mean some signals which are not at the right hand side of assignments if the right hand side of the assignment does not include all inputs to the module? Please answer this question again.

Regards

all input inside module is applicable for this.......

Click to expand...

That's slightly different from what the Verilog specification says about implicite event expression lists. It talks about all variables that are read by the statement respectively statement group in the always block.

I guess however, you'll have some difficulties to set up an example that creates a difference between the exact meaning according to the Verilog specification and assumed "all input inside module". I'm curious, if you find some. You should also consider, that level sensitive event expressions are ignored in logic synthesis and only matter in simulation.

@* is an event control. It does not know anything about input/outputs, or combination logic for that matter. It simply builds an implicit sensitivity list by looking at the identifiers in the single statement that follows it. (that single statement could be a begin/end block). If you have


then @* is replaced with @(A or B or C).G is not included because it is not part of the statement that appears after the @*. D is not included because it only appears as an lvalue (target of an assignment), and E is not included because it only appears in an event control.

Synthesis rules usually require that only one event control can appear in an always construct and must be the first token in the construct, and no other event controls are allowed in the construct. That is why you always see always @* together.

SystemVerilog replaced always @* with always_comb and always_latch. This is preferable because there are many problems with @*.

First is if any of the identifiers are parameters or constants, the construct does not execute unless there is some other event. always_comb will always execute at time 0. Then the result will be correct from time 0.
parameter A=1;
always @* C = A | B;
This does not execute until there is a event on B.
The other problem with @* is that it ignores identifiers embedded in function, whereas always_comb expands the function.

always @* Z = func() && W;
function reg func;
func = X | Y;
endfunction

Only W is put on the sensitivity list.
If you use SystemVerilog's always_comb, W, Y and Y are put on the sensitivity list.

Dave

FvM said:

That's slightly different from what the Verilog specification says about implicite event expression lists. It talks about all variables that are read by the statement respectively statement group in the always block.

Click to expand...

FvM

What do you mean by " all variables that are read by the statement respectively statement group in the always block"? Do you want to mean all variables at the right hand side of all the assignments statements inside the always block?

---------- Post added at 08:33 ---------- Previous post was at 08:23 ----------

Is that the level sensitive event expressions are ignored in logic synthesis even if this always @ (*) block is inside the generate and endgenerate statement where the always blocks ar conditionally instantiated.

Do you want to mean all variables at the right hand side of all the assignments statements inside the always block?

Click to expand...

As said, I was just quoting the Verilog standard, in so far it's not a question of what I want to mean. But in my understanding "read variables" means just this. I think however, that Dave has given a much more detailed explanation.

P.S.: I didn't want to start a big discussion on the role of event expressions in synthesis, just mention a simple fact. The topic has been discussed at Edaboard before. Event expressions are nevertheless necessary to achieve correct simulation results and are thus claimed by synthesis tools as well.

FvM said:

As said, I was just quoting the Verilog standard, in so far it's not a question of what I want to mean. But in my understanding "read variables" means just this.

Click to expand...

FvM

Your answer was not clear. Can you please answer these questions so that the answer become clear : What does the Verilog Spec mean by " all variables that are read by the statement respectively statement group in the always block"? Does the verilog spec want to mean all variables at the right hand side of all the assignments statements inside the always block?



The example in the post of Dave was complex, a more simpler code would have brought more clarity. So there are still question on the reply of dave. However if you can answer the above question, things are expected to be clear as you are quoting directly from Verilog Spec.

Rather than asking me for a clear answer, you would want to review the text yourself. There are also examples added, refer to the original document if you're interested.

9.7.5 Implicit event_expression list

The event_expression list of an event control is a common source of bugs in register transfer level (RTL) simulations. Users tend to forget to add some of the nets or variables read in the timing control statement. This is often found when comparing RTL and gate-level versions of a design. The implicit event_expression, @*, is a convenient shorthand that eliminates these problems by adding all nets and
variables that are read by the statement (which can be a statement group) of a procedural_timing_control_statement to the event_expression.

All net and variable identifiers that appear in the statement will be automatically added to the event expression with these exceptions:
— Identifiers that only appear in wait or event expressions.
— Identifiers that only appear as a hierarchical_variable_identifier in the variable_lvalue of the left-hand side of assignments.

Nets and variables that appear on the right-hand side of assignments, in function and task calls, in case and conditional expressions, as an index variable on the left-hand side of assignments, or as variables in case item expressions shall all be included by these rules.

Click to expand...

My answer was biased in that I want people to avoid using @*. I am trying to show the problems it has. Let my try to explain it in the simple terms.
The always and @* are two separate constructs. You could write
and the @* here is a shortcut for writing @(B or C or i or E or F). The statement group in this example is a begin/end block. It could have been a fork/join block, or just a single statement. My point is it that according to the Verilog spec it doesn't matter if this code represent combinatorial logic or not (And in this case, it is not combinatorial because I used an initial construct). All that matters to @* is that it will build a list of variables for an event list from all the variables that appear in the statement or block statement that follows it. There are only two exceptions: variables that only appear as a target of an assignment, and those that only appear in an event control.

The Verilog Spec, now called IEEE SystemVerilog 1800-2009, does not define what is synthesizable; that is up to each individual synthesis tool.