Meeting 10 Minutes

Teleconference, February 28th, 2005
A quorum of 10 out of 11 voting members present.
Attendance is noted on the web site roster.

1. Call to order

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

2. Approval of minutes from meeting 9

Andrew Piziali moves to approve the minutes.
Lori Kate Smith seconds.
No objections/abstainers. The motion to approve the minutes was carried.

3. Review list of technical Items pending inclusion

Yaron:
During the last meeting we decided to get the technical issues into some kind of order and get a handle on what has still to be done for the 1st revision of the standard.

This has been discussed with Joe the editor re what needs to be ready for June 1st ready for review, some others joined in the discussion and we came up with the list which we posted as part of the agenda

List of technical issues to be done

- add an introduction chapter with technical summary
This is a requirement by the standards committee and should have a high level description of what the standard is about. Yaron currently working on this.

- document load order and visibility
This is not addressed well in the LRM. The AOP TF and Matan have been working on updating this - we may here more about this later in the meeting from matan.

- parsing infrastructure
This is also being looked at by Matans team. It is potentially aimed at reunifying defines and other language constructs. If this is ready in time then it may be considered for entry in the 1st revision.

- document the reflection API (optionally)
We are uncertain if we have the time for this, really its up to the AOP TF to decide whether to decide or put a proposal forward

- document method extension principals
Again this is down to the AOP TF - it is treated poorly in the current LRM so we need to know if we really want to fix this

- document the decision on Verilog and VHDL declarations
Verilog and VHDL are to be discussed later in the meeting

There are a few chapters which have not completed their initial review :
There are some which have things such as the constraints are too tightly tied to a particular constraint resolution engine version which it was originally based on. We need to make this more implementation independent.
- review of the constraints chapter (to remove implementation dependency)

The next three chapters require reviewing
- review of the TCMs chapter and related matter
- review of the temporals chapters
- review of the library chapters
Nobody is signed up to review the library chapter at this time.

- review of the macro expansion chapter
- resolution of all issues logged in the issue tracking system

There are also still a bunch of issues still open in the issue tracking system. These have all the technical information provided although it is still a fair amount of wrk. We do need to achieve closure on the list of issues ready for the first revision, which should include everything discussed in meeting 9.

Any missing items will have to be brought up as urgently as possible so that it won't end up disrupting the editoing and ballots later on.

Andy:
We're currently having one more pass over the coverage chapter - if we have some issues that we are aware of when we are reviewing this do you want us to open these up as new issues?

Yaron:
Yes - although if it needs a larger rewrite we may have to carefully consider it.

Andy:
Mainly its about some global substitutions and also some local ones so its mainly a case of cut and replace

Joe:
On the global note I'm easy - for local issues let me know, either enter it or I'll deal with it individually with the person.

Yaron:
Just a note - I'd like to emphasize that part of the reason for the issue database is to keep some audit trail about our decision making process. Hopefully we can point to the discussion and the issue will be logged and show the deliberation that led to the decision.

Joe:
On another note for those of you who have not been in an IIEEE group before , it used to be a bit looser and you could contact me directly or you could just edit out bits from the meeting and incorporate them in. But apparently the IEEE is now being a lot stricter about following guidelines.

4. Technical presentation of the load order issue

Matan not available.

5. Technical presentation of the Verilog and VHDL declarations proposal

A link to the proposal in PDF form

Eran:
We propose to exclude both the verilog and vhdl declarations from the standards. It is discussed in chapter 25 which discusses VHDL's interface with specman. Most of the chapter is about the VHDL and Verilog declarations and we propose to exclude these declarations. The declarations serve specific purpose of defining interface features, compensating for shortcomings of specific interfaces. These could be addressed more naturally by the writer of an interface adapter. The general attribute mechanism can be used for that purpose.

Yaron:
Is it conceivable that somebody creates a tool that has all the interface functionality and does not require such constructs?

Say we re-implement the standard in a different tool can we provide the same functionality that specman provides with out these constructs?

Eran:
Specman does not use any of these declarations for any language needs, rather these are used by the adapter to match behavior of the PLI for instance. The new implementation can take care of this in a more natural way.

Andy:
What about the ability to in-line verilog code actually within your e program

Eran:
You can use any function or any method or any user defined macro for this - If you want to connect your implementation to verilog you can use a vendor defined macro or something like this.

Pitchu:
I think this has to be considered for a vote. At this point this is the recommendation of the interface TF

Yaron:
Since the proposal was made very recently, people may need more time to review. We will table this for now and decide on the issue during our next call.

Matthew:
I have a couple of questions - firstly I didn't think that the LRM that we had prepared included anything about macros and they were talking about using macros as a substitute for something which is being dropped from a chapter and secondly I didn't think that we had included ports as part of the LRM - so have we now added ports

Vitaly:
Actually its an issue of interpretation - we don' t have to say that they are macros - the issue of ports is that they are user defined entities and that can be left for interpretation - I think ports are declared in general and external ports are not part of the language but are in fact just a kind of binding.

Matthew:
It's a suggestion then for Vitaly to use method ports as opposed to the verilog code or vhdl code constructs?

Vitaly:
No this is not what I meant - I meant that we should use simple ports and event ports - Method ports are not part of the IEEE standards proposal

Joe:
I have two points that I'd like to add to this too. As an editor I'm always having to reference to something like verilog or vhdl and generally speaking if you're going to do so - other than an open reference you very much want to say that you're using this in a very limited sense and here is the limitations as opposed to trying to expand upon it - and my other general point and this should be seen as true within the revised LRM is references to specman like that HAVE to come out, we've got to be as neutral as possible and therefore with the proposal in general we should also make them more HDL neutral.

6. Task force updates

TF2 - Basic Language
Chris:
We have not had any meeting since the last WG meeting - so nothing to report. Some of the members are going to propose some things and are actively working on their presentations for the group.

TF8 - Foreign access
Pitchu:
We had a meeting on the 16th February and a discussion about the VHDL and Verilog Declarations. We have also identified some things that need top be edited for chapter 6 so we have submitted a summary in a mail to you.

Yaron:
I have some bad new about the Generation task force - ken sailor has unfortunately switched positions and is too busy to continue in his rule so I'm look for anybody who would like to replace him. Please contact me if you're interested

7. Editor's Update

Joe:
I've had a chance to look through all of the chapters except for two of the library chapters - I'll try and look at those later today. I've come up with a format that I'm going to be using for what I'm going to do to help me condense some of the material now it's a broad outline but hopefully you'll all get to see this within the next couple of weeks. It's about a two page document which stresses that 90% of the examples are going to come out and the syntax etc. all can come out as it looks much more like a users guide. Can I ask you all to keep a copy of your draft pdf as they'll come in handy later. We're looking to shrink the standard by at least a half to 300 - 500 pages. I'll also shrink a lot of the white space that has the syntax examples in. I'm not identifying any big chunks of re-work that needs to be done I'm happy to say. Next week yaron and I are going to sit down and go through all the issues and whether we should database everything. I'm still a little bit up on the air about how I should continue forward, some of the chapters really haven't been reviewed at all - so should I start dealing with those or should I start with those chapters that you're more familiar with. By next week I hope to have completed an updated version of at least 1 section. Then you can take your pdf's and my proposed and see what the difference that is. I'll borrow off a conversation I had with Harry foster who says these standards proposals tend to be literal, dry and pedantic simply what needs to be is if this construct is used at all and how it needs to be used and that's it. One break is that the IEEE is more flexible <<woof woof woof>> (dog barking in background) they say we can insert a reference into a web page which will allow us to show examples which at least will be of benefit to the users.

Andy:
Joe - can you tell me what the motivation is for shrinking the size of the standards and removing the examples that clarify syntax etc.?

Joe:
It makes sense to have an example for usage. Generally speaking for standards it used to be that examples were seen as relatively superfluous. It also means that there's a lot of descriptive test. Therefore sits better to have a smaller standard in the first place which is tighter and more concise. I have a personal preference in that I think the smaller it is when it first comes out the better it is and I think that's normally less than 500 pages. An exception to that was with vhdl …. Please keep your current draft of your standards. I do think it makes sense to develop a web site which will have all of the examples - its just not something that I'll be involved with - at least initially.

Yaron:
Ok so one of the issues is how we should go about things re picking a particular example chapter

Joe:
I would prefer a chapter which has been worked on it would be a good example to show how things change for people who are familiar with the material. Also to use as guidance for those who are developing new material to see the difference between this and the more elaborate descriptions that you currently have. An example would be good We'll definitely take the remaining portions and make them available on our web site or whatever

David:
All of the PSL operators discussed in the PSL standard have an example - so are you saying that these will be thrown out the same way?

Joe:
Actually I'm not the editor for PSL but I think they're staying in. There are incidences within the 1647 document where there are 6 or 10 examples for one construct - its these excessive examples that we're taking out. One of the reasons is that the IEEE ref com board will say that you're trying to define how people should interpret this and and how they should therefore implement it.

What I want to do is to say that that you've made my job easier - unfortunately the way that a lot of international bodies try to drive things that are easily translatable and not implementation specific. Hence removing most of these examples so that its a standards not an implementation guide.

7. Other Business

Pitchu:
Is there anything that you want for the IF TF about systemVerilog or systemC - should we discuss this further with them - is there any work to be done?

Yaron:
When we approached them they were accommodating in principle but they were too busy doing their initial revision at the moment. In the future there may be some collaboration. It seems natural that these things may happen after the initial revision. We did cover this conversation a couple of meetings ago but if anybody feels strongly then they can bring it up again

Joe:
I need the material in and a first editing by June 1st - and although June 1st seems a little way off but its only a couple of months. What do you want me to do - do you want to see it piece by piece or in one big document in the summer as I don't want to bog everyone down with lots of work to do in the summer.

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, April 4th 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:44 PDT 2006)