Meeting 8 Minutes

Teleconference, November 16th, 2004
A quorum of 12 out of 15 voting members present.
Attendance is noted on the web site roster.

1. Call to order

Meeting was called to order at 09:02 PST/16:02 GMT.

2. Approval of minutes from meeting 7

Hamilton B Carter moves to approve the minutes.
Andy Piziali seconds.
No objections/abstainers. The motion to approve the minutes was carried.

3. Present Keywords proposal (Language TF)

This has been discussed in the past and work was done at the Basic Language TF but there were no clear recommendations. Chris Macionski requests to postpone the talk until Cristian Amitroaie arrives.

(This item discussed chronologically after item 5 on the agenda, and is summarized here out of order)
Christian: Did everyone take a look at the document that we posted (94k PDF file)? Shall I go over it and then go over the basic language group recommendations?

Yaron: I suggest that you do a brief on each section only then the recommendations

Christian : The TF essentially came out with no suggestions - there was either the choice of not reserving any keywords - which would have no impact on any of the existing code as this is no different to its current format OR we can have reserve phrases which is a change and will thus impact some of the existing code.
Under option 1, every keyword is a reserved name which means that the user has a long list of reserved names to remember. Option 3, preferred buy some members of the group wanted to reserve nothing, parsing is not too difficult but it may have a performance trade-off. The Basic Language Task force concludes that it is going to go for option 3 - we have nothing more to say.

Discussion:

Christian: My personal preference is no reserved key-phrases

Andy: Doesn't this make parsing difficult? I know its for backward compatibility but surely if this is more important than simplifying the language then maybe people won't wish to adopt it anyway?

Christian : Some people can use less than 300 words to express their entire life. It would not necessarily simplify the language as we would need 300 odd keywords and 150 odd key phrases. As far as I am concerned I can parse the language and support the macros for the rest you can find workarounds. I would rather have full use of the macros rather than give up this power in favor or easier parsing, part of the strength of the language is its special extensibility. On the other hand someone might also be dependent on a keyword for parsing . The current code of the e-language is based on no keywords and having flexible macros is core to the language. Examples of this have been given in the document online.

Matan: I wish to add about Andy's remark, some misconception that this is about compatibility versus good coding practices. Compatibility is certainly a problem, with a current parser that accepts half of the words in Christians list but has trouble with the others. On the other hand it is possible to maintain good coding style by using strict coding guidelines. Reserving so many words would make the standard useless, no one ever wrote or would write for it. It is not an improvement to have such a strict limitation on vocabulary. As Christian said, its different to other languages, it has no wide filter and is still not final. It would make a standard useless

Joe Hupcey: A counter argument is - reserving words would make the code more maintainable. Although it is restrictive it would make it more readable to others - for example using delay as if its an identifier would give e portability.

Andy : Any parser will point out differences to the user between identifiers and keywords surely? - This will assist users trying to write or use maintainable code. I have experienced this recently with the problems that the parsers deal with and the users themselves deal with.

Avi: Everyone's talking about identifiers. Talking about macros *example of a macro given* I wouldn't be able to use 'do 'for' etc if they were reserved in which case I wouldn't be able to use macros so simply.

Joe: True - but from my experiences its beyond the simple defines. These are only used uncommonly - if there are more limitations then we would force users to use other words other than 'do' etc.

Meirav: Why can't you use 'for' in a macro?

Avi : In the definition of a macro - you can't use reserved words within a pattern

Matan : to dispel what Andy said. We're actually having a lot of trouble getting an e parser. Actually one that we released on Shareware is on the IEEE downloads page see (http://www.ieee1647.org/downloads.html#An_open_source_parser_for_e)

Yaron : The parser on the web site is actually Christians - it has no relations with Verisity.

Matan : There's one e-parser which reads keywords with no problem, there's another that doesn't but the keywords are about 80 words only and many are very useful words. There is no e style written which is so strict that it complies with this standard - we have a parser which gets along with about half of them - taking the whole list would in effect kill the standard.

Joe: maybe some users have user words such as delay everywhere. They will need to correct this - no other language allows you to use keywords so this is not unusual. It will require that new tools will address or have the ability to recognize the issues and give warnings to the users. The main interest should be in doing better in the future rather than looking after the legacy code.

Matan : Are there any e programmers here that know all of the keywords in C?
<<deathly silence>>
Matan: If you think of sequences as macros or keywords - I don't think everybody who discussed ports etc mentioned macros - so maybe reserving macros? A couple of groups on the list could be knocked down even if they don't do all, thus reduce the impact on parsing and legacy code

Yaron: on what principle? Should we leave things such as 'time' is built in and not user defined? There's no reason to reserve it. And other time units such as 'sec' 'min' which we can parse as identifiers. There are also a couple of others which may be like this even if we do decide to reserve the rest.

?:One problem with that approach is that you'll need to remember which is the keyword and which is not - as one is reserved

Yaron: See it as a way of defining the language - there is some duality which exists today. Thank you all for the discussion we need to move on and as everyone appears dug into their positions we will put this forward to ballot which I will send out.

4. Update on coordination initiatives

Yaron: This is with reference to coordinating with the P1800 SystemVerilog, the P1666 SystemC and the P1850 PSL IEEE working groups

4.1 P1800 SystemVerilog

I had an e-mail exchange with Johny Srouji, chair of the SystemVerilog working group. He has agreed to bring the subject up at their next meeting which is being held later this week in Israel. They are on a very tight schedule, however, and plan to complete by November of next year - therefore they do not have a lot of time in which to implement any changes to the language although they agreed that maybe they could in future revisions. For us there is no urgency so we do not have a similar problem - we'll just need to wait for a response from their WG. They did discuss maybe setting up a joint taskforce with their interface teams.

4.2 P1666 SystemC

I had an informal discussion with OSCI Chair Mark Milligan.- although it all sounds interesting we probably wouldn't engage with direct work through OSCI as its non IEEE organization, which brings up issues with IP rights etc. Unsure what forward progress may be made on this. We are still waiting for P1666 to be approved by the standards board - I will contact Victor Berman, who is the Chair, once this has happened.

4.3 P1850 PSL

No chance to contact Harry Foster yet. Internally we discussed this with the foreign interface taskforce about adding an API. It was suggested that we could model an API to match specman ESI. We could make it compliant with the standards with the advantage that there would be one set API rather than various tool specific ones.

Vitaly: Do we need to add this to the LRM?
Yaron: So far this is simply a report of what was discussed - re is ESI ok in its current form or does it need to be changed? It is not released by verisity so I need to be sure - this is a preliminary look only.

Mac: Theres also a VHDL WG that’s active - will we not also want to contact them?
Yaron : Yes - but although they have some changes there is not actually a lot of progress being made on the testbench side of things - I will contact Steve Baily to discuss further.

5. Update on LRM Work

Yaron: After the last call Ron prepared the version to be split into a per chapter basis so that it was easier to download for those interested in specific chapters only. These were all promptly posted on the web site (see http://www.ieee1647.org/downloads.html#Draft_0.2).

Other than that all the issues on the issue tracking system that were not updated in tim for the last revision have been referred to version 0.2 as opposed to 0.1.

Matan: Which issues were selected and which ones were chosen for the next revision??

Yaron: essentially there was a bit of a time crunch on this as we had only so many hours available to be able to work on it, however we did want an update as version 0.1 was so 'long in the teeth'. To enable us to get an update we basically went through and picked up all the easier ones to implement and I assisted Ron with it - we then however ran out of time so reassigned all the ones which hadn't been implemented into the next revision to be implemented for that one.

6. Task force updates

TF2 - Basic Language
Chris Macionski: The group was reviewing the keyword issue, (see section 3) . The group has bought up some new topics which are being discussed and revising the latest LRM.

TF3 - AOP
Matan: had been away for quite a while. They are looking to incorporate some work about load order - this will soon be added

TF4 - Constraints and Generation
Ken Sailor was absent

TF5 - Coverage
Andy Piziali: Not yet started on 0.2 LRM revision

TF6 - Temporals
David van Campenhout: lack of critical mass is a problem in this group so if anyone was interested in assisting with temporals…..?

TF7 - TCM's
Matthew Morley was absent.

TF8 - Foreign access
Pitchumani Guruswamy dropped off the call.
Vitaly: There have been no new developments since the first pass of the revision. There was a discussion about whether to drop all vhdl related constructs from the manual but maybe its too late for that.

Yaron: This can be done with the approval of the WG (as it is an incompatible change). The TF needs to prepare a recommendation similar to the work on keywords.

7. Other Business

Yaron: There was a DASC steering committee meeting last week. There is a motion to update membership fees to $100 per individual as its been held at $40 for the last 10 years. DASC currently runs a $10,000 dollar deficit, although the IEEE covers this. Can all DASC members please reply to the Ballot.

Re approval for our WG bylaws - I'm expecting a DASC-SC ballot on that subject

8. Patent policy

The chair has issued a call for essential patents, in compliance with current IEEE/SA PatCom guidelines. The WG members are advised to review the call for essential patents and the patent related slide presentation posted on the web site .

9. Next meeting

Please remember to send e-mail to rollcall@ieee1647.org so that your attendance on this call is recorded.

• Please DON'T send these e-mails to the reflector
• Use the e-mail address you registered with

Next meeting is set to Monday, January 24th at 9:00 AM pacific (same time as today's meeting).

10. Adjourn

IEEE/SA home
IEEE Standards Association

DASC Home
Design Automation Standards Committee

VLSG Home
Verification Language Study Group

The 1647 PAR
Project Authorization Form

(Updated Wed Oct 11 16:18:36 PDT 2006)