Attendees: Swapnajit Ghassan Andrzej Joao Kevin Cameroon Doug Warmke John Amouroux Stuart Francoise John Stickley Bassam Joe Daniels - Issue 1.2 Andrzej described proposal for issue 1.2 related to overridding builtin Verilog fnames with DirectC calls Swapnajit then clarified that requirement was for, a C function ref in C code, to be able to be overridden by a different directC version of that call. Discussion ensued pointing out that this was outside the control of the SV compiler, as foreign language compilation & linking (ie invisible to Verilog) Summary 1.2a: can user override a built-in exported system C functions from SV system invoked from C with his own implementation Voting (1.2a, summary above): 0/7/0 (No, Yes, Abstains) New issue: 1.2b: can user override a built-in Verilog function/task invoked from SV with his own DirectC implementation Discussion postponed Voted reject (John A. has details) - Issue 1.3 (name resolution rules) Andrzej described proposal: ie that this is already defined in SV ie SV name resolution rules apply. Voting: 0/7/0 - Issue 1.8 (distinguishing between C and C++) Andrzej described issues Joao & Doug proposed symmetry between externs and exports ie both define SV name and an optional external name Proposal 1(Andrjez, Kevin): extern svname (ansi-args) [ "linkname" ]; Proposal 2(Joao): extern [ "linkname" ] svname ( ansi-args ); where linkname is the link name to be put into the object file Proposal 3(Francoise): (* attributes *) extern svname( ansi-args ); Votes: Proposal 1: - Proposal 2: 1/6/0 (No/Yes/Abstain) Proposal 3: -/1/0 (No/Yes/Abstain) NOTE: new issue: change export definition to have same ordering. - Issue 1.10 (removing cmodules) Some discussion on future modelling requirements (foreign modules), led by Stuart. The concern is that we are incrementally adding foreign modelling capabilities before we're ready (ie all agree on mechanisms, goals, etc). Stuart stated that he'd be more confortable deferring all external module type capabilities to 3.2 Removing C modules: Voting: 0/7/0 Adding external modules (Doug's proposal) Voting to postpone this to 3.2: 3/4/1 (Put in 3.1/Put in 3.2/Abstain) - Issue 1.13 having constant attribute on function prototypes for input ports on directC functions Joao proposed to move this discussion to the DirectC C-side API discussion Voting: unanimous to postpone - Issue 1.9 How to find C/C++ code to link into the simulator Andrzej presented both his and Michael's proposals Kevin thinks that Michael's proposal is too complex, he'd prefer to see only a reference to library being given (at the extern declaration). Kevin would prefer to see a much simplified approach. Voting to accept Michael's proposal in entirety: 3/6/0 (No/Yes/Abstain) All yes votes with the condition of cleaning up the proposal All no votes primarily against the provision to supporting passing C/C++ sources to SV Voting to accept Andrzej naming proposal (only parts a, c): 5/1/3 (No/Yes/Abstain) John Amouroux: no, but would like issue revisited for 3.2 Stuart: no, but if instead of addressing source issues the proposal primarily addressed shared libraries (.so/.sl/.dll) then proposal would be acceptable Francoise also mentioned that it would be better to adapt the Verilog configuration mechanism to also address the binding to C - Issue 1.7 Direct vs Abstract vs Blended approach (direct for simple vs abstract for abstract) Stuart: how would user know what mechanism to access a particular type? Doug: "abstract" only to get array bounds and array dimensions. For everything else direct like access, and using A/B PLI-like format for vectors. Joao: discussion is premature, as we do not have (yet) a proposed C interface itself. As a goal, having interface being fast & simple is laudable, but going any further requires knowing what the interface itself looks like Stuart: defining the C interface to DirectC should be our highest priority Doug: need also discussion of memory ownership across the interface & dynamic memory Joao: this should be noted as an issue for the directC C side API Ghassan: propose to go over timetable of committee's actions this afternoon - Issue 1.2 John Stickley's queueable functions Lots of discussion on locus of control, multiple C threads, communication queues. Andrzej raised the point that, even if this proposal is accepted, is that there will be no effect whatsoever on the SV generated code. Joao it only has semantic effect iff system verilog is responsible for spawning multiple C threads; this is something we have explicitly avoided at every point. Francoise: why not use a standard Verilog attribute to denote the same information John S.: OK only iff this is a standard attribute Discussion to continue offline ---- lunch break ---- John A. kept meetings after lunch ... - assertion API discussion of this interface vs extension to VPI. module names: have to resolve nested definition issue (module in module, interface in module)