Re: [sv-champions] Clarifications on issues from the spreadsheets

Hi Karen and Champions,

First, I would like to sincerely thank you for the excellent and quick 
work you have made yesterday, in the issues review and their routing to 
specific technical committee.

As for your questions, please see my replies below:

> As you've heard from Stu, it looks like some comments are missing from 
the spreadsheets, 
> both on 1364 and 1800.  Neil said that he was also missing his filing of 
a comment.  Can you follow up on that?
I asked Andy from IEEE to follow-up on this and make sure we are not 
missing any issue. He will specifically look at Neil and Stu comments.

> Can web links to the SVDB (mantis) be placed into the spreadsheet for 
delivery to the IEEE?
I am checking w/ IEEE whether there is a certain format that they want us 
to follow to capture issue resolutions (and also have it ready for 
RevCom). I still don't have an answer for that, but at this stage I 
suggest that we use the Excel sheets as the "master" place to track 
received issues and their resolutions. Having links from the Excel to the 
DB should still be Ok, assuming all links will be accessible (no broken 
links, permission access issues, etc). I believe this will keep the excel 
sheets more readable.

> The Champions would like to propose that the committees quickly pass the 
"easy" stuff so that
> Stu can get as much editing done as possible with inputs from the 4/19 
Champions meeting.  Is 
> that ok with you?  It will change our current operating priority.
This is a good point to consider, but here is my take on this:
The priorities which I proposed are based on the objective of resolving 
the high priority issues, starting from those which were filed by a 
negative vote. Still, I proposed resolving high "positive" (i.e. issues 
filed by entities casting a positive vote) before all other medium issues 
as I want to make sure we address all high importance issues
Usually, high priority issues are also the more difficult ones
It is not simple to gather and arranged F2F meetings for the technical 
groups and I certainly appreciate it. Therefore, I would like the 
technical committees to focus most of their F2F time and discussions to 
address high (difficult) issues first. This is why we advocated the need 
for a F2F meeting rather than tele-call
I tend to think that most of the simple and editorial related issues can 
be resolved at each of the technical committees via a tele-call meeting. 
Right?
Having said that, I do agree that it is very useful to resolve the easy 
issues in order to enable Stu to start the editing work in parallel. This 
is important.

Therefore, here is my suggestion:
I urge technical committees to schedule a two hours tele-call and try to 
address as much as possible of the easy issues. This tele-call should be 
held prior to the F2F meeting and focused only on editorial and easy 
issues
If this is not possible, I suggest to dedicate the first two hours (three 
at the most) of each F2F meeting to address the easy issues. Regardless of 
how many simple issues are fixed during this two hours slot, the 
committees should spend the rest of their F2F meeting to address the high 
issues (i.e. following the priorities that we defined)

Obviously, I think the first option (quick tele-call) is best but second 
one is also Ok. This enables some "balance" of enabling a quick resolution 
of simple issues (and keeping Stu busy ;-) as well as sticking w/ our 
priorities.

> The process we propose to follow is:
I agree.

> P1364 - Line 29:  The note (b) following Table 16-2 states ($nochange) 
"not ususally implemented in Verilog simulators".
I will soon (by end of today) send information of entities voting results 
for P1800 and P1364 (I had to confirm this w/ IEEE which is why I delayed 
this information). This information will only be sent to the ballot 
resolution group (Champions is part of this) and not to P1800 reflector. 
Therefore, you should have this information available to you (which is why 
I wanted to make this information available) and you can directly contact 
the filing entity in this case.

> P1800 - Line 37 of the spreadsheet from my mail: Problem with default 
arguments 
>             Is it ok for the champions to say it is a duplicate and save 
the committees work? 
Yes.

> Line 148: It is not define whatis the whitespaces policy from before and 
after the variable 
> names in the macro call arguments.  Also it does not say that tab 
characters are not allowed in this. 
> The Champions believe this is an issue for the 1364.  Can we forward 
this to them? 
It is not them or us - it's all one WG. The champions are addressing all 
issues (P1800 and P1364) and I already noticed you have a separate 
category called 1364.
Therefore, the answer is Yes - we'll catalog this under 1364 sheet and 
make it part of the P1364 ballot resolution process. The main difference 
of routing issues to SV-{ac, bc, ec, cc} and to 1364 (which is probably 
what you meant) - is that we need to capture issues moved from P1800 
ballot issues to P1364 and keep track of those. 
Thanks for bringing it up.

> Line 192: Section 8.4.1: Typo in formal semantic definition of SVA 
> The section should be H.4.1:  Can we fix the spreadsheet? 
Yes.

> Line 281: As a general comment, Sutherland HDL feels that the P1800 
standard, which is a set of extenstions 
> to the P1364 standard, should not be stand-alone reference manual. 
> These extensions should be integrated into the P1364 standard, making 
one unified Verilog standard, rather 
> than two Verilog standards. 
> However, we recognize that a majority of the P1800 working group members 
are not in agreement with this. 
> Sutherland HDL will not hold back its approval of the P1800 standard due 
to this general comment. 
> We will change our vote to APPROVE if the following six concerns are 
adequately addressed 
> (assuming that the resolutions to other ballot comments are also 
satisfactory). 
     >  No action is required.  Stu, the filer, said so.  What do we say 
as a comment? 
This important topic was brought up for a significant discussion in P1800 
WG, back in September and October 2004 time frame. It was agreed in the WG 
that we believe SystemVerilog and Verilog should become a one reference 
manual - so there is no argument here. However, given that schedule is 
king and we have a tight schedule for P1800 SystemVerilog - the WG agreed 
that for the short term (2005) the focus should be kept on making sure we 
release a quality IEEE SystemVerilog standard. After that, we shall 
discuss how we achieve our long term goal of ONE LRM. We have even taken 
the proper steps to make sure we keep both languages aligned and therefore 
specific assignments and task forces were moved from 1364 to SV-BC. 

I believe the ballot resolution group will make every effort to address 
all high priority issues and this hopefully convinces Sutherland HDL to 
change its vote to Approve. As for making SystemVerilog and Verilog a ONE 
LRM for this standard, it is not a goal for this revision as was already 
agreed in the WG.

I would also like to take this opportunity and emphasize that I do not 
expect the resolution group to be able RESOLVE every issue (some may be 
out of the scope of this standard revision or time frame). I do expect to 
ADDRESS (I hope the difference is clear) all issues as possible and 
resolve issues as recommended by the technical committees, Champions and 
as ratified by P1800 WG members.


> We gave this one to the Champions because they are the only group that 
covers the whole thing.
>  Johny, is this ok, or do you want me to give it to one of the 
subcommittees?
Yes, this is Ok.

I hope I was able to answer more of your questions.

Again, thanks for all the hard and excellent work. Keep it up!

--- Johny.