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

The problem is that the elements have to have the same type, and, they cannot be SVA properties or sequences.
ed

> -----Original Message-----
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of
> Rich, Dave
> Sent: Sunday, June 06, 2010 1:20 PM
> To: sv-bc@eda.org
> Cc: sv-ac@eda.org
> Subject: 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.
>

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