Subject: Re: Minutes January 7, 2003
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Jan 07 2003 - 14:27:18 PST
Kevin, thanks for this fast provision of minutes. As requested by Swapnajit and to further improve the discussion some comments:
Kevin Cameron wrote:
> January 7, 2003, 9:00-10:00am PST
> ...
> Meeting is dedicated to discussing Andrzej's Proposal
> [http://www.eda.org/vlog-pp/sv-cc/hm/0511.html]
>
> Should use 'svc' prefix for routines.
> Discuss handles (VPI or not) over reflector.
Short and simply said. The provided svHandle should match the corresponding tf_, acc_ or vpi_ handle when it refers to a
corresponding element. This will permit to directly run corresponding functions on it.
I am not religious about this. If there is too much overhead involved in this. fine. forget it. Anybody should feel free to show me
some good examples for reasons why this is too complicated or would require too much data. Without such examples, I think, it would
be a neat feature.
> void * - assumes similar layout to C within SV for arrays.
> Missing size functions.
> Bare pointers unsafe?
> Writing to data through pointer skips triggering sensitivity.
> Kevin & Michael suggest hiding pointers as handles.
Just to clarify this. According to Andrzej's example C:
...
for (i = lo1; i <= hi1; i++) {
for (j = lo2; j <= hi2; j++) {
my_value = *(MyType *)svGetArrElemPtr2(h, i, j);
...
*(MyType *)svGetArrElemPtr2(h, i, j) = my_value;
...
}
...
}
it is intended to permit direct access to Array elements by providing a pointer to them.
IMHO this is a dangerous thing, for the following reasons:
- when [as described earlier] it is the task of the SV kernel to perform the actual updates of a simulation object, it is mostly
impossible (without defining any implementation details here) that the provided void* pointer does directly refer to the simulation
object itself. Otherwise any modification of a simulation object will immediately take effect.
- there are [of course among others, but these are the two that immediately come into my limited mind] possible implementations to
prohibit this:
a) delay the actual update of a modified simulation object by introducing a 'commit' stage that is then performed by the SV
kernel
b) provide a copy of the array, that this actually being modified. The SV kernel does then move this copy or only the modified
parts to the actual simulation object when the actual update of the simulation object needs to happen.
- given the proposed functionality as layout in example C, there are several issues with such a scheme:
. option a) is basically impossible, when the void* pointer provided by svGetArrElemPtr2 directly refers the simulation object.
If it does not, it is basically option b)
. option b) is a hefty runtime overhead (because a full copy of the array needs to be created). As soon as a pointer to a
simulation object is returned THAT PERMITS THE SIMULATION OBJECT TO BE MODIFIED, it is a problem to control those updates by the
kernel. The provision of a pointer prohibits many optimizations; a problem I would like to avoid.
Also, Andrzej's proposal is IMHO a little bit inconsistent (in the sense of not being fully balanced), since it uses complementary
Put and Get functions (vcPutBitArrElemVec32 + vcGetBitArrElemVec32) to access the canonical representation, but only Get functions
to access the actual representation and providing a pointer to this representation for modifications. I feel it would be better to
provide here also Put functions for performing modifications, mostly for two reasons:
. it permits further optimizations; as an example it is possible that a Get function provides direct access to the simulation
object. Modifications could be guarded by declaring it as const, the compiler will flag any attempts to overwrite it [please note
that these are SV service functions, so we _can_ force it. If you want to cast away the const, your fault, you know what you do.]
. it permits to clearly identify the modified elements of a vector (which must have been performed by a Put function). This permits
different, better optimized implementations [e.g. create a copy only upon modifying (w/ or w/o checking for _real_ modifications),
or use a scoreboard to identify modified elements within the copy].
All this is impossible when modifications are done solely by modifying the elements referred by a void*.
Hope this clarifies my concerns a little bit. Kevin, any additions ???
Regards,
Michael
--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 07 2003 - 14:28:19 PST