Use of * as sensitivity list

[mk]

I recently saw a code where * is used as sensitivity list to create a
combinational logic.

It looked like this.

always (*)
begin
Case (Bus_name) // FSM
.
.

end

I've always seen the signals being specified explicitly. I'm not sure
it is okay to use * instead. If used, can someone tell me if there is
any potential side effect (such as mismatch between post synthesis
netlist and the RTL model and so on ..)?

Thanks in advance

 

[Andy Ray]

mk wrote:

I recently saw a code where * is used as sensitivity list to create a
combinational logic.

It looked like this.

always (*)
begin
Case (Bus_name) // FSM
.
.

end

I've always seen the signals being specified explicitly. I'm not sure
it is okay to use * instead. If used, can someone tell me if there is
any potential side effect (such as mismatch between post synthesis
netlist and the RTL model and so on ..)?

Thanks in advance

This makes the simulator/synthesizer work out all the signals in the
sensitivity list and make the always block depend on all of them
(always_comb is another name I think). It is designed to avoid
synthesis/simulation mismatches and generation of latches based on
incomplete sensitivity lists.

It's probably verilogs best feature, but your mileage may vary depending
on the tools you use.

I believe the notation "always (*)" is better written as "always *" as
the former (apparently) makes the verilog grammar more difficult to parse.

Cheers,

Andy

 

[mk]

Thank you for the clarification. The Lint tool does show up this as an
error. But by specifying Verilog-2001 option, it does not show this as
an error. My concerns was about the simulation mismatches between post
synthesis netlist and the RTL. Seems like that's not an issue.

Regards,
MK


Andy Ray wrote:

mk wrote:
I recently saw a code where * is used as sensitivity list to create a
combinational logic.

It looked like this.

always (*)
begin
Case (Bus_name) // FSM
.
.

end

I've always seen the signals being specified explicitly. I'm not sure
it is okay to use * instead. If used, can someone tell me if there is
any potential side effect (such as mismatch between post synthesis
netlist and the RTL model and so on ..)?

Thanks in advance




This makes the simulator/synthesizer work out all the signals in the
sensitivity list and make the always block depend on all of them
(always_comb is another name I think). It is designed to avoid
synthesis/simulation mismatches and generation of latches based on
incomplete sensitivity lists.

It's probably verilogs best feature, but your mileage may vary depending
on the tools you use.

I believe the notation "always (*)" is better written as "always *" as
the former (apparently) makes the verilog grammar more difficult to parse.

Cheers,

Andy

 

mk wrote:

I recently saw a code where * is used as sensitivity list to create a
combinational logic.

It looked like this.

always (*)

You left out the @ symbol.

I've always seen the signals being specified explicitly. I'm not sure
it is okay to use * instead. If used, can someone tell me if there is
any potential side effect (such as mismatch between post synthesis
netlist and the RTL model and so on ..)?

This feature was added in Verilog-2001. One of its goals is actually
to avoid mismatches between pre- and post-synthesis. A synthesis tool
is going to produce combinational logic, which will be sensitive to all
of its inputs, whether you wrote it that way in the RTL or not. So the
synthesis tool will effectively fill in any signals you left out. A
simulator will do what you told it to do. So an explicit list with
missing signals will behave differently pre- and post-synthesis.

By using @*, the simulator will fill in all the signals, so it will
match what the synthesis tool is going to do anyway.

 

[gabor]

Andy Ray wrote:
[snip]

I believe the notation "always (*)" is better written as "always *" as
the former (apparently) makes the verilog grammar more difficult to parse.

Cheers,

Andy

I usually write

always @ (*)

because it looks more like

always @ (sig1, sig2, ...)

but I'm not sure why the parentheses should matter. I have noticed
that the Xilinx ISE editor likes to paint the (*) grey as if it has
some
other syntactical meaning to the parser (comments?). In any case
either syntax works with XST synthesis and Modelsim.

Regards,
Gabor

 

[John_H]

I recently started using the syntax for including attributes in my code
without using a

/* synthesis yadayada */

style comment. Instead, there's direct support for

(* yadayada *) object

attribute syntax. I can see now why the (*) could confuse a parser.

- John_H


"gabor" <gabor@alacron.com> wrote in message
news:1156538457.438882.268020@74g2000cwt.googlegroups.com...

Andy Ray wrote:
[snip]
I believe the notation "always (*)" is better written as "always *" as
the former (apparently) makes the verilog grammar more difficult to
parse.

Cheers,

Andy

I usually write

always @ (*)

because it looks more like

always @ (sig1, sig2, ...)

but I'm not sure why the parentheses should matter. I have noticed
that the Xilinx ISE editor likes to paint the (*) grey as if it has
some
other syntactical meaning to the parser (comments?). In any case
either syntax works with XST synthesis and Modelsim.

Regards,
Gabor

 

gabor wrote:

but I'm not sure why the parentheses should matter. I have noticed
that the Xilinx ISE editor likes to paint the (*) grey as if it has
some
other syntactical meaning to the parser (comments?).

The characters '(*' are used to start an attribute declaration, and the
characters '*)' are used to end one. So it is easy for a parser to
confuse (*) with the attribute syntax. It has to do extra work to
figure out what you meant. Fortunately, an attribute is not legal at
that position, or it would have been much worse. It would have been
simpler for tools if the parentheses had not been allowed. However,
most tools have probably hacked around this issue already. The parser
in your editor may not have done so.

Other tools may have problems if you put spaces in various places,
depending on how thoroughly they handled the issue. For example, they
might have handled the '(*' at the start of '@ (*)', but not the '*)'
at the end of '@ ( *)'. Or they might have treated '@(*)' as a
single token, and not handle it if you put spaces anywhere in it.

 

[Daniel O'Connor]

sharp@cadence.com wrote:

This feature was added in Verilog-2001. One of its goals is actually
to avoid mismatches between pre- and post-synthesis. A synthesis tool
is going to produce combinational logic, which will be sensitive to all
of its inputs, whether you wrote it that way in the RTL or not. So the
synthesis tool will effectively fill in any signals you left out. A
simulator will do what you told it to do. So an explicit list with
missing signals will behave differently pre- and post-synthesis.

By using @*, the simulator will fill in all the signals, so it will
match what the synthesis tool is going to do anyway.

I'm inclined to not use it because it stops the synthesis tool warning you
that you missed a signal which can mean you haven't taken something into
account.

--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C