Geek Answers Handbook

Verilog Always block the use of the character (*)

I have a simple question on how to always write a block in the verilog module.
If my Verilog module has the following inputs:

input [31:0] PCplus4 ; // Value of PC + 4 input [31:0] A; // Value A, ie RSbus (Use Forwarded Value) input [31:0] B; // Value B, ie RTbus (Use Forwarded Value) input [31:0] IMM; // Extended Immediate Value input [25:0] TARGET; // Target Address for Jumps input [3:0] BR; // Branch Selector Input

Is there any difference if I use

 always @ (*)

instead

 always @ (PCplus4 or A or B or IMM or TARGET or BR)

Is this always the @ (*) syntax valid for all versions of Verilog?

+4
source share
5 answers

The always @(*) syntax was added to IEEE Verilog Std in 2001. All modern Verilog tools (simulators, synthesis, etc.) support this syntax.

Here is a quote from LRM (1800-2009):

An incomplete list of event_expression event management is a common source of error in register transfer level (RTL) modeling. Implicit event_expression, @ *, is a convenient shortcut that fixes these problems by adding all the networks and variables that are read (this may be a statement to the group) of the procedure_timing_ control_statement to event_expression.

So, your two lines of code can be equivalent (it depends on the code in the body of your always block). However, the @* syntax is easier to maintain.

+10
source

always @(*) was an addition to the language as amended by the 2001 standard. It is supported by all the latest releases of quality tools. I have no problem using a construct in code intended for arbitrary reuse, but I can run into an old tool that does not support always @(*) , especially when internal utilities are involved.

+3
source

This is just a shortcut for listing all the wires that the block always depends on. These wires are a "sensitivity list". One of the advantages of using this is that the synthesized code hardly cares about what you put on the sensitivity list (except posedge and negedge), because the wires will be “physically” connected together. The simulator can rely on a list to select which events should trigger block execution. If you change the block and forget to update the list, your simulation may be at variance with the actual synthesized behavior.

0
source

Although both are equivalent, using always@ (*) avoids the mismatch between modeling and synthesis. Suppose you have 15 signals in the sensitivity list, as shown below:

 always@ ( a1 or a2 or ... or a15)

Now suppose the designer skipped the presence of a14 in this list by mistake. The synthesis tool ignores this fact and synthesizes a code assuming that all signals on the RHS in this block are in the sensitivity list. While the modeling tool behaves differently, because it depends on the list of sensitivity.

0
source

For the 1st question .... I would say that it depends on whether in the second case it is the only inputs that you feel can change, which will lead to the output being triggered. Ideally, it would be better to use *, because it indicates "for any input changes", it is also useful to avoid verbose code.

For the second question ..... it was introduced in verilog -2001, and since then it has been widely used.

0
source

More articles:


All Articles