Subject: Re: SystemVerilog: always_comb and functions
From: Peter Flake (flake@co-design.com)
Date: Mon Apr 01 2002 - 05:21:21 PST
Stu,
At 11:44 AM 3/28/02 -0800, Stuart Sutherland wrote:
>I would like to just throw an idea in to the arena, and leave it to you
>syntax/semantic wolves to attack... Could we add the now infamous .*
>connection to function call argument lists? It would be used to say "any
>names common within the function and the calling scope are inferred in the
>function call argument list". This would mean:
>
>- An always_comb only has to be sensitive to the function call arguments
>(listed and inferred). The function might still reference something
>outside the calling scope, but the always_comb would not be sensitive to it.
This would still require the user to list the sensitivity and therefore
enable errors.
>- The "calling scope" can be a named block. This would prevent
>sensitivity to something a function referenced several levels of up in the
>hierarchy. It would also allow different named blocks to call the same
>function, and yet connect to different signals.
This would be a new effect of scoping, because normally any visible name is
treated the same.
>- The side affects of sensitivity to static variables in automatic
>function may be reduced (I haven't thought that through).
>
>- A user has to deliberately say he intends to shoot himself in the foot.
I think it is actually less likely to cause a user to shoot himself in the
foot. My argument is that it should be possible to move an expression into
a function without changing the behavior.
function andb (input a); return a & b; endfunction
always @(posedge clock) r1 = a & b;
always @(posedge clock) r2 = andb (a); // same as a & b
always_comb r3 = a & b;
always_comb r4 = andb (a); // same as a & b
assign w1 = a & b;
assign w2 = andb (a); // not the same as a & b - shoot in foot
So I think ignoring the other variable (b) is a bug in Verilog, but
unfortunately we cannot fix it.
Peter.
This archive was generated by hypermail 2b28 : Mon Apr 01 2002 - 07:18:16 PST