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

That should have been

Note that an array can be created anonymously using an assignment
pattern.

same c1 {'{a,b,c,d, e||f});

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

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