Subject: Re: [sv-cc] Updated proposal for C/C++ file inclusion
From: Michael Rohleder (michael.rohleder@motorola.com)
Date: Tue Jan 28 2003 - 07:24:16 PST
Francoise,
thanks a lot for this very good input. See below my responses/comments interspersed.
Regards,
-Michael
Francoise Martinolle wrote:
> Michael,
>
> I don't understand the multiple occurrences rule. You say that a library
> must and
> will only be loaded once.
> For example if my entry in my bootstrap file says:
> #!SV_LIBRARIES
> myclibs/lib1
>
> and I have a switch -sv_lib clibs/lib1
>
> These could be the same library copied in 2 different places.
> Does it mean I only load the first occurrence of lib1: myclibs/lib1?
This is actually a very good comment.
The rule is intended to clearly define how to handle libraries that are specified multiple times. I have seen this happening often,
many projects are sharing code, many users are sharing code. Loading such code twice could result in silly errors I want to avoid.
On the other side, your comment shows that there is also a name aliasing problem. As a matter of fact, the same library could be
referred by /home/user/common/lib1 and /common/libs/libx (e.g. by a link). I have no intention to define a solution for this. Any
capability to detect such cases would be major effort I don't want to spent...
> My general comment is that you propose not only 1 solution to specify the
> object or source
> code but 3 solutions which can be intermixed. Why does the user need 3 of them?
> it adds flexibility but complexity. Why not just enforce 1 of them. That
> makes it
> easier for the vendor and for the user. In fact you want 1 standard way.
I think I have to agree, at least mostly. There is some background required on this ...
- I want to have a solution that is common for all SystemVerilog applications from all vendors. So I can use the same integration
method for all simulators and any user knows how to include his Foreign Language Code. This makes it easier to switch tools,
requires less learning and training for the users and do such enhance the competition between vendors.
- From my history as one of the architects of the Motorola SPS wide design system I am aware of many problems that are caused by
the limited flexibility for integrating this code. As such I have designed in the flexibility that I wished I have seen by all
applications in the past.
- So yes, I want to have _one_ common solution, that has _three_ viewpoints; and these viewpoints are the viewpoints of the
different users I have seen in the past:
a) A third party want to integrate Foreign Language Code. This use case is covered by the bootstrap file approach (as you also
described below). It is the most natural solution.
b) A project team that specifies a common, standard set of Foreign Language Code; this set might change, dependent on technology and
related info selection, selected cells, backannotation data, whatsoever. As a result there is often a set of scripts wrapped around
the invocation of the actual tool that (pre-)defines the correct selection for those settings. This use case is covered by providing
a set of switches to pass the required information set. I think this is the most natural solution for this use case.
c) A user that wants to switch between selections or stitch in additional code; especially in cases where the wrapper scripts (see
above) do not permit additional settings or changing the scripts would require some major hassles on the user side. This use case is
covered by the environment variable approach; clearly limited by making environment variables the last resort (which is another
result of bad experiences in my history).
Hope this explains why I think this amount of flexibility is required.
> I would prefer the bootstrap file approach because this is the way that a
> 3rd party can
> deliver and package directC code for another user. The 3rd party will
> provide the bootstrap
> file as part of the directC delivered code. If other methods would be
> chosen, the only way to
> specify them would be to provide it in the documentation. Instead the
> directC code
> delivered provide a self contained file for using it.
Mostly agreed. By when it is required to wrap a SV application by a set of scripts and those scripts do select a varying set of
Foreign Language Code, then a single solution using a bootstrap file approach would require to always write a differing set of
bootstrap files. Some people will see this as overhead, risky (how to avoid/handle file overwrites, assert the integrity between
creation and consumption by the application) or simply file system cluttering ...
> Francoise
> '
>
> At 10:24 PM 1/27/2003 +0100, Michael Rohleder wrote:
> >Hi all,
> >
> >please find below the updated proposal for the inclusion of C/C++ code. As
> >requested in the last meeting, I have split it into two
> >parts: Object Code inclusion and Source Code inclusion. The result
> >consists now of three parts:
> > . a common introduction
> > . the part about Object Code inclusion
> > . the part about Source Code inclusion
> >[the rationale behind this organization is that the addition of a PLI/VPI
> >inclusion mechanism as requested in the meeting could be
> >easily accomplished as third part, with only minor changes to the
> >introduction]
> >I have further added a complete set of switch settings for all environment
> >variables (as requested by Joao) and further provided a
> >mechanism to disable the usage of environment variables. Change bars are
> >used to show all modifications. Since I have done some
> >restructuring in the switch/variable parts of the source code part, there
> >are a lot of changes in this part ...
> >
> >Have fun reviewing!
> >
> >Best 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 28 2003 - 07:54:13 PST