Re: [sv-cc] Question from ["Edelman, Rich" <rich_edelman@mentorg.com>]


Subject: Re: [sv-cc] Question from ["Edelman, Rich" ]
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Jul 22 2003 - 16:04:36 PDT


Hello Rich,

thanks a lot for your interest in this topic. I'll try to make it short (and simple), but this kind of explanations tend to grow
rather fast ...

a) Your interpretation is correct, with some slight remarks. I'll will do some hair-splittering now, to clearly identify my
interpretation of your interpretation (what a sentence !@%& ...)
b) The specification only says that an override has to happen _when_the_file_can_be_easily_identified_as _being_identical_ (e.g. by
same path or same inode). This should prevent loading errors caused by multiple loads of the same object (which can easily happen in
case of shared libraries). Instead it should load such objects only once.
c) It does not say that a file of the same name overrides a file of the same name when they are located in different directories.
Instead I would consider this an error. I have too often seen multiple users have their own set of utilities/shared functions in
files/archives named util.o, common.o, shared.o ...
[If an user happens to have an exact copy of the same file in another directory I leave it up to the application to abort in this
case or to handle it gracefully. Such kind of problems can be easily solved at the user's side ...]
d) The override mechanism works at the file level (see the specification granularity); when there are name collisions between single
functions of two shared objects there is no way to prevent them or resolve them for an application.

Why this? The reason is mostly in the packaging of IP:
E) Bootstrap files will usually group IP belonging together in a single package. Singular objects specified on the command line will
often provide simple functions, extensions or shared functionality.
F) It makes sense to process the IP grouped by a bootstrap file together.
G) Another ordering mechanism (e.g. in order of appearance) would permit a single file specified by -sv_lib to override an entry in
a bootstrap file. Given that a bootstrap file contains IP that should be processed as a whole, this is undesirable (although I would
consider this as being harmless, since overloading happens only in case of b) -- which means its the same object).
As such the stated rule is a simple priority in favor of a better integrity of IP grouped within a single bootstrap file.

Hope this is the information you were searching for ...

Best regards,
-Michael

Swapnajit Mittra wrote:

> Michael, can you please reply to this?
>
> --
> Swapnajit Mittra
> Project VeriPage ::: http://www.angelfire.com/ca/verilog
>
> --- owner-sv-cc@eda.org wrote:
>
> From: "Edelman, Rich" <rich_edelman@mentorg.com>
> Subject: [sv-cc] Using "sv_liblist" - Annex F "Inclusion of Foreign Language Code"
> Date: Wed, 16 Jul 2003 14:31:22 -0700
>
> Hi,
>
> I'm new to SystemVerilog, and am trying to understand the
> behavior of the
>
> -sv_liblist "bootstrap file"
>
> as specified in the SystemVerilog 3.1 LRM Annex F.
>
> My reading of the specification says that a shared object
> specifed within a "bootstrap" file will override
> a shared object specified using -sv_lib.
>
> Can you tell me why we need this behavior, and how and
> when it is used?
>
> Thanks for your help.
>
> rich
>
> -------------------------------------------------------------------
>
> >From SystemVerilog LRM 3.1 Final:
>
> At the top of page 340:
>
> Compiled object code can be specified by one of the following two methods:
>
> 1) by an entry in a bootstrap file; see Annex F.2.1 for more details
> on this file and its content. Its location shall be specified with one
> instance of the switch -sv_liblist pathname. This switch can be used
> multiple times to define the usage of multiple bootstrap files.
>
> 2) by specifying the file with one instance of the switch
> -sv_lib pathname_without_extension (i.e., the filename shall be
> specified without
> the platform specific extension). The SystemVerilog application is
> responsible
> for appending the appropriate extension for the actual platform. This
> switch can
> be used multiple times to define multiple libraries holding object
> code.
>
> <...snip...>
>
> At the bottom of page 340:
>
> In case of multiple occurrences of the same file (files having the same
> pathname or which can easily be identified as being identical; e.g., by
> comparing the inodes of the files to detect cases where links are used to
> refer the same file), the above order also identifies the precedence of
> loading; a file located by method 1) shall override
> files specified by method 2).
>
> ________________________________________________________________
> The best thing to hit the internet in years - Juno SpeedBand!
> Surf the web up to FIVE TIMES FASTER!
> Only $14.95/ month - visit www.juno.com to sign up today!

--

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 Jul 22 2003 - 23:37:52 PDT