RE: Notes from my discussion with Johny Srouji (Accellera Technic al C hair)

 
Hi,
 
The goal is definitely to move to SystemVerilog-AMS. As i have explained in the committee calls that goal hasnt changed.
 
There are two ways of getting there. The interim version of merging with P1364-2005 (LRM2.3) does in no way change the goal of merging with SystemVerilog-AMS. Infact in my opinion given that P1800 is a superset of 1364, this interim revision should facilitate this. Also, this keeps the language development moving forward and keeping it current in more reasonable frame of time. Also the community is moving forward with 1364-2001 (and probably soon 2005) with analog and it makes sense to do this.
 
As part of LRM2.3, some of the conflicts with SystemVerilog that exists in the AMS language today are being addressed as high priority items. The work done with this revision should make it easier to move towards SV. [Johny's assumption and expectation that he has mentioned is correct].
 
Regards,
Sri
 
 

-----Original Message-----
From: Johny Srouji [mailto:srouji@us.ibm.com] 
Sent: Wednesday, 31 August 2005 11:42 PM
To: Chandrasekaran Srikanth-A12788; 'Kevin Cameron'
Cc: Verilog-A Reflector
Subject: RE: Notes from my discussion with Johny Srouji (Accellera Technic al C hair)



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. 

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. 







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