parag
Guest
Thu Sep 09, 2010 8:12 pm
module child(clk);
input clk;
reg lhs[];
int i = 0;
always /* nosched0 */ @(lhs) $display($time,,"lhs = %b", lhs[i]);
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
Guest
Thu Sep 09, 2010 8:12 pm
On Thu, 9 Sep 2010 10:12:11 -0700 (PDT), parag wrote:
Quote:
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
Guest
Tue Sep 14, 2010 10:26 am
On Sep 9, 10:42 pm, Jonathan Bromley <s...@oxfordbromley.plus.com>
wrote:
Quote:
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
