[sv-bc] RE: Need for 1566 (variable number of arguments)

Hi all,

I think that the primary need in a variable number of arguments comes from let/sequences/properties/checkers. Here are some examples that can be a natural part of a checker library:

Several signals have the same value. We want to have a checker called same, and be able to pass it any numbers of arguments:

same c1(a, b);
same c2(a, b, c);
same c3(a, b, c, d);

Without this capability the library should contain many checkers doing this job:

same2 c1(a, b);
same3 c2(a, b, c);
same4 c3(a, b, c, d);

Think that when there are many signals that should have the same value, the user will have to count their exact number. If a signal needs to be added or removed from the check, the checker name has to be changed.

Another example checking the temporal relationship: events should be received in a given order. Again, having one checker event_order, this can be written as:

event_order c1(en, ev1, ev2);
event_order c2(en, ev1, ev2, ev3);
event_order c3(en, ev1, ev2, ev3, ev4);
...

Today you have to create many checkers like this:

event_order2 c1(en, ev1, ev2);
event_order3 c2(en, ev1, ev2, ev3);
event_order4 c3(en, ev1, ev2, ev3, ev4);
...

The number of examples may be easily multiplied.

This feature is important to improve usability of checker libraries, including the standard ones. Implementing it is most important in checkers, but it makes sense to allow this feature for all similar language constructs for uniformity. For this feature to be usable, it should also be supported in macros, as checker invocations are often wrapped in macros.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Daniel Schostak
Sent: Friday, June 04, 2010 12:30 AM
To: sv-bc@eda.org
Subject: [sv-bc] RE: Need for 1566 (variable number of arguments)

Two possible use cases that have occurred to me are:

  1) Wrapping $display (or other system tasks that take variable numbers of arguments). However, I think for this to be useful, a $vdisplay system task would be required in the same way that C has a vprintf function to take a list of arguments.
  2) Creating utility functions that can operate on a variable number of arguments (for example, calculating the maximum of an arbitrary number of variables).

(1) can be usually worked around by using $psprintf / $sformatf to pass a pre-formatted string, but this restricts what can be done easily in the wrapping function (and also means that there is the overhead of formatting the string even if the wrapping function will discard it for some reason).

(2) could be worked around by using an untyped mailbox (as mentioned in the meeting) or a list (if all the arguments can be of the same type). However, if the data to be passed to the function is not already stored in a mailbox or a list, then there would be some overhead in creating the container and then discarding it once the function call is complete. It seems plausible to me that an implementation of variable arguments could pass data more efficiently to a function that operates on an arbitrary number of variables.

I do not think either use case indicates that adding variable arguments would allow you to do something you cannot already do some other way in SystemVerilog. However, I think adding variable arguments might well allow you to write more concise and generic code. (I think that this is more so for (2) than (1), because I think it is likely that without variable arguments (2) would be solved with a less direct workaround than was suggested above for efficiency reasons.)

From, Daniel.

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Little Scott-B11206
Sent: 03 June 2010 13:24
To: sv-bc@eda.org
Subject: [sv-bc] Need for 1566 (variable number of arguments)

Hi all:

Mantis item 1566 was created because of a question asked by Mike Burns,
but the question is not directly related to variable numbers of
arguments. There is minimal interest in variable numbers of arguments
within Freescale, so I don't have any additional information or
clarification in regard to the requirements for this Mantis item

Thanks,
Scott

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.