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

Why can't a dynamically sized array serve the same pupose. Not that an
array can be created on the fly using an assignment pattern.

Dave

> -----Original Message-----
> From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
> Korchemny, Dmitry
> Sent: Sunday, June 06, 2010 1:53 AM
> To: Daniel Schostak; sv-bc@eda.org
> Cc: sv-ac@eda.org
> Subject: [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.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.