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

From: ben cohen <hdlcohen@gmail.com>
Date: Mon Jun 07 2010 - 23:52:58 PDT

The example with the dynamic array (with the sequence seq[];) needs to allow
for the definition of
a dynamic array of sequences. I don't believe the a fixed array is also
legal.
The example needs the generate construct, I believe. Also, it is illegal to
use a non-constant generate loop condition.
Maybe I am missing something here. Sorry!
Ben

module never_seq();
//
logic seq[];
event clk;
 default clocking @clk; endclocking
// default disable iff rst;
 int n = seq.size; //!!!
 // if (n == 0) $error;
 generate
 for (genvar i = 0; i < n; i++) begin : b // Illegal non-constant generate
loop condition.
 // for (genvar i = 0; i < 3; i++) begin : b
   if (i == 0)
       sequence s;
       seq[0];
     endsequence
   else
     sequence s;
       b[i-1].s ##1 seq[i];
     endsequence
 end
 endgenerate
 a1: assert property (not strong(seq[n-1]));
endmodule

** Error: test.sv(21): (vlog-2110) Illegal reference to dynamic array "seq".
** Error: test.sv(21): (vlog-2110) Illegal reference to dynamic array "seq".
** Error: test.sv(10): Illegal non-constant generate loop condition.
** Error: test.sv(13): (vlog-2110) Illegal reference to dynamic array "seq".
** Error: test.sv(13): (vlog-2110) Illegal reference to dynamic array "seq".
** Error: test.sv(17): (vlog-2110) Illegal reference to dynamic array "seq".
** Error: test.sv(17): (vlog-2110) Illegal reference to dynamic array "seq".
%

// Original model taht I was trying to test using a module.
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
On Sun, Jun 6, 2010 at 10:42 AM, Eduard Cerny <Eduard.Cerny@synopsys.com>wrote:

> 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.
>
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Jun 7 23:53:49 2010

This archive was generated by hypermail 2.1.8 : Mon Jun 07 2010 - 23:53:56 PDT