SystemVerilog: No 'ref' for tasks or functions?

M

mrfirmware

Guest
I just want to be sure that you can't pass a task or function to
another task or function. I don't see it stated that this is allowed
but I don't want to give up without confirmation. I'd like to pass a
receive handler task into another task by ref to simulate a C-style
call-back.

Thanks,
- Mark
 
On Jan 16, 3:18 pm, mrfirmware <mrfirmw...@gmail.com> wrote:
I just want to be sure that you can't pass a task or function to
another task or function. I don't see it stated that this is allowed
but I don't want to give up without confirmation. I'd like to pass a
receive handler task into another task by ref to simulate a C-style
call-back.
No, SystemVerilog does not support passing references to tasks/
functions.

Some of the uses for this functionality may be provided by other
mechanisms though.
 
On Jan 16, 11:07 pm, sh...@cadence.com wrote:
Some of the uses for this functionality may be provided by other
mechanisms though.
Upon further thought, the full functionality can be obtained using
classes in the following way:

Declare an abstract base class with nothing in it but a virtual task
with the prototype of the task you want to be able to pass. For each
different implementation of the task that you want to be able to pass,
declare a class derived from that abstract base class and with the
desired task as the implementation of the virtual task for that
derived class. If you don't want to put the actual task inside the
class, leave it outside and have the virtual task call it for you.
Then take the argument that you wanted to be a ref to a task and
declare it instead as the abstract base class. To pass a particular
implementation to it, create an object of the derived class containing
that implementation, and pass that in.

Having to wrap the task in a class before you can pass it is a little
clumsy, but it does provide the desired functionality.
 
Although you can get the C like reference to task and functions by jumping
through hoops, is it worth it? I think you would have a very hard time
getting a synthesis tool to understand it and make something useful out of
it.
If the synthesis engine doesn't just print an Error not supported message.

That means you will only be able to use this in the testbench. There has
to be a cleaner way to achieve the final goal without passing the
function/task references.

<sharp@cadence.com> wrote in message
news:e6e92667-3049-451d-b05d-bd9e89bbc310@e23g2000prf.googlegroups.com...
On Jan 16, 11:07 pm, sh...@cadence.com wrote:
Some of the uses for this functionality may be provided by other
mechanisms though.
Upon further thought, the full functionality can be obtained using
classes in the following way:

Declare an abstract base class with nothing in it but a virtual task
with the prototype of the task you want to be able to pass. For each
different implementation of the task that you want to be able to pass,
declare a class derived from that abstract base class and with the
desired task as the implementation of the virtual task for that
derived class. If you don't want to put the actual task inside the
class, leave it outside and have the virtual task call it for you.
Then take the argument that you wanted to be a ref to a task and
declare it instead as the abstract base class. To pass a particular
implementation to it, create an object of the derived class containing
that implementation, and pass that in.

Having to wrap the task in a class before you can pass it is a little
clumsy, but it does provide the desired functionality.
 
"Dwayne Dilbeck" <ddilbeck@yahoo.com> wrote in message
news:13ovbf7i20e3ed1@corp.supernews.com...
Although you can get the C like reference to task and functions by jumping
through hoops, is it worth it? I think you would have a very hard time
getting a synthesis tool to understand it and make something useful out of
it.
If the synthesis engine doesn't just print an Error not supported message.

That means you will only be able to use this in the testbench. There has
to be a cleaner way to achieve the final goal without passing the
function/task references.
The "virtual base-class + inherited child-class" technique is a
verification (testbench) technique. It's not intended to be synthesizeable
at all! And yes...it is an awfully convoluted way to implement a
simple "function-pointer" (in the sense of ANSI C/C++)
 
On Jan 18, 2:16 am, "aka" <a...@nospam.net> wrote:
"Dwayne Dilbeck" <ddilb...@yahoo.com> wrote in message

news:13ovbf7i20e3ed1@corp.supernews.com...

Although you can get the C like reference to task and functions by jumping
through hoops, is it worth it? I think you would have a very hard time
getting a synthesis tool to understand it and make something useful out of
it.
If the synthesis engine doesn't just print an Error not supported message.

That means you will only be able to use this in the testbench. There has
to be a cleaner way to achieve the final goal without passing the
function/task references.

The "virtual base-class + inherited child-class" technique is a
verification (testbench) technique. It's not intended to be synthesizeable
at all! And yes...it is an awfully convoluted way to implement a
simple "function-pointer" (in the sense of ANSI C/C++)
Yes, but it does seem to answer my needs. I was thinking virtual
functions was the way to go (yes, this is purely for my testbench) but
I was just making sure I hadn't missed some obscure corner of the SV
LRM. Thanks to all.

- Mark
 

Welcome to EDABoard.com

Sponsor

Back
Top