Subject: SV_CC meeting minutes for 15 Jan, 2003: My action items
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Fri Jan 17 2003 - 13:26:16 PST
Hi all,
here is the response for my action items as defined in the meeting:
"Amouroux, John" wrote:
> ACTION: (according to Swapnajit) Michael to check on bit part select
> definition. [JA - This is the action from above.(?)]
Background:
Andrzej uses the qualifiers 'bit selects' and 'partial bit selects' within his proposal
(e.g. "There are also functions for bit selects and limited (up to 32 bits) partial bit
selects ("partial bit selects" refer here to slices of packed arrays of types
'bit' or 'logic').") I had some concerns that these or similar qualifiers are already
used within 1364-2001 and those names were incompatible or not fully consistent.
Result:
IEEE 1364-2001 uses the terms 'bit select' and 'part select'. Some description what
these are can be found at page 52 of the standard.
There are further some API functions that are related to those objects (look up the
object type 'accNetBit' and 'accPartSelect', and the discussion of 'Nets and net arrays'
(section 26.6.6 and further); especially with vpi_handle(vpiIndex, ...) and
vpi_iterate(vpiIndex, ...)
I feel myself unable to decide whether there is a 100% match between the 'bit selects'
and 'partial bit selects' in Andrzej's proposal and the 'bit select' and 'part select' in the
IEEE standard; especially when taking into account that 1364 seems to have a limited
view on what Verilog types might have bit selects/part selects. Do a search on 'bit select'
in Acrobat on the standard and you'll know what I mean. Since DirectC permits arrays
consisting of any types for its elements there is some possibility for a clash here. On the
other side it looks to me like DirectC might be a clear superset of 1364 here.
Therefore I would like to ask Francoise to help me out here. Do you see a mismatch
between 1364's definition and Andrzej's. I'm not, but - as said - I am not sure.
Dependent on this, my recommendation is:
a) use 'bit select' and 'part select' (not 'partial bit select') when both definitions match
b) use another terminology when both definitions do not completely match
Francoise, Andrzej could you tell me whether both definitions match???
> Issue 1.4 (Michael's)::::::::::::::::::::::::::::::::::::::::::::::::
>
> Reminder, the "pure" keyword means that there are no side-effects, even
> though pli/vpi read functions can be called. Doug suggests another
> qualifier that says NO pli/vpi functions will be called. Andrzej notes that
> we should have the keyword on if pli/vpi functions will be called and have
> the default be for no pli/vpi calls allowed.
> ACTION: Michael to come up with a proposal by the end of this week.
According to the latest specification I found in my email folders the declaration
syntax is (I might have failed to grab the most recent version, and there were some
later discussions on the exact syntax here, so please forgive me any mistakes here.
The one and only discussion is about the <attribute_list> element of this syntax):
'extern' <attribute_list> <return_type><fname>'(' [<arg_list>] ')' ["<cname>"] ';'
<attribute_list> ::= [ <attribute> ] <attribute_list>
<attribute> ::= "pure" | "context"
The attribute "pure" denotes that the corresponding C function has no side effects
and may be even optimized away when the context permits this.
The attribute "context" denotes that the corresponding C function uses one of the
four functions "tf_isetworkarea", "tf_igetworkarea", "tf_getinstance", "tf_mipname"
to establish the context it needs for further PLI calls.
ISSUE 1.4 request to clearly establish a relationship to the other API's. The discussion
during the conference call centered around the question: do we need additional attribute(s)
to permit this.
Some further discoveries while doing this work:
a) There is no document (or I was dumb enough not to find the right one) describing
the most recent version of the SV to C side. It might be good to have such a thing
published on the web site for further references
b) I have seen three different BNF versions of <attribute_list> in all the proposals I
have checked. They do not completely match; especially one of it would have made
the provision of an <attribute> mandatory. My understanding is that this list is optional.
c) The current definitions of "pure" and "context" are rather inexact on their meaning and
the resulting effects. I think we need to exactly define what is triggered by them and what
are the trigger conditions. We better prepare this correctly for the LRM.
I thought it might be a good idea to structure the problem space a little bit. What do we have:
. The DirectC function might do plain calculations without any side effects OR
might have side effects (storing information in global variables, using other API's, or write
some information into a file)
"pure" attribute -> this decides on possible optimizations that might resulting in pruning away
the function call when none of the outputs of this function call are further needed
. The DirectC function uses one of the above functions (... or its VPI equivalents) to establish
the context needed for further API calls
"context" attribute -> this decides whether the SV simulator must prepare the appropriate
context information needed for those calls or can omit this functionality.
QUESTION:
- Is there a single context, or is the context for vpi_ functions different from the context for
acc_ and or tf_ functions. When this is the case, we might need sthg. like "vpi_context",
"acc_context", "tf_context", and the global "context" in case of mixed API functions.
For me (being a newbie in the vpi_ area) it looks like the vpi_ context might be sufficiently
different from acc_ and tf_ contexts (which are very likely to be strongly linked). As such,
splitting "context" into "vpi_context" and "acc_context" might be sufficient. A mixed situation
might then be denoted by "vpi_context,acc_context". I think you get the scheme.
My current assumption is that there are at least two different contexts for (acc_,tf_) and vpi_
END_OF_QUESTION
. I was further thinking about other optimization information we might provide here. Something
like "we are calling acc_ functions to traverse some pieces in the design, but don't modify anything
within the design". Or "we are calling vpi_ functions, but will only modify sub-blocks of module X".
NOPE. I think we will end up with a definition chaos here for the user, when we start to define these
kind of attributes.
Besides that. I think that the latter kind of attributes are already defined in the PLI/VPI scope of
many vendor simulators. No need to intrude into this space.
So the proposal is: three attributes "pure", "vpi_context", "acc_context"; the latter two might be one
single attribute "context", if a single context can handle vpi_, acc_ and tf_. This means <attribute_list>
may have seven possible values:
- MISSING: There are side effects performed by the function, but no function from another API is
being called. [Calling an API function within a DirectC function is regarded as erroneous, and may
lead to unexpected results]. Calling this function must not be optimized away when its outputs are
no longer needed by the simulation.
- "pure": There are no side effects performed by the function, it might be optimized away when its
outputs are not longer needed by the simulation. No function from another API is being called.
[Calling an API function within a DirectC function is regarded as erroneous, and may lead to
unexpected results].
- "vpi_context": The DirectC function calls vpi_ functions and requires therefore the VPI context to
be prepared before calling the DirectC function. There are side effects in the function call.
- "acc_context": The DirectC function calls acc_ and/or tf_ functions and requires therefore the PLI
context to be prepared before calling the DirectC function. There are side effects in the function
call.
- "vpi_context,acc_context": The DirectC function calls vpi_ AND acc_ and/or tf_ functions and
requires therefore the VPI _AND_ PLI context to be prepared before calling the DirectC function.
There are side effects in the function call.
- "xxx_context,pure" [Any of the latter three in combination with "pure"]: Same as stated above under
the xxx_context description _plus_ READ ONLY access of acc_/vpi_ parameters (dependent on
xxx_context) related to the actual module and/or parameters of the DirectC function. No other parts
of the SV design will be access by the acc_/vpi_ functions.
[Would be permit to optimize away such a function, when it's outputs are not needed ???]
When you read until here, thanks a lot for doing this. I know it can be boring and I apologize for this.
This is clearly my fault. Hope this is at least a useful start for some further discussion on this.
-Michael
P.S. We might think about excluding some special functions (e.g. io_printf() from the need for setting
the context).
--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 : Fri Jan 17 2003 - 13:30:29 PST