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

----- Forwarded by Johny Srouji/Austin/IBM on 08/31/2005 09:24 AM -----

Johny Srouji/Austin/IBM
08/31/2005 09:12 AM

To
Chandrasekaran Srikanth-A12788 <Srikanth.Chandrasekaran@freescale.com>, 
"'Kevin Cameron'" <kevin@sonicsinc.com>
cc
Verilog-A Reflector <verilog-ams@eda.org>
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
>
> 
>