RE: [sv-ac] call to vote on Mantis 1674

What I would like to see is some combination of syntax, language,
operators, or methods to define these, not system function calls.
Unfortunately, I only have a limited amount of time to spend on the
sv-ac and don't have a lot of formal expertise. I'm only looking at this
from the perspective of keeping SystemVerilog a unified HDVL while
keeping the LRM as simple as possible.

I'm only suggesting that you spend some time investigating alternative
solutions to the function calls.
Dave


> -----Original Message-----
> From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> Sent: Monday, April 30, 2007 9:45 AM
> To: Korchemny, Dmitry; Eduard Cerny; Rich, Dave; sv-ac@eda-stds.org
> Subject: RE: [sv-ac] call to vote on Mantis 1674
> 
> So how do we reconcile the two?
> ed
> 
> > -----Original Message-----
> > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> > Sent: Monday, April 30, 2007 12:42 PM
> > To: Eduard Cerny; Rich, Dave; sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] call to vote on Mantis 1674
> >
> > Essentially we can, but it will be very user-unfriendly.
> >
> > Thanks,
> > Dmitry
> >
> > -----Original Message-----
> > From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> > Sent: Monday, April 30, 2007 7:40 PM
> > To: Korchemny, Dmitry; Eduard Cerny; Rich, Dave; sv-ac@eda-stds.org
> > Subject: RE: [sv-ac] call to vote on Mantis 1674
> >
> > Could we add another argument to distinguish it?
> > ed
> >
> > > -----Original Message-----
> > > From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> > > Sent: Monday, April 30, 2007 12:14 PM
> > > To: Eduard Cerny; Rich, Dave; sv-ac@eda-stds.org
> > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > >
> > > Hi Ed, Dave,
> > >
> > > But how we define $rising_i, $changing_i, etc. in this case?
> > >
> > > Thanks,
> > > Dmitry
> > >
> > > -----Original Message-----
> > > From: owner-sv-ac@server.eda.org
> > > [mailto:owner-sv-ac@server.eda.org] On
> > > Behalf Of Eduard Cerny
> > > Sent: Monday, April 30, 2007 3:22 PM
> > > To: Rich, Dave; Eduard Cerny; sv-ac@server.eda-stds.org
> > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > >
> > > Hello Rich,
> > >
> > > good point even if the solution is not obvious. Still,
> > > perhaps something
> > > could be done w/o breaking backward compatibility in the
> > case of 1682:
> > >
> > > For example, $past is currently defined as:
> > >
> > > $past( expression1 [, number_of_ticks] [, expression2] [,
> > > clocking_event])
> > >
> > > If we allow number_of_ticks to take values in [-1:$] then -1 could
> > > indicate next clock tick, i.e., future value (negative past
> > > == future).
> > > To indicate that global clock should be used, use the name of
> > > the global
> > > clocking declaration for the clocking event. The problem
> > with this is
> > > that in the case the future value should be used, the
specification
> > > becomes a bit long because both the ticks and the clock must be
> > > specified. On the other hand, compared to the regular use of
> > > $past there
> > > will be relatively few such uses and in more specialized
> > situations.
> > >
> > > Dmitry, would something like this be acceptable?
> > >
> > > ed
> > >
> > >
> > > > -----Original Message-----
> > > > From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> > > > Sent: Sunday, April 29, 2007 10:42 AM
> > > > To: Eduard Cerny; sv-ac@eda-stds.org
> > > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > > >
> > > > If you look at the VPI object model, there's a regular
> > way of moving
> > > > from one object to any other object through a limited set of
> > > > operations.
> > > > Then from any object, there's a regular way of querying or
setting
> > > > information about that object. With the PLI, there were
> > > separate tasks
> > > > to do individual operations. For example, there was one
> > > > function to get
> > > > the value of a signal, another to get the value of a task
> > > > argument, and
> > > > another to get the value of a parameter.
> > > >
> > > > I'm not suggesting that the solution has to be
> > > introspection, but that
> > > > you take a global look at all the features that need to be
> > > > added and see
> > > > if there are better language based solutions. It looks
> > like you are
> > > > trying to get access to inferred signals from within a
> > property and
> > > > inferred signals from the context where a property has been
> > > > instantiated. Then I see the three different kinds of
> > > signals that are
> > > > being inferenced. What if you decide you need to know the global
> > > > defaults as well? Then you have to add three more system
> > functions.
> > > >
> > > > Mantis 1682 is probably a poster example of the problem I
> > > see. A year
> > > > from now, who outside the sv-ac is going to remember the
> > difference
> > > > between $rose, $rose_i, $rising_i (I don't remember if
> > $posedge was
> > > > added elsewhere). Come up with a single definition of
> > > > rising/falling/changing, then come up with definitions for
> > > > past, current
> > > > and future, then try to come up with syntax that blends the
> > > > two concepts
> > > > together without creating unique identifiers with each
> > combination.
> > > >
> > > > Dave
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com]
> > > > > Sent: Friday, April 27, 2007 1:39 PM
> > > > > To: Rich, Dave; sv-ac@eda-stds.org
> > > > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > > > >
> > > > > Hi Dave,
> > > > >
> > > > > is it not, though, that the user must have means of
> > > specifying where
> > > > the
> > > > > inference should be made and where not? How would
> > > introspection help
> > > > > that?
> > > > >
> > > > > Thanks,
> > > > > ed
> > > > >
> > > > >
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On
> > > > > > Behalf Of Rich, Dave
> > > > > > Sent: Friday, April 27, 2007 4:30 PM
> > > > > > To: sv-ac@eda-stds.org
> > > > > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > > > > >
> > > > > > Ed,
> > > > > >
> > > > > > My problem with this proposal is that it needs a more
general
> > > > language
> > > > > > based way to solving the problem. Synthesis tools will
> > > > certainly be
> > > > > > interesting in utilizing inferred clocks, resets and
enables.
> > > > > >
> > > > > > The sv-ac has been adding what looks like system functions
> > > > > > all over the
> > > > > > place in a relatively ad-hoc manner, and the list is getting
> > > > > > relatively
> > > > > > large. This same thing that happened to the PLI 1.0 as
> > > > the number of
> > > > > > routines grew. They replaced it with a more OO-like VPI when
> > > > > > it started
> > > > > > to become unmanageable.
> > > > > >
> > > > > > My suggestion is to start looking at other languages with
> > > > > > introspection
> > > > > > (Python) and coming up with more regular ways querying
context
> > > > > > information.
> > > > > >
> > > > > > Dave
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: owner-sv-ac@server.eda.org
> > > > [mailto:owner-sv-ac@server.eda.org]
> > > > > > On
> > > > > > > Behalf Of Eduard Cerny
> > > > > > > Sent: Friday, April 27, 2007 10:44 AM
> > > > > > > To: Kulshrestha, Manisha; john.havlicek@freescale.com;
> > > > > > sv-ac@server.eda-
> > > > > > > stds.org
> > > > > > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > > > > > >
> > > > > > > I think that there is a real need to be able t specify
such
> > > > default
> > > > > > > arguments, otherwsie properties are not reusable in
> > different
> > > > > > contexts.
> > > > > > > Therefore, would you have a counterproposal? Or what
> > > you feel is
> > > > not
> > > > > > > intuitive?
> > > > > > >
> > > > > > > Regards,
> > > > > > > ed
> > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org]
On
> > > > > > > > Behalf Of Kulshrestha, Manisha
> > > > > > > > Sent: Friday, April 27, 2007 1:36 PM
> > > > > > > > To: john.havlicek@freescale.com; sv-ac@eda-stds.org
> > > > > > > > Subject: RE: [sv-ac] call to vote on Mantis 1674
> > > > > > > >
> > > > > > > > I vote no on 1674. I am not convinced that the
> > > current way to
> > > > > > replace
> > > > > > > > default arguments with $inferred.. is the right way to
do
> > > > > > this. This
> > > > > > > > makes it unnecessarily complicated and it is not very
> > > > intuitive.
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > > Manisha
> > > > > > > >
> > > > > > > > -----Original Message-----
> > > > > > > > From: owner-sv-ac@server.eda.org
> > > > > > > > [mailto:owner-sv-ac@server.eda.org] On
> > > > > > > > Behalf Of John Havlicek
> > > > > > > > Sent: Wednesday, April 18, 2007 4:20 AM
> > > > > > > > To: sv-ac@server.eda-stds.org
> > > > > > > > Subject: [sv-ac] call to vote on Mantis 1674
> > > > > > > >
> > > > > > > > All:
> > > > > > > >
> > > > > > > > This is the call to vote on the proposal for Mantis
1674.
> > > > > > > >
> > > > > > > > As discussed in our meeting, this vote runs longer than
> > > > > > > > the usual week because we have so many e-mail ballots
> > > > > > > > running concurrently.
> > > > > > > >
> > > > > > > > Please vote if you are eligible.  See the details below.
> > > > > > > >
> > > > > > > > J.H.
> > > > > > > >
> > > > > > > > Ballot on Mantis 1674
> > > > > > > >
> > > > > > > > - Called on 2007-04-18, final ballots due by 23:59 PDT
on
> > > > > > 2007-04-30.
> > > > > > > >
> > > > > > > >  v[xxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Freescale)
> > > > > > > >  v[xxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsys)
> > > > > > > >  n[---------x-x-xxx-x---x] Surrendra Dudani (Synopsys)
> > > > > > > >  v[x-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale)
> > > > > > > >  t[xxxxxxxxxxxxxxxxxxxxxx] John Havlicek
> > (Freescale - Chair)
> > > > > > > >  v[xxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Intel
> > > - Co-Chair)
> > > > > > > >  v[xxxxx----------xx-xxxx] Manisha Kulshrestha
> > > > (Mentor Graphics)
> > > > > > > >  n[---xxxxx-------x-xx-x-] Jiang Long (Mentor Graphics)
> > > > > > > >  n[x.....................] Joseph Lu (Altera)
> > > > > > > >  n[x--x-xx--xx-xxxxxxx-x-] Hillel Miller (Freescale)
> > > > > > > >  v[xxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence)
> > > > > > > >  v[xx-x..................] Erik Seligman (Intel)
> > > > > > > >  n[-----xxxx-xx----------] Tej Singh (Mentor Graphics)
> > > > > > > >  v[xxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara (Synopsys)
> > > > > > > >  v[xxxxxxx...............] Tom Thatcher (Sun
Microsystems)
> > > > > > > >    |---------------------- attendance on 2007-04-17
> > > > > > > >  |------------------------ voting eligibility for
> > > this ballot
> > > > > > > > |------------------------- email ballots received
> > > > > > > >
> > > > > > > >
> > > > > > > > 	Legend:
> > > > > > > > 		x = attended
> > > > > > > > 		- = missed
> > > > > > > > 		r = represented
> > > > > > > > 		. = not yet a member
> > > > > > > > 		v = valid voter (2 out of last 3)
> > > > > > > > 		n = not valid voter
> > > > > > > >                 t = chair eligible to vote only to
> > > > make or break
> > > > a
> > > > > > tie
> > > > > > > >
> > > > > > > > --
> > > > > > > > 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.
> > >
> >

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