FPGA Central

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

On 24 Jan 2005 05:36:14 -0800, [email protected] 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

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.

On 24 Jan 2005 10:32:22 -0800, [email protected] 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

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.