Subject: Re: [sv-cc] Update on inclusion doc
From: Francoise Martinolle (fm@cadence.com)
Date: Tue Feb 18 2003 - 08:46:29 PST
I think we need to vote on this.
I like the fact that the directC interface is standardizing on a methodology to bring
and integrate directC shared libraries but I don't want to force in the standard a methodology for bringing in directC source code. I think there are two many issues associated with compiling linking C and C++ code
which cannot be solved in a small amount of time by this committee.
Francoise
'
At 04:06 PM 2/18/2003 +0100, Michael Rohleder wrote:
Thanks Doug, this was a good reminder that I better close this issue now ...
Since I have not heard any more feedback since then I would like to formally sign off these documents to Swapnajit for
inclusion in the next draft. I am unsure whether we need a vote on this, so this is up to the decision of Swapnajit/the team.
Attached you'll find three attachments a) the introduction b) the inclusion of object code c) the inclusion of source code.
All parts are basically unchanged; the only two changes I did was i) to remove the third part (PLI/VPI registration)
as decided by the team in the conference call Feb 5th and any references to this part and ii) the two statements forbidding
other extensions as requested by Joao.
Best regards,
Michael
"Warmke, Doug" wrote:
> Michael,
>
> Thanks a lot for doing all this work.
> I think parts 1 and 2 are good and are pretty
> much ready for inclusion into the LRM.
>
> Is the "excerpt from an internal document" that last
> attachment regarding the potential IP directory structure?
It is part of one directory structure we are using / have defined within Motorola. I am still extremely hesitant to standardize any
kind of directory structure.
> Francoise,
>
> In our face-to-face, you mentioned that you had a lot of
> experience with the complexities of supporting a source-based
> C/C++ code inclusion system. It would be great to see some
> "Francoise questions and issues" mail on this topic. We could
> all learn from your experience.
Yes, I would also appreciate this.
> Thanks and regards,
> Doug
>
> > -----Original Message-----
> > From: Michael Rohleder [mailto:michael.rohleder@motorola.com]
> > Sent: Wednesday, February 05, 2003 8:49 AM
> > To: SystemVerilog CC DWG
> > Subject: [sv-cc] Update on inclusion doc
> > Importance: High
> >
> >
> > Hi all,
> >
> > as proposed here is the update on the SW inclusion document. Updates:
> > - Removed env var features, as requested by the team (all parts)
> > - Describes the intention, as requested by the team (intro)
> > - Shows some of the possible use case to give some reasons
> > for the amount of flexibility needed (intro)
> > - Makes the actual switch names no longer mandatory, but
> > recommended, as requested by Francoise (intro)
> > (if EDA vendors want to use this to distinguish them from
> > others, fine with me ...)
> > - Current working directory is default, if no -sv_root
> > switch given (intro)
> > - Permits now only shared libraries (archives are no longer
> > possible), as requested by Francoise. (part1)
> > - Clarified on the responsibility to provide correct on
> > complete data (part1), requested by Doug
> > - Added a recommendation on how to handle unreferenced code
> > (part1), requested by myself
> > - Fixed some errors in the examples
> > - Part 2 is mostly unchanged
> > - Part 3 is now added for DISCUSSION PURPOSES _only_. Just
> > want to find out what the team thinks about it. You tasked me
> > to do this, now tell me whether it is O.K. to pursue this
> > direction or shut it down ...
> >
> > Open question from my side:
> > - My hope is intro & part 1) is now mostly O.K. ?
> > - Do we want to continue with part 2)
> > - Only issue left with part 2) is how to handle 'generated'
> > header files included in a simulation
> > - Is part 3) something we want (I will show some problems in
> > the conf call) or should we just kill it.
> >
> > Remaining things left:
> > - Inclusion of .o stuff as requested by Andrzej ->
> > since Francoise had some _very_ good points to remove .a,
> > I _hope_ this is no longer required ...
> > - Definition of associations with C source and VL code as
> > requested by Andrzej ->
> > I am still VERY hesitant to do this. This would be open up
> > a can of worms ...
> > But I have added some excerpt from an internal document
> > that shows how this could be done as requested in the
> > previous call. I had to remove a lot to not exhibit internal
> > information, but I think you get the scheme ...
> >
> > Best regards,
> > Michael
> >
> >
> >
> >
> > --
> >
This archive was generated by hypermail 2b28 : Tue Feb 18 2003 - 08:47:29 PST