Surrendra Dudani
Karen Pieper
Brad Pierce
Bassam Tabbara
Stu Sutherland
Dave Rich
Issue Discussion:
Issue 76, 109. 119: In Francoise’s review, she suggested friendly amendments for these issues to clarify the English.
The Champions recommend that the P1800 pass these proposals as is and a new erratum making Francoise’s suggested changes is filed as immediate priority. Unanimous.
Issue 50: In the discussion in the SV-CC, the split in the committees was along lines in the user community, trying to determine which would be the larger affected community. Existing SystemVerilog and DirectC users fear loss of backward compatibility with respect to the existing code they have using these functions. The PLI users fear that when they move to using direct access they will have to rework their existing PLI data access.
The Champions recommend that the P1800 discuss issue 50 regarding the non-unanimous backward compatibility change. Dave against. Surrendra for. Brad is for. Stu for. Bassam for.
Issue 205: The issue is to make the data layout of C-compatible types C-compatible. The discussion focused on increasing binary compatibility across simulators. This proposal makes SV’s layout consistent in the layout of the datatypes in C. The potential negative impact of this change is the limiting of future optimizations.
The tradeoff is C-compatible datatypes through the DPI vs. future potential optimization opportunities. This change is backwards compatible because there was no specification of the data layout in previous versions of the standard.
There are no cross-the-committee problems here.
The Champions recommend that the P1800 pass this issue. Unanimous.
Issue 163: Steven was afraid this might impact datatypes on wires. He suggested using reg like var is proposed now.
The Champions recommend that the P1800 pass this issue. Unanimous.
Issue 254: Doug was taken by surprise by one implication of this with parameters. When Doug saw that there was ambiguity in general rather than with parameters in specific, he was concerned that it didn’t resolve 32 as he thought, and he wanted to think longer, so he abstained. He later voted to close 32.
The Champions recommend that the P1800 pass this issue. Unanimous.
Issue 125: The minutes were lost because Charles lost the disk on his machine. As a result, we do not know the exact vote.
The Champions recommend that the P1800 pass this issue. Unanimous.
Issue 197: Dave would like to see strings behave more like arrays.
The Champions recommend that the P1800 pass this issue. Unanimous.
Issue V-629 (in the boyd.com database): Cliff opposes all defparams.
The Champions recommend that the P1800 pass this issue. Unanimous.
Issue V-530, 605: Charles Dawson would like to move these back to the SV-CC for a more formal process.
The Champions unanimously agreed that no discussion was required on the remaining issues. They are all ok.
Issues that will cross
committees or are controversial:
168: Datatypes on wires: DPI access for datatypes on wires is not defined. We believe that Steven Dovitch may be creating a proposal. The SV-CC minutes recommend that the P1800 discuss whether the VPI needs to be addressed in this proposal.
Champions recommend that the VPI changes be addressed in the same proposal. Surrendra, Brad, Bassam, Stu agree. Dave prefers it be passed as a separate item.
Stu believes that resolving this would be spread over at least 3 SV-CC meetings, to allow discussion, research and voting.
BC and CC schedule risk.
Bitstream types: A new issue Dave will file shortly. Class is a bitstream type, but there is no description of the behavior of a class as a bitstream type. This issue will cross the SV-EC and SV-BC. The datatypes groups think it would be nice to use the phrase “bitstream” type if it had a clear proposal.
Dave is on both SV-EC and SV-BC and can represent both perspectives.
41 and 169 in the SV-BC need to be reviewed by the SV-CC: Do prototypes require the names of formals? Do the DPI prototypes have the same form as the other datatypes. Do we need separate BNF for these or footnotes, or?
Bassam to raise with Charles, and to be sure to invite Brad, Francoise, Stu to the discussion.
51 in the SV-BC need to be reviewed by the SV-CC: Are integer types a form of packed array?
Bassam to raise with Charles, and to be sure to invite Brad, Francoise, Stu to the discussion.
315 with the bind construct: Involves many of the same issues that generate does. Bind was originally put in by the SV-AC under accellera. The AC agreed to move this over to the SV-BC. Issues are with how defparams, parameters, interact, etc. The solution involves at least one not backward compatible change. The construct should probably move out of section 18 as well.
Doug Warmke is driving this in conjunction with Mark Hartoog. We are wondering if there is VPI access for bind? It could end up as hard of the datatypes proposals. The LRM has no definition of them, just an example.
We could take a different approach and clean up the current language rather than enhance it as the current proposal seems to do. (Allowing to parameterize instances inserted with the bind construct for example).
This is a risk item for the schedule.
BC-schedule risk. Dave considers this a showstopper for the release.
196: Extending argument types for properties and
sequences: AC schedule risk
Next Champions meeting
We adjourned at