Subject: Re: [sv-cc] SV-CC minutes 03/11/03
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Wed Mar 12 2003 - 05:18:54 PST
Doug,
thanks a lot. Great minutes, you must be pretty overworked after this ...
Only one minor correction, and question. See below.
-Michael
"Warmke, Doug" wrote:
> 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
I said I did this already yesterday (on Monday), it should have been seen on the reflector.
At least I have received it over the reflector. Nobody else? I am curious now ... after all these mailing list problems!
> - 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.
--NOTE: The content of this message may contain personal views which are not neccessarily the views of Motorola, unless specifically stated.
___________________________________________________ | | _ | Michael Rohleder Tel: +49-89-92103-259 | _ / )| Software Technologist Fax: +49-89-92103-680 |( \ / / | Motorola, Semiconductor Products, System Design | \ \ _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany _ | _) )_ (((\ \>|_/ > < \_|</ /))) (\\\\ \_/ / mailto:Michael.Rohleder@motorola.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \
The information contained in this email has been classified as: Motorola General Business Information (x) Motorola Internal Use Only ( ) Motorola Confidential Proprietary ( )
*** This note may contain Motorola Confidential Proprietary or Motorola Internal Use Only Information and is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email and its attachments, if any, or the information contained herein is prohibited. If you have received this email in error, please immediately notify the sender by return email and delete this email from your system. Thank you! ***
This archive was generated by hypermail 2b28 : Wed Mar 12 2003 - 06:07:29 PST