Subject: [sv-cc] Meeting minutes for SV-CC 03/27
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Thu Mar 27 2003 - 11:02:52 PST
---+ SV-CC minutes 03/27/03
---++ Attendee list
* Swapnajit
* Joao
* Andrzej
* Francoise
* John Stickley
* Bassam
* Kevin
* Doug
---++ Procedural Issues
Joao proposes accepting meeting minutes from 03/18/03 (Andrzej seconds)
Doug proposes accepting meeting minutes from 03/25/03 (Joao seconds)
SV-BC feedback still lacking on Andrzej's points for data representation.
Some SV-BC members may directly contact Andrzej on his issues.
Andrzej feels that it is very bad that these issues are not
taken more seriously by SV-BC.
---++ Discussion on User Data
We bat around the idea of unique keys.
Group decides to dump the svIsUserKeyUnique() function.
Require user to be fully responsible for generating unique keys.
Recommend use program loader symbol addresses.
We discuss use of NULL secondary userKey.
Is it just a normal pointer?
Is it illegal and reserved for some special use?
Joao brings up using NULL as value for primary key (svScope).
Could this be a shortcut to indicate current scope?
That way we avoid a call to svGetScope() before
any call to get or set user data.
Francoise is concerned about multi-threaded DPI functions.
John, others respond that in this revision of DPI, we
specifically state that multi-thread considerations
are ignored.
Andrzej says NULL is used as a marker for error situations.
For example, svGetScope() returns NULL for errors.
Then if someone does:
myData = svGetUserData(svGetScopeFromName("badname"), userKey);
an error situation wouldn't be detected.
Remember, svGetScope() can be called from non-context import functions,
and in such cases it is not required to return NULL. It may return
just any old thing.
Joao and John still want to use NULL as short-cut for current scope:
myData = svGetUserData(NULL, userKey);
Andrzej thinks this is error-prone, and would rather see
if ((scope = svGetScope()) == NULL)
errorOut();
myData = svGetUserData(scope, userKey);
Resolution is that all these NULL parameters are illegal:
- No NULL scope used as shortcut
- No NULL user keys
Note this is not by unanimous consent, rather Joao and John
just give up the discussion in the name of low priority.
We may address this in later rounds of LRM review, under
the criteria of cleaning up inconsistent or erroneous
specification.
---++ Andrzej's exported virtual function observations
More than one function can be exported with the same name,
as long as the headers have the same name.
Initially Andrzej was strongly in favor of having one cname
symbol corresponding to only one SV source definition.
But then realized that module/generate/interface variants
will occur due to different parameterization. Thus the
main problem of having the same cnames corresponding to
different function implementations needs to be solved anyways.
So why restrict users from explicitly doing the same thing?
It seems like a viable use model and an interesting modeling
capability. No one objects, so it is in.
Joao or Andrzej will write this up in the LRM, something
like adding Andrzej's bullet (YES) into the LRM.
---++ Swapnajit general LRM issues
Many people have sent comments on 0.7.
Are there any other comments pending?
When is the cut-off time for further comments?
Joao wants all comments in by today 3/27, 3pm EST.
This will be our contribution to SV3.1 draft 4.
Swapnajit clarifies that the actual deadline for
Stuart is tomorrow. Joao will send 0.8 version to
SV-CC reflector, and Swapnajit will forward that
to Stu.
Joao has already contacted David Smith and the
discussion of context export function name-binding
in Chapter 12 has been fixed up.
---++ More ad-hoc technical issues to finalize
Andrzej brings up that there should be no rule
excluding arbitrary legal cnames. For example,
cnames like "fork", "join", "begin" should be
allowed without restriction. Also, cnames may
collide with unrelated SV identifiers, such as
non-DPI function or task names, variable names, etc.
Doug brings up the fact that keywords never make
it into the global program namespace anyways.
Francoise and John think that allowing cnames that
collide with SV keywords make the parser tricky.
Andrzej has to write the parser for VCS and he
doesn't object.
Joao's opinion: Don't allow it right now,
relax the restriction later if needed.
(Doug's rule of restriction). Joao looks through
the SV keyword catalogue and figures that there is
a very low chance of any collision anyways.
Kevin proposes putting cnames in quotes.
Joao states that the syntax would look odd with
so many quoted tokens in import/export function
declarations.
Informal poll:
Francoise: likes restriction
John: votes for restriction
Kevin: no restriction
Andrzej: no restriction
Bassam: no restriction
Doug: no restriction if compiler guys don't care
Joao: no restriction if compiler guys don't care
So cname can be any legal C identifier, can clash
with Verilog keywords or identifiers.
Joao will put this into section 1.8.
Andrzej suggests using \ escaped id syntax around
a cname in order to overcome clash with any SV
identifier. The leading \ would be removed
in all cases. No one objects.
So the restriction is kind of back: Can't use keywords
for cnames. If you want to do that, just escape
the cname in the function declaration.
Joao will write this up, with \ rules in 0.8.
Doug suggests writing something up about
the fact that there is never a clash between
cnames and any visible user Verilog identifiers.
This archive was generated by hypermail 2b28 : Thu Mar 27 2003 - 11:04:49 PST