Implicit event_expression list

[Allan Herriman]

Hi,

I'm having a problem with the following code (which is a simplified
version of some code that I inherited).


Simulators don't seem to mind, but XST produces the following error
message:
ERROR:HDLCompilers:168 - <filename> line <number> No signals
referenced in statement with implicit sensitivity list


module foobar ();

localparam foo = 0;
reg bar;

always @*
begin
bar = foo;
end

endmodule


Is this code meaningful? Will bar get the value of foo? Or is it a
problem in XST?

Regards,
Allan

 

Hi, If you dont have any ports in your design the tool wont synthesize
it to anything. imagine a design using no inputs and giving no outputs.
-Neo

 

[Allan Herriman]

On 24 Jan 2005 05:36:14 -0800, zingafriend@yahoo.com wrote:

Hi, If you dont have any ports in your design the tool wont synthesize
it to anything. imagine a design using no inputs and giving no outputs.

Thanks for that gem of wisdom, Neo.

As I said, the code is a simplified version of something else. The
I/O is irrelevant to the question.

Allan

 

[Swapnajit Mittra]

A localparam (or parameter, for that matter) is a run time constant.
When the implicit sensitivity list expands to hold all the right hand
side variables that occur within that always block, it sees a
constant, which by definition can not change value. This is the
dilemma faced by your tool that produces that error.

- Swapnajit.
--
SystemVerilog, DPI, Verilog PLI and all other good stuffs.
Project VeriPage: http://www.project-veripage.com
For subscribing to the mailing list:
<URL: http://www.project-veripage.com/list/?p=subscribe&id=1>

 

Technically, the @* expands to an empty event control, since constants
don't get included in the expansion. Since empty event controls are
not legal in the language, producing an error is a reasonable response.

The other reasonable response is to treat it as an event control
containing only constants. The simulation behavior of that is to wait
for the constant to change value, which never happens. So the event
control waits forever, and the statement after it never executes. That
means bar never gets the value of foo, which means that it doesn't act
like combinational logic (or like the equivalent continuous assignment,
or like what a synthesis tool will probably produce). NC-Verilog takes
this approach, but produces a warning about it, since the behavior will
probably not be what was desired.

 

Allan,
I am sorry but I realised my mistake then itself and deleted the post
but looks like it didnt get deleted.

-neo

 

Allan Herriman wrote:

In short, the coding style is wrong, and I should get the original
author to change the code. (If I've interpreted your post
correctly.)

Yes.

 

[Allan Herriman]

On 24 Jan 2005 10:32:22 -0800, sharp@cadence.com wrote:

Technically, the @* expands to an empty event control, since constants
don't get included in the expansion. Since empty event controls are
not legal in the language, producing an error is a reasonable response.

The other reasonable response is to treat it as an event control
containing only constants. The simulation behavior of that is to wait
for the constant to change value, which never happens. So the event
control waits forever, and the statement after it never executes. That
means bar never gets the value of foo, which means that it doesn't act
like combinational logic (or like the equivalent continuous assignment,
or like what a synthesis tool will probably produce). NC-Verilog takes
this approach, but produces a warning about it, since the behavior will
probably not be what was desired.

In short, the coding style is wrong, and I should get the original
author to change the code. (If I've interpreted your post correctly.)

Thanks,
Allan