Subject: Re: [sv-cc] Polls on extern/export and representation of SV data types
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Mar 11 2003 - 02:24:55 PST
Joao,
thanks a lot. Comments interspersed. Hope this clarifies my problems a little bit. Kevin might have some more or even better examples.
-Michael
Joao Geada wrote:
> Michael,
>
> With respect to externs at top-level, the rules are no different than those
> that apply to any other SV declaration: you cannot declare the same name
> twice. Given that SV supports conditional compilation etc, I do not see a
> compelling reason to violate basic SV rules just for DPI.
> Of course, I am willing to change this if some can give a convincing reason as
> to why DPI must have this flexibility.
I agree to your point about compliance with other SV declarations, but I have to say that this is a restriction that I envision as being
extremely reuse unfriendly. See the following example (currently from hot air, but I have seen sthg. similar already in other contexts):
- Assume you have a company internal bus standard, and there are some C functions used by the related code. So you might have a
testbench or protocol converter that uses some C code (e.g. for signature calculation, ECC calculation or similar) you have to declare
as being external.
- Of course your system need to include multiple instances of this bus/protocol
- Now assume you have multiple groups providing you one or multiple blocks, all of them are using one instance of this bus
- You are the poor integrator having to integrate all these blocks
- Think about a system consisting of about 100 blocks from 7 groups located on 4 continents. I have seen this more than once!
When for whatever reason more than one of these groups or you have decided to locate the blocks in the top-level, you might experience a
massive amount of error messages due to multiple extern declarations, when the extern declarations are being done outside of other
blocks. This is also the case when all these extern declarations are exactly matching.
The only way to avoid this is to change the hierarchy of your system (I am sure you don't want to suggest this to a designer) or to
introduce additional hierarchies, just to avoid those errors. On the other side this is something you very likely want to avoid.
Everybody within your company should (re-)use the internal standard, which uses these external C functions. As such the bus/protocol
block is very likely a standalone block that is located near to the top level. It will be only instantiated once (this can be of course
controlled), but what about the extern declarations usually being done by the other blocks. Do you want to modify the source code 100
blocks? Some of them you might simply not have write access to ...
IMHO, the proposal is unbalanced here from a usage point of view:
- everything is O.K. when you bury the extern definitions within lower hierarchy levels
- as soon as you have a more flat hierachy or you want to reuse blocks containing C code on the top level or you want to define stuff
at the top level you have to be very carefully not to collide with somebody else's code
This is my problem.
> For permitting externs in a location other than where it is declared: this
> requires new syntax for describing "definition" qualifiers, which currently is
> not present in SV. This is needed to qualify which function is being exported.
Disagree; for extern functions I don't request such a qualifier. I just request not to have an error message, if there are multiple
matching extern declarations on the top level. And yes, this complicates also the matching rules, because in case of multiple
declarations in the same scope also the default values must match, of course.
I am sympathetic to the Doug Warmke rule [Doug, sounds like Moore's law, doesn't it ;-)], but this is something I consider as _very_
important.
> Also note that the context of the exported function would always be its
> actual instantiation context (ie where the function really exists in SV terms)
> rather than the location of the export. This may lead to user difficulties
> (but my extern and export statements are in the same scope; how come my C function cannot find the exported SV function ? Well,
> because the SV function is actually in a different context, even though the export statement is in the same context as the extern
> statement ...)
> This change has a lesser impact on other parts of SV so if people feel strongly
> about this and consider the tradeoffs acceptable, we could change the export
> syntax to look like:
> export "DPI" [cname=]function [Def::]fname
> where Def is the name of the definition containing the function definition to
> be exported. Multiple :: separators possible if exporting from within a nested
> set of definitions (eg exporting a function from within a nested module defn)
I am far less religious about the possibility to qualify an exported function, Iff the first problem is solved:
a) when I can define multiple instance of extern, I just can use the export at the top level and have a more or less flat hierarchy. Not
nice, but this is a workaround
b) I agree that we first should have some thinking about the definition qualifier.
This is new to SV, so we better put some brain behind it.
c) The real problem here is that I don't want to be forced by the export semantics to change somebody else's code when this is not
neccessarily required, not to have this capability. In some cases it might be even intended, that I can not export something.
> The context of exported (and extern functions) is always the fully qualified
> instance name of the instance containing the extern statement or exported SV
> function definition. NOTE this is consistent with rules SV functions follow;
> specifically, with these rules an exported SV function could be invoked as an
> extern function and have exactly the same semantics as making a SV hierarchical
> function call:
>
> module top;
> initial
> bot.DPI_foo(..); // call 1
> bot.foo(..); // call 2
> endmodule
> module bot;
> extern "DPI" foo=function DPI_foo(..);
> export "DPI" function foo;
> function foo(..);
> endfunction
> endmodule;
>
> In this contrived example, both call 1 and call 2 have the exact same effect,
> that is, invoking the SV function "foo" in the instance of module "bot". Note
> that call 1 is a DPI function call, wherease call 2 is a SV function call.
> BTW: note also that if the extern was moved to top, then the C code would have
> to explicitly change context for the call to foo to work.
>
> Note that only _functions_ can be externed/exported. Class methods are not
> covered by the DPI interface (at least not in the SV 3.1 revision ;-)
Yes, but there was mentioning about this in the 'gnarly thread'.
> extern functions (even if pure) are not ever considered to be constant functions
> and thus cannot ever be used by elaboration time constructs (specifically this
> applies to definition of parameter values, dimensions of signals/variables,
> generate controls and instance arrays etc)
This is handled in a different thread. See there.
> For the final item, yes, at least 4 additional functions are required in the
> DPI interface:
> - get context from a fully qualified name
> - get current context (automatically setup for extern "context" functions)
> - set the current context
> - get the fully qualified name of a context
Thanks, that was my point.
>
> Joao
> ==============================================================================
> Joao Geada, PhD Principal Engineer Verif Tech Group
> Synopsys, Inc TEL: (508) 263-8083
> 344 Simarano Drive, Suite 300, FAX: (508) 263-8069
> Marlboro, MA 01752, USA
> ==============================================================================
>
> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org]On Behalf Of
> Michael Rohleder
> Sent: Saturday, March 08, 2003 4:46 PM
> To: Swapnajit Mittra
> Cc: sv-cc@eda.org
> Subject: Re: [sv-cc] Polls on extern/export and representation of SV
> data types
>
> > 1. Poll on acceptance of Joao's modified extern/export proposal.
> > http://www.eda.org/sv-cc/hm/0920.html
>
> Abstain.
>
> I very much like the overall proposal and basically most points within, but would like to see some changes in the two following
> areas:
>
> - I dislike that it is prohibited to have multiple extern declarations at $root level; this is a big inconvinience and I still
> don't understand the reasoning why it is such a big problem to permit this.
> - I would strongly request that it is _also_ permitted to 'export' a function from the $root level by fully qualifying its path.
> This is hindering reuse, because otherwise I would have to touch the Verilog code of someone else when I want to export only
> function declared within this code. Not nice.
> The current way of exporting functions is O.K., but extending it to permit also this would also be important.
>
> Also, IMHO it is still not completely clear on how the context is defined for _exported_ functions; a lot of very useful discussions
> went into the aspect of external functions, but this is also important. I believe the rule of thumb here should be that calling an
> exported function from an external function should behave exactly and (use the same context) as if the external function is an SV
> function and calls the exported (SV) function.
>
> My vote would be clearly yes, when solving all these issues (or explaining why it is such a problem)
>
> P.S.
> - I am against permitting to export class member functions. Until we support classes, this is too dangerous.
> - I am very unsure about external function calls during elaboration; if we really want to have this I would rather go for an
> additional attribute like 'pure' that explicitely requests this
> - I think we need two more service functions to retrieve the place where an external function is declared and called; this is
> needed for error handling. I am unsure whether PLI can already provide all this information after some of these discussions.
--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 : Tue Mar 11 2003 - 02:25:41 PST