Johny Srouji wrote: > > ----- Forwarded by Johny Srouji/Austin/IBM on 08/31/2005 09:24 AM ----- > > Sri, Kevin, Hi, > > I want to make sure we are all clear on this - here is my take: > > There is NO contradiction between Verilog-2005 and SystemVerilog - > they are actually both under the same WG now (P1800). Long term, both > LRM's will converge into a single one. That was discussed and agreed > upon in the P1800 WG, but it was understood that for the short term we > need to refine the latest Verilog version and get SystemVerilog LRM > out and approved as an IEEE standard. We also kept in mind and as part > of our goals, that we will not create "conflicts" between the two > languages. > > Under the same spirit, I also think that Verilog-AMS is a step in the > right direction and goal which is SystemVerilog-AMS. Therefore, I > would assume and expect (Sri - please confirm) that any work that is > done for Verilog-AMS would not make it harder to develop > SystemVerilog-AMS but the contrary. I want the committee to keep > SystemVerilog-AMS in mind - this is the goal. I'm not very convinced that SV committees will consider AMS issues during future enhancements or that the Accellera committee will track SV enhancement proposals either unless there is a single committee structure under P1800. I say that having raised a few issues that are important to AMS at SV committees and generally saw them get ignored. What would be the problem with rolling the Verilog-AMS/Verilog-2005 merge into the P1800 Verilog-2005 WG? > Also, given the install base and usage of Verilog vs. SystemVerilog, I > think it makes sense to start w/ the Verilog version and then migrate > to SystemVerilog. I expect two things to happen here: 1) the > Verilog-AMS work will not take too long (I will follow-up w/ Sri on > the schedule) and 2) SystemVerilog-AMS is kept in mind when making > design decisions. I see no conflict from the vendors perspective > either - they will have to support both of these implementations anyway. > > As for P1800 (which I also chair), I will make sure that > SystemVerilog-AMS is on our next WG F2F meeting agenda (mid October), > after which I will work w/ Sri on a detailed plan and schedule for > this work. As for the structure, I would still like this work to be > done under the AMS committee (versus merging it into P1800 or Verilog > P1364) but will probably assign a liaison person between the two > groups to make sure we're aligned. > > Hope this clarifies this important topic. Thanks, > > --- Johny. My only complaint is that the AMS committee has been running for ~ 10 years now and the work should have moved into the IEEE Verilog Standard ~ 5 years ago. Continually deferring integration will make the integration harder since both languages are continually being "enhanced". Unnecessary conflicts have appeared in areas like generate statements, reals on ports and keyword usage because of the delay. At the rate things are going it looks like it will be another decade before there is a single integrated language, and it is very difficult to move forward with new extensions into other areas (e.g. RF) without that base in place. Kev. > *Chandrasekaran Srikanth-A12788 <Srikanth.Chandrasekaran@freescale.com>* > > 08/30/2005 06:44 PM > > > To > "'Kevin Cameron'" <kevin@sonicsinc.com> > cc > Verilog-A Reflector <verilog-ams@eda.org>, Johny Srouji/Austin/IBM@IBMUS > Subject > RE: Notes from my discussion with Johny Srouji (Accellera Technic > al C hair) > > > > > Kevin, > > This was discussed in detail in the AMS committee call this morning. > > Couple of things seem to be very clear from the participants and > vendors point of view. > > 1. Vendors (cadence, mentor) who were in the call today seem to agree > that it makes lot of sense to move towards 1364-2005. Infact most > vendors are already doing this or planning to migrate to the latest > 1364 digital standard (based on user needs and also the roadmaps from > vendors), so it makes lot of sense for Accellera AMS standard to be > consistent with what the user community and the vendor and tool > implementors are providing to users. Also there was agreement that > this direction is consistent with the overall goal of merging with > P1800 revision. So part of this interim version any critical SV > conflicts will be resolved. So I don't necessarily agree that there is > not going to be buyin for the interim AMS LRM2.3 version. Infact to > the contrary this provides the vendors a very good migration path to > systemverilog. > > 2. Also, its reasonably well acknowledged that going to SV directly is > reasonably difficult in terms of time and effort. Its going to take a > fair amount of time, and not having interim version to address the > needs of the user community and having critical analog issues resolved > is very important. So approaching that problem through interim 1364 > versions is very doable, manageable and it can be done in an finite > amount of time. > > 3. Also working on 1364 doesn't not preclude in any sense on the > SystemVerilog integration work. Infact in some sense it needs to > happen parallely than sequentially, with reasonably aggressive > roadmaps and plans that we have. This also needs a reasonable > commitment from P1800 with AMS which I guess would happen once the > P1800 standard is approved and published. > > Regards, > Sri > > > -----Original Message----- > From: Kevin Cameron [mailto:kevin@sonicsinc.com] > Sent: Wednesday, 31 August 2005 3:05 AM > To: Chandrasekaran Srikanth-A12788 > Cc: Verilog-A Reflector; srouji@us.ibm.com > Subject: Re: Notes from my discussion with Johny Srouji (Accellera > Technical C hair) > > > Chandrasekaran Srikanth-A12788 wrote: > > >0. Gave outline, membership, current status of AMS committee and the > >LRM version. > > > >1. Interim versions for VerilogAMS: It will be good to have interim > >VerilogAMS LRM release which synchronizes with 1364-2005 standard > before moving to SystemVerilog. SV is still a very high priority and > the right direction to move, but given the nature of the task it might > be good to first move to 1364-2005 which is a natural step towards > p1800. There was a workshop in April set out for discussing plan and > also requirements from different members/companies to be involved > with, for SV merge and cadence is working on a initial draft proposal > - initial plan was to release SV integration early Feb 2006. > >This is a very difficult task to jump directly to SV from current > version of AMS standard. It was agreed to release interim version with > 1364-2005 at the same time addressing some of the critical SV > incompatibility issues. > > > > > While I can see the logic in merging with 1364-2005, I'm not convinced > that EDA vendors are going to be very motivated to work on a Verilog-AMS > that only has 1364-2005 compatibility when most folks now seem to be > working on SV. Man-power is somewhat limited, the same people are going > to be working on the committees at Accellera and IEEE (as far as I can > tell). > > I think 1364-2005 synchronization is only going to delay integration > with SV, and the committees should make a concerted effort to integrate > AMS with SV in the next round of SV enhancement. > > Both AMS and SV have outstanding issues in the area of back annotation, > and how the SV/AMS type schemes can be extended to handle more signal > types. IMO it is extremely important that these issues are addressed > together, sooner rather than later. > > >(Action: Sri) Need to come up with plans/roadmap and release time > >frames to be sent to Accellera. There might be a board meeting in > >september and status of AMS also needs to be sent out. > > > >2. (Action: Sri) Need to send through documentation/details of the > >VerilogAMS - latest status report, website links, reflector pages etc > > > >3. Release of p1800 - This is planned to happen late Q3 (probably > >september). Reviews have been completed and its very close to be > approved and released. P1800 is a merge of SV and 1364-2005 standards > and hence is a superset of the verilog digital standard. The focus of > p1800 will be to ensure the smooth transition of verilog users to > p1800 system verilog standard. > > > >4. IEEE version with AMS: The plan for the next revision of the p1800 > >standard would be to release with AMS. This needs to be worked out, > >planned/detailed and the committee would works towards that as next > >major milestone. Timeframe? Johny mentioned that the next revision of > >p1800 may possibly be within 3 years instead of a 5yr wait to integrate > >into next revision. > > > >5. Cooperation between two committees: Once p1800 is released Johny > >will talk to members on contributing to the merger of p1800 with AMS. > He was requesting also the possibility of analog people getting > involved in SV/p1800 committee. These needs to be discussed with AMS > committee. Will be very difficult to merge p1800 with AMS unless there > is involvement within the two groups to come out with common standard. > This SV-AMS merger can be done in parallel with the AMS LRM interim > version releases. > > > > > It's still my opinion that the AMS committee at Accellera should be > split, with language development continuing as a subcommittee of the > P1800 effort and Accellera looking after standard libraries and models. > > Since the compatibility issues between AMS and 1364-2005 are probably > mostly minor I suspect that they could be mostly handled by addenda > posted on the web, I don't see the requirement for producing full-blown > LRMs - particularly since the current LRM is a free download. > > Kev. > > >Regards, > >Sri > >-- > >Srikanth Chandrasekaran > >Freescale Semiconductor, Inc., Australia > >Ph: +61-8-8168 3592 Fax: 3501 > > > > > > >Received on Wed Aug 31 10:25:13 2005
This archive was generated by hypermail 2.1.8 : Wed Aug 31 2005 - 10:25:52 PDT