Yes, I was thinking of 1800-2005 which defines the sampled-value functions. These can only be extended which was the direction I took in the earlier email. But it makes it a bit messy as Dmitry pointed out. ed > -----Original Message----- > From: Rich, Dave [mailto:Dave_Rich@mentor.com] > Sent: Monday, April 30, 2007 1:43 PM > To: Eduard Cerny; Korchemny, Dmitry; sv-ac@eda-stds.org > Subject: RE: [sv-ac] call to vote on Mantis 1674 > > > Yes, that is a challenge, but will be hopefully worth it given the > anticipated longevity of SystemVerilog. > > Remember, you only need to be backwards compatible with 1800-2005, you > still have time to modify anything that has passed through > the committee > since then. > > Dave > > > -----Original Message----- > > From: Eduard Cerny [mailto:Eduard.Cerny@synopsys.com] > > Sent: Monday, April 30, 2007 10:08 AM > > To: Rich, Dave; Eduard Cerny; Korchemny, Dmitry; sv-ac@eda-stds.org > > Subject: RE: [sv-ac] call to vote on Mantis 1674 > > > > Hi Rich, > > > > if we can redefine it then fine, but the problem is backward > > compatibility as well... > > ed > > > > > -----Original Message----- > > > From: Rich, Dave [mailto:Dave_Rich@mentor.com] > > > Sent: Monday, April 30, 2007 1:06 PM > > > To: Eduard Cerny; Korchemny, Dmitry; sv-ac@eda-stds.org > > > Subject: 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.Received on Mon Apr 30 11:08:50 2007
This archive was generated by hypermail 2.1.8 : Mon Apr 30 2007 - 11:09:02 PDT