Subject: [sv-cc] Re: SV_CC meeting minutes for 15 Jan, 2003: My action items
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Jan 28 2003 - 08:21:52 PST
I don't think there is a mismatch.
If you have a verilog array defined as:
reg [7:0] my_two_dim_array [0:31] [0:63];
A bit select would refer to a bit of this array and you would have to
specify it
using 3 indices:
my_two_dim_array[0][0][7] would refer to one bit in the packed dimension
A part select would be a subset of the bits in the packed dimension:
my_two_dim_array[0][0][3:0]
In Verilog you cannot address a element of the array which would be bigger
than a bit
or a part select you cannot write the following:
my_too_dim_array[1] or my_too_dim_array[0:1]
With Vpi the object named my_too_dim_array would be a 32 by 64 by 8
vpiRegArray.
By iterating on vpiRegs from this object you can get 32 x 64 vpiReg
each one of them will be 8 bits wide and you can ask for their respectives
indices in the unpacked dimensions.
For example you would get a vpiReg object which indices (vpiIndex
iteration) woud be 0, 0 for the first reg.
Francoise
'
Reg returned from the iteration. This reg
At 10:26 PM 1/17/2003 +0100, Michael Rohleder wrote:
>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 : Tue Jan 28 2003 - 08:27:15 PST