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