iverilog-devel

[Iverilog-devel] $monitor/$strobe and friend (pr1780480).

[Cary R. <cy...@ya...>]

A recent patch I submitted prevents these from crashing the simulator when
given calculated values (bits[i]+1, etc.), but they still do not always
work correctly. The basic problem is that the expressions need to be
calculated when the system functions run not when they are called. An
additional problem for $monitor is that any change to this expression
needs to trigger a cbValueChange call back.

I believe the $strobe family can be fixed by replacing the code generated
by draw_eval_* (in tgt-vvp/draw_vpi.c) with some sort of simple anonymous
function creation and call. It needs scope information to find the correct
variables but it doesn't need arguments and only has a single return
value. We may need vector and real versions. These anonymous functions are
only needed until the $strobe finishes executing.

To get $monitor to work correctly the anonymous function needs to get a
bit smarter. It needs to be able to create cbValueChange call backs for
all the variables or pieces of a variable it references when it is asked
to provide a cbValueChange call back. The anonymous functions for $monitor
would need to be persistent.

Does this sound like a reasonable plan? Any suggestions? Would an
anonymous and possible temporary continuous assignment be a better
solution?

FYI once this is implemented we will likely no longer need the scheduled
thread bits deletion so that can be removed.

I believe something similar to this will be needed to fix the
$fscanf/$sscanf problem (pr1876798). The data is propagating the other
way, but the rest is close to what we need for $strobe.

Cary


      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

Re: [Iverilog-devel] $monitor/$strobe and friend (pr1780480).

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> A recent patch I submitted prevents these from crashing the simulator when
> given calculated values (bits[i]+1, etc.), but they still do not always
> work correctly. The basic problem is that the expressions need to be
> calculated when the system functions run not when they are called. An
> additional problem for $monitor is that any change to this expression
> needs to trigger a cbValueChange call back.

The basic problem is that the way Verilog is defined, if you pass
an expression to a system task/function, the system task will get
a handle to the *expression* and not the value that it evaluates to.
I thought that to be pretty nuts (I still do) but the odd-ball tasks
$strobe and $monitor indirectly rely on that interpretation. Look at
all the various kinds of expression nodes are supported by the VPI:-(

> I believe the $strobe family can be fixed by replacing the code generated
> by draw_eval_* (in tgt-vvp/draw_vpi.c) with some sort of simple anonymous
> function creation and call. It needs scope information to find the correct
> variables but it doesn't need arguments and only has a single return
> value. We may need vector and real versions. These anonymous functions are
> only needed until the $strobe finishes executing.

That's something like a vpi expression node that supports vpi_get_value
by evaluating the expression. Perhaps the code generator can write
out the vpi expression nodes and make them available to the system
task?

> To get $monitor to work correctly the anonymous function needs to get a
> bit smarter. It needs to be able to create cbValueChange call backs for
> all the variables or pieces of a variable it references when it is asked
> to provide a cbValueChange call back. The anonymous functions for $monitor
> would need to be persistent.

VPI expression nodes would be a natural for carrying callbacks. They
can even automatically propagate the calculation.

> Does this sound like a reasonable plan? Any suggestions? Would an
> anonymous and possible temporary continuous assignment be a better
> solution?

I can think of two plausible ways to handle this. One would be to
create VPI expression nodes that reflect the expression, and the
other is to create an implicit user-defined function. The latter is
what I think you are proposing and has the advantage of using the
run time of the behavioral instructions to handle things. Perhaps
the ideal would be to combine the two by generating a VPI expression
node that acts as a handle for that implicit user defined function.
In any case, a vpi handle for this implicit function, even if it
is a private type, would act as an infrastructure for carrying the
callbacks etc.

- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH6+FErPt1Sc2b3ikRAtD7AJ9xmunnQS78Wnq00xkKfm7oV/5SMwCg6NKx
aT75vr25xGOSPxfSo6U3XZU=
=Vtoy
-----END PGP SIGNATURE-----

Re: [Iverilog-devel] $monitor/$strobe and friend (pr1780480).

[Cary R. <cy...@ya...>]

--- Stephen Williams <st...@ic...> wrote:

> Look at all the various kinds of expression nodes are supported
> by the VPI:-(

And it's real nice that we can safely ignore them in Icarus :-).
 
> That's something like a vpi expression node that supports vpi_get_value
> by evaluating the expression. Perhaps the code generator can write
> out the vpi expression nodes and make them available to the system
> task?

OK I will think about this.

One complication so far is do we need to handle special the case when a
$strobe is called inside a loop that may be changing a variable the
expression depends on? Something like:

// $strobe the elements of an array.
for(idx = 0; idx < 8; idx = idx + 1) begin
  $strobe(a[idx]);
end
#1;

In this case do we assume the index variable is different for each call
(is an argument) or is it just a normal expression? I believe the correct
interpretation is that you will end up with eight strobes all displaying
the value of a[8]. Thoughts?

Cary


      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

Re: [Iverilog-devel] $monitor/$strobe and friend (pr1780480).

[Stephen W. <st...@ic...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Cary R. wrote:
> --- Stephen Williams <st...@ic...> wrote:
> 
>> Look at all the various kinds of expression nodes are supported
>> by the VPI:-(
> 
> And it's real nice that we can safely ignore them in Icarus :-).
>  
>> That's something like a vpi expression node that supports vpi_get_value
>> by evaluating the expression. Perhaps the code generator can write
>> out the vpi expression nodes and make them available to the system
>> task?
> 
> OK I will think about this.
> 
> One complication so far is do we need to handle special the case when a
> $strobe is called inside a loop that may be changing a variable the
> expression depends on? Something like:
> 
> // $strobe the elements of an array.
> for(idx = 0; idx < 8; idx = idx + 1) begin
>   $strobe(a[idx]);
> end
> #1;
> 
> In this case do we assume the index variable is different for each call
> (is an argument) or is it just a normal expression? I believe the correct
> interpretation is that you will end up with eight strobes all displaying
> the value of a[8]. Thoughts?

I think you are right. Just one of many strange consequences
of $strobe/$monitor.



- --
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFH7CHNrPt1Sc2b3ikRAiZLAKDoqyfgCXx93nSlpPLa5WN4pDZ8AgCcCT+H
EIYTXNnsoei4nH5Ujxq8OAA=
=gBti
-----END PGP SIGNATURE-----