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

Hi Dmitry,

Clearly, parameterized sequences/properties cannot replace checkers with a variable number of arguments. Those are just simple and intuitive derived operators. As for the need in practice - I believe that for and/or sequence/property operators the use is very common. I don't have any numbers to support this statement, though ;-)

Best,
Dana

-----Original Message-----
From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
Sent: Tuesday, June 08, 2010 10:38 AM
To: Dana Fisman; Rich, Dave; Eduard Cerny; sv-bc@eda.org
Cc: sv-ac@eda.org
Subject: RE: [sv-ac] RE: [sv-bc] RE: Need for 1566 (variable number of arguments)

Hi Dana,

Having parameterization or reduction, as you suggest, will address basic cases only, but for sophisticated cases a predefined number of reductions is never sufficient. Note also that in any case the language has to support passing a variable number of arguments to different constructs to apply the parameterization, and this capability is currently missing.

I agree that the parameterization is convenient where it is applicable, instead of ugly implementation using generate constructs. The question is how common such pure cases are in practice to justify introduction of new operators in addition to the new constructs that have to be introduced in any case to support this concept. I think that it must be easy and natural to use checkers with a variable number of arguments, but this requirement is not gating for the implementation of these checkers, since their implementers are usually few and qualified.

Thanks,
Dmitry

-----Original Message-----
From: Dana Fisman [mailto:Dana.Fisman@synopsys.com]
Sent: Tuesday, June 08, 2010 8:55 AM
To: Dana Fisman; Korchemny, Dmitry; Rich, Dave; Eduard Cerny; sv-bc@eda.org
Cc: sv-ac@eda.org
Subject: RE: [sv-ac] RE: [sv-bc] RE: Need for 1566 (variable number of arguments)

I meant

" ... If the parameterization is done by means of an array (rather than a set), I believe this makes sense for every binary ***associative*** operator such that both operands and the result are of the same type."

Dana

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Dana Fisman
Sent: Tuesday, June 08, 2010 8:52 AM
To: Korchemny, Dmitry; Rich, Dave; Eduard Cerny; sv-bc@eda.org
Cc: sv-ac@eda.org
Subject: RE: [sv-ac] RE: [sv-bc] RE: Need for 1566 (variable number of arguments)

Hi Dmitry,

Another approach to go, considering the below example, is to define parameterized sequence/property operators - similar to \bigsum in math and \bigand in logic.

For example,
        intersect (seq[])
can be defined as
      seq[0] intersect seq[1] intersect ... seq[n]
where n is the size of seq[].

Similarly
        ##1 (seq[])
can be defined as
      seq[0] ##1 seq[1] ##1 ... seq[n]
where n is the size of seq[].

Then the below assertion can simply be written as:
a1: assert property (not strong(##1 (seq[])));

Then we have to discuss which sequence/property operators can be parameterized. If the parameterization is done by means of an array (rather than a set), I believe this makes sense for every binary commutative operator such that both operands and the result are of the same type. For instance, the sequence operators and, or, intersect ##[N:M] adhere these.

In PSL, by the way, parameterized operators exists for the and/or property and sequence operators. There, the parameters are regarded as a set - thus the restriction to commutative operators.

Best regards,
Dana

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Monday, June 07, 2010 9:05 AM
To: Rich, Dave; Eduard Cerny; sv-bc@eda.org
Cc: sv-ac@eda.org
Subject: RE: [sv-ac] RE: [sv-bc] RE: Need for 1566 (variable number of arguments)

Hi Dave,

I think that conceptually what you are proposing is what we need. I cannot see a need in variable data types for the usage I am talking about. However, the concept of dynamic arrays in our context should be elaborated.

Consider the following example. We want to write a checker that accepts an array of sequences seq[] and checks that their concatenation seq[0] ##1 seq[1] ##1 ... ##1 seq[n-1] never happens. Here is how it will look using a dynamic array of sequences:

checker never_seq(sequence seq[], event clk = $inferred_clock, logic rst = $inferred_disable);
  default clocking @clk; endclocking
  default disable iff rst;
  genvar n = seq.size; //!!!
  if (n == 0) $error;
  for (genvar i = 0; i < n; i++) begin : b
    if (i == 0)
        sequence s;
        seq[0];
      endsequence
    else
      sequence s;
        b[i-1].s ##1 seq[i];
      endsequence
  end
  a1: assert property (not strong(seq[n-1]));
endchecker

Note that we have to consider the size of a dynamic array as an elaboration *constant expression*. Without being able to do that I don't know our problem can be solved.

Thanks,
Dmitry

-----Original Message-----
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Rich, Dave
Sent: Monday, June 07, 2010 5:03 AM
To: Eduard Cerny; sv-bc@eda.org
Cc: sv-ac@eda.org
Subject: RE: [sv-ac] RE: [sv-bc] RE: Need for 1566 (variable number of arguments)

Arrays of sequences and properties could be easily added to the language
(easier that variable number of args, at least)

The examples shown so far might benefit from parameterizable functions,
but do not need variable number of args.

The big problem with variable number of args is not so much the variable
'number', but the 'variable data types' of each arg.

Dave

> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> Sent: Sunday, June 06, 2010 10:42 AM
> To: Rich, Dave; sv-bc@eda.org
> Cc: sv-ac@eda.org
> Subject: 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.
---------------------------------------------------------------------
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.
---------------------------------------------------------------------
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.