Subject: [sv-cc] SV-CC minutes 03/11/03
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Mar 11 2003 - 10:06:33 PST
SV-CC Meeting minutes for Tuesday 3/11/03
Francoise proposes accepting last meeting minutes.
Joao seconds. Motion passed.
Attendance
Kevin
Ghassan
Andrzej
Michael
John Amouroux
John Stickley
Francoise
Doug
Swapnajit
*** Procedural part ***
Bassam's updates to assertion API will be present in next rev.
Joao will only put in changes that are not controversial and
that everyone agrees with.
Swapnajit noted following changes are needed:
- Surrendra's feedback to assertions API
- Michael will modify annex to remove source inclusion
- Clarifications on context functions and extern/export part
Doug mentions that the reflector blocks large attachments.
Francoise says the other committees have no such problems.
Joao also frustrated, wants at least some feedback about the bounces.
Doug asks to at least temporarily lift all size limits, otherwise
we will have serious productivity problems.
Michael asks for the limit to be increased, and the size published
to us so that we know how large we can make attachments.
*** Context functions, extern/export functions ***
Joao and Doug mention that they need to understand the kind of
problems Michael illustrated in his email.
Doug says that a lot of the problem can be solved with some
kind of namespace concept for items that go in $root. But needs
to understand the problem more deeply.
Joao doesn't understand why DPI has different needs for function
name binding than regular SystemVerilog code.
Andrzej says we might need a separate global namespace that is
separate from SystemVerilog global namespace. Joao says that
the cname concept can be applied there. John/Michael say that
doesn't solve Michael's problem.
Michael: Using IP from multiple sources that use the same cname.
Is it a name collision problem? Or a re-use issue? Michael says
it's re-use - lots of users of the common C function. BFM has
C functions inside, each peripheral needs to instantiate the
bus protocol. Michael says that all kinds of blocks in the
design would like to use this BFM, so they all instantiate
either master or slave blocks of the BFM. They declare the
extern functions outside of the BFM instance, in their scope.
(Sorry I'm pretty confused about these minutes since the
discussion is going so fast) Michael will try to create a
specific example that illustrates his problems.
Joao: Motorola must have some reuse for Verilog modules themselves.
How are you solving it?
Michael: The problem stems from extern declarations being outside
the modules.
Doug, Joao: But the extern declaration is inside the module now.
Michael: I agree, but many people will just declare it outside,
since they think of it as a prototype. Since they will intuitively
think that since they are using C functions, they should code like C,
namely thinking that extern declarations are just prototypes.
In a way, the users are making a mistake, but they will do it,
and then the poor system integrator will be stuck with a big mess.
They will need to modify lots of code to get things working.
Joao: OK now I understand better. Don't really agree that this
is an OK way to do design, but it is a legitimate problem that
we should discuss. One of the main problems is the consistency
checks between the multiple declarations in a single scope.
Andrzej: Likes unnamed proto formal args, since that would make
the kind of use model Michael is envisioning safer and easier.
Joao: Allowing multiple declarations in same scope solves 50%
of Michael's problem. But the integration problem is still
present for any kind of complex cases.
Andrzej: Yes, but you can include same file everywhere to
get consistent results.
Joao: But you can already do that with existing proposal.
Michael: Want to avoid something I see often: A central
module flies around often, exchanged around, people then
take the Verilog code and slap it right into the source deck.
That way new objects appear up by the top of the hierarchy.
We have to watch out for colliding extern declarations up
there that would cause a lot of problems.
Joao: Methodology change should be a better solution to this.
Rather than language change. Because doing the language change
would be complex and require lots of intricate rules. The SV
side of the language is NOT C, it doesn't look like C, it
doesn't behave C.
John: We are getting confused, because we think we are calling C,
we think we should have C semantics imposed into SV. But that's
not right. What we're really doing is C replacements for SV
functions, and we need to keep with SV semantics on the SV side.
Joao: If multiple declarations exist, none could have formal names.
Michael: If multiple declarations exist, they have to be textually
equivalent.
Andrzej: But that's impractical, if formal names are not used,
they should be ignored.
Joao: But paragraph #1: Whatever language you are working in,
that's the semantics you follow.
John: You have to follow the rules of the call site language,
otherwise too much confusion.
Andrzej: But that's not pragmatic.
Joao: We have to be able to explain all our rules to the other
SV committees, and we have to have defensible positions.
Why should we treat DPI external functions differently
than SV functions? If something is wrong with SV functions,
and we have our finger on it, let's address it both for DPI
functions and for SV functions.
Andrzej: External functions should be treated differently
just for a matter of convenience.
Francoise: Worried about multiple modules declaring and using
the same external function.
Andrzej: This is an ideological issue, we should just poll on it.
Michael: Can't produce an example in time for a decent poll.
I think we can go with the "restrictive now, expand later in 3.2".
Andrzej: Would like to propose a conditional solution, which would
be what we implement if we decided to go for multiple declarations.
Several: Conditional parts of the LRM are not acceptable.
Joao: Will bring it up with David Smith
Joao: Does anybody object to disallowing external functions
at elaboration time?
Kevin: I object.
Francoise: We need to determine exactly where such calls
would be disallowed. For example, in initializing reg.
Joao: generate proposal has similar holes, due to the
ability to invoke functions as controls for generate.
Andrzej: Simply, elaboration shouldn't be mixed up
with compilation.
Swapnajit: Are we proposing deferring calling external functions
at elaboration time until 3.2?
Many: Yes
Some: Defer permanently.
Swapnajit: Will note it down as deferred.
Joao: Michael wants to be able to export something from
a module, without touching the module definition. Doug pointed
out that SV-AC is proposing "extends" as a solution, and Joao
thinks we should just free-load on that.
Swapnajit: Michael, when can you send out the example?
Michael: I will have to do it on the weekend.
Francoise: Why can't we just put export anywhere in the design
and use a hierarchical name?
John: You can't use hierarchical names, you would have to export
a declarative scope (like with the :: operator).
Doug: Francoise, you should study John's example in the tutorial
to see exactly what you can do with export. Using hierarchical
name, as you suggest, won't work for this kind of application.
Joao: Tries to explain the meaning of declarative context
function exports.
Francoise: What about export functions whose definitions
depend on module parameters?
Joao: Doesn't mind having a single-instance export declaration,
since it doesn't add any new syntax.
John: That implies you need to put in some error checking
machinery to make sure users don't call non-exported instances
of functions.
Joao: Will send updated version of his proposal out.
This archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 10:09:00 PST