RE: proposal to resolve AMS - SystemVerilog logic conflict

Hi all,
 
The two proposals have been recorded on the mantis database. I understand and agree that the reflector is good medium to discuss the proposals  - the good points, the loopholes and what is missing in the proposals that are being submitted,  including any current language issues and get an understanding from different members as to how they are resolving the problem.
 
I would suggest once a proposal has been submitted and key points made on the proposal about the good and not-so-good aspects of the proposal we move the discussion on to the committee meetings. We have regular committee meetings (once in every 2 weeks). If any member feels that there are pressing issues that needs to be discussed earlier they can always propose an intermediate call to discuss some key items that have come up during the week that needs to be critically addressed.
 
We can take the discussion points into the committee meeting and hopefully make a decision with the input of the other committee members either mutually or through a voting system. 
 
Also when a particular ticket is being assigned (I am not saying assignment of tickets to persons/member companies has been happening rigidly, but with mantis database we can make some good strides on this) to a particular member in the committee it will be good to go ahead and analyse the proposal and discuss that. If a member company or member(s) of the committee feel that they might have alternative proposals which might resolve the problem differently then it might be good to request a alternative proposal that need to be discussed and i dont see any reasons why we cannot take that up.
 
This committee is a forum for discussing issues in a open manner, but keeping in mind that we want to resolve issues and take the language forward in the interest of all. 
 
Regards,
Sri 

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Kevin Cameron
Sent: Friday, 19 August 2005 7:46 AM
To: Martin O'Leary
Cc: Steven Sharp; verilog-ams@eda.org
Subject: Re: proposal to resolve AMS - SystemVerilog logic conflict


Martin O'Leary wrote: 

Kevin,
I started this thread looking for feedback on my proposal in the hope I would get constructive feedback on it - instead it was there was a counter proposal (which was already rejected by a standard that we meant to merge and be compatable with) and now you bemoaning the fact that you are not getting constructive/technical feedback on your proposal! (which is a point that I don't accept).

Since only a few people from the AMS committee attended the SystemVerilog committees and new people have joined since the original discussion there, I feel it's fair enough to repost the my original proposal. I reposted it because your proposal required legacy code to be modified (i.e. logic needs to be renamed in the AMS code), and my proposal doesn't  require that. I feel that is more positive than just saying I didn't like your proposal.

I'm bemoaning the fact that Cadence generally (from my AMS experience, since they didn't get involved with SV until rather late) don't offer reasonable technical criticism of proposals that they just don't want to implement (usually because they have already implemented something dysfunctional that they don't want to change).


The logic conflict is IMHO a relatively small issue when trying to merge SV and AMS and based on this thread I am very concerned about moving forward with this merger unless we establish a clear and practical approach for getting this done.
Part of such an approach would be 1) the degree to which SV precedences should be accepted 2) what type of issues should be passed to the SV committee instead of being kept with the AMS committee 3) a procedure for submitting, reviewing and approving/rejecting proposals.

If you take the SV precedence of how Vera was integrated, all you do is get the AMS-LRM pasted it into the SV-LRM as a new chapter and then see how much clean-up you can do before the next DAC. 

There are not enough people involved in AMS to run an SV sub committee and the existing committee and make much progress. As I said before I think the Accellara committee should change focus to developing standard libraries/models and the language development should move to the IEEE.

Kev.



 
Thanks,
--Martin

  _____  

From: Kevin Cameron [mailto:kevin@sonicsinc.com <mailto:kevin@sonicsinc.com> ] 
Sent: Thursday, August 18, 2005 9:28 AM
To: Martin O'Leary
Cc: Steven Sharp; verilog-ams@eda.org <mailto:verilog-ams@eda.org> 
Subject: Re: proposal to resolve AMS - SystemVerilog logic conflict


Martin O'Leary wrote: 

 
> This is a different committee and we're considering proposals for the same problem (most
> of the folks doing AMS have not been involved in SystemVerilog development), so I'm
> reiterating my proposal - feel free to reiterate yours.

Kevin,
the goal is the merge AMS and SV so we need to take System Verilog precedences into account and IMHO as much as possible comply with them - otherwise we are only adding more conflicts and issues that will impact meeting our goal.
 
Thanks,
--Martin

As I said before the proposal is a general solution to the type/keyword clash problem that is 100% backward compatible with SV code, and facilitates reuse of any code with type-name clashes in design flows using old methodologies.

If anyone at Cadence has a technical objection to the propsal (i.e. some reason that it won't work) that might be a useful discussion. Claiming precedence is specious, I proposed other things at the SV committees that were initially rejected and then reappeared later.

Generally I throw out proposals as a starting point, if people have technical problems with them I will attempt to fix the problems and improve the proposals. Whether or not the final proposal is adopted should be a democratic decision by the committee.

Kev.


 


  _____  

From: Kevin Cameron [mailto:kevin@sonicsinc.com <mailto:kevin@sonicsinc.com> ] 
Sent: Wednesday, August 17, 2005 11:46 PM
To: Steven Sharp
Cc: Martin O'Leary; verilog-ams@eda.org <mailto:verilog-ams@eda.org> 
Subject: Re: proposal to resolve AMS - SystemVerilog logic conflict


Steven Sharp wrote: 

From: Kevin Cameron  <mailto:kevin@sonicsinc.com> <kevin@sonicsinc.com>

    

As Martin has already noted, the built-in types in SV are keywords rather

than predefined typedefs.  This means that an "untypedef" would not help

in avoiding name conflicts with them.  There was resistance within the SV

committees to the suggestion of using a less common name for the built-in

types, with typedefs to get backward compatibility with code using the

older names.  So I wouldn't count on getting that changed.

      

The proposal was to rename the built-in types to something wordy e.g. *__sv_logic*,

(which can be a keyword), and then have an initial typedef of that to *logic* (not a keyword)

which can be "forgotten" if necessary with an untypedef. As far as I can tell this should not

change the behavior of SV at all with respect to existing code.

    



Which is substantially the same as what I wrote, except with the

addition of untypedef instead of just not including the standard

typedef if you didn't want logic pre-defined.



A number of variations on this theme were brought up in the Accellera

and IEEE committees.  I know you suggested some, as did I.  But they

were all rejected, so there is no reason to expect that to change.



  

This is a different committee and we're considering proposals for the same problem (most
of the folks doing AMS have not been involved in SystemVerilog development), so I'm
reiterating my proposal - feel free to reiterate yours.


As I said before the mechanism I proposed is a general purpose way of limiting the

scope of various types. There is plenty of opportunity for users to create data-types that

will clash with other designers' types, disciplines or natures etc. which are likely to

make the source descriptions ambiguous (and unparsable).

    



Your mechanism is not general, since it doesn't deal with types that

are defined with reserved words rather than typedefs.  In particular,

it doesn't deal with the type in the subject: logic.

I'll repeat: If you rename the keyword logic to (say) __sv_logic and then typedef __sv_logic to logic, then logic does not  need to be a keyword. You can do the same for all the predefined types, and if you can think of a name for the predefined types that can't be a user defined type or an AMS keyword all the better (e.g. $sv$logic). 


  You can argue

that your mechanism would be more general in a different language where

these types were defined with typedefs.  However, we are talking about

SystemVerilog, where they weren't.  Nor is there any guarantee that

this will change.



  

If you know any reason why my proposal isn't 100% backward compatible I'll be glad to hear it.


Meanwhile, the mechanisms of `begin_keywords and file-based compilation

unit scopes are already part of the P1800 standard.



  

Draft standard.

Kev.



Steven Sharp

sharp@cadence.com <mailto:sharp@cadence.com>