Is this correct

[parag]

module child(clk);
input clk;
reg lhs[];
int i = 0;

always /* nosched0 */ @(lhs) $display($time,,"lhs = %b", lhs);
always /* nosched0 */ @(clk) $display($time,,"clk = %b", clk);

always @(lhs ) <-- where lhs is a dynamic array, this errors at
compile time saying that Dynamic array in dynamic context,.

Is the error msg correct. I thought always blocks are procedural
concept

 

[Jonathan Bromley]

On Thu, 9 Sep 2010 10:12:11 -0700 (PDT), parag wrote:

always @(lhs ) <-- where lhs is a dynamic array, this errors at
compile time saying that Dynamic array in dynamic context,.

Is the error msg correct. I thought always blocks are procedural
concept

I think your example is illegal for a different reason:
the result of the expression in an @() control must be
a singular value. It is therefore illegal to use the
whole of any unpacked array here.
Event expressions shall return singular values
(quoted from 1800-2009, clause 9.4.2)

Putting any large or complicated or dynamic thing in an @()
event expression seems very, very strange to me. Instead
I would think it is far more sensible to hide the array
inside a module or class, and provide an access method to
write to the array; then, execution of this access method
serves as your trigger, and the method can be instrumented
any way you like.

However, I know that some people try to do things like your
example, and expect the tools to do something sensible.
Pity the poor tool vendors, trying to implement a big
complicated language and endlessly being beaten up with
strange requests from customers for weird or non-standard
features and behaviours.

It would be interesting to try @(lhs.size()). I believe
this should be legal. Indeed, I've often seen code like

int fifo[$];
task get(output int result);
wait (fifo.size() > 0);
result = fifo.pop_front();
endtask

and I can't find any LRM objection to it.

I still think it's damn silly, though.
--
Jonathan Bromley

 

[parag]

On Sep 9, 10:42 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:

On Thu, 9 Sep 2010 10:12:11 -0700 (PDT), parag wrote:
always @(lhs ) <-- where lhs is a dynamic array, this errors at
compile time saying that Dynamic array in dynamic context,.

Is the error msg correct. I thought always blocks are procedural
concept

I think your example is illegal for a different reason:
the result of the expression in an @() control must be
a singular value.  It is therefore illegal to use the
whole of any unpacked array here.
   Event expressions shall return singular values
   (quoted from 1800-2009, clause 9.4.2)

Putting any large or complicated or dynamic thing in an @()
event expression seems very, very strange to me.  Instead
I would think it is far more sensible to hide the array
inside a module or class, and provide an access method to
write to the array; then, execution of this access method
serves as your trigger, and the method can be instrumented
any way you like.

However, I know that some people try to do things like your
example, and expect the tools to do something sensible.  
Pity the poor tool vendors, trying to implement a big
complicated language and endlessly being beaten up with
strange requests from customers for weird or non-standard
features and behaviours.

It would be interesting to try @(lhs.size()).  I believe
this should be legal.  Indeed, I've often seen code like

  int fifo[$];
  task get(output int result);
     wait (fifo.size() > 0);
     result = fifo.pop_front();
  endtask

and I can't find any LRM objection to it.

I still think it's damn silly, though.
--
Jonathan Bromley

Thanks a lot Jonathan for your answer

Just a request for review of the wordings in the error message,
Should the vendors mention this error as
Dynamic type in declarative context


is this a declarative context, I dont think so ?
Isnt it a procedural context.
I am bita confused here