Subject: [sv-cc] RE: Version 2 of DPI LRM
From: Warmke, Doug (doug_warmke@mentorg.com)
Date: Tue Mar 11 2003 - 13:05:44 PST
Team,
Forwarding John's review of the C-side LRM to the reflector
(since at least this email won't get swallowed into a black hole).
John, Andrzej - note that John's first comments are addressed
at Andrzej's portion of the C-side LRM, I have no feedback to
give on this topic and I hope Andrzej can respond to John's
comments below.
All,
I know it's a lot to ask, but I do encourage all of you to read
the LRM edits I made over the weekend. I think a lot of the
confusion might be cleared up if you look at the distillation
of the "gnarly thread" that I made. In particular section A.8
of the C-side LRM will be a useful starting point for further
debate. If anyone on the reflector who cares about these edits
didn't receive them already, let me know and I will send them
separately. The reflector can't handle the attachment size.
Actually, all of Joao's proposal is already in those rev2 LRM
drafts I sent out. Whatever new things he adds on to the
proposal could be easily incorporated.
Once Swapnajit gets the eda.org IT team to lift our size
restriction on attachments, we will all be able to work
together a lot more efficiently.
Thanks and regards,
Doug
> -----Original Message-----
> From: Stickley, John
>
>
> Doug,
>
> Here's my feedback on the C-layer doc. Again minor because
> I'd read it all before except for the new section on context.
>
> --------------------------------------------
> A.7.1 Overview - 3rd paragraph
>
> I'm a little confused by the wording of this. If applications
> access packed arrays directly using implementation specific
> representation, is it not also source compatiblity that
> compromised as well ?
>
> Perhaps here we should make it clear that source
> compatability is compromised in addition binary compatibility.
>
> I understand that if all access is done using the access
> functions in section 10 for individual elements then it is
> still source compatible. But the wording of this implies
> direct access of the implementation specific representation
> without using any functions but rather vendor specific data
> types used in implementation. Was that your intent here ?
>
> If you meant to imply the access functions should be
> used you should probably have a forward reference
> to section 10.4 through 10.6.
>
> --------------------------------------------
> A.8 Context
>
> This section is superbly worded. You really captured
> the issues we've been discussing and have articulated
> them very well. As I read through it, the concepts
> flowed clearly and concisely. I think new readers will get
> the picture immediately when they read this and not
> have to deal with the same gnarliness we did !
>
> --------------------------------------------
> A.9.3 Example 2
>
> Looks like there's a typo in this example.
>
> It shows the export function as this:
>
> export "DPI" function $root.exported_sv_func;
>
> With our latest syntax it should simply be this:
>
> export "DPI" exported_sv_func;
>
>
> --------------------------------------------
> A.9.4 Example 3
>
> Export declaration should be the same as shown above.
>
>
>
> Warmke, Doug wrote:
> > Team,
> >
> > I can't stand waiting around for the SV-CC reflector to
> finally send
> > you my LRM edits. So here they are, addressed individually to the
> > committee members who have been actively involved in the debates (I
> > calculated this list by looking at emails, and looking at
> who voted on
> > Joao's proposal.) Hopefully I didn't forget anyone, and hopefully I
> > can get these files out on the main reflector soon.
> >
> > Swapnajit,
> >
> > Can you please find out the limit for sending around files? For big
> > files, is there any kind of ftp site or alternative to email
> > available?
> >
> > Andrzej,
> >
> > Could you please confirm that you received the Frame
> sources for these
> > documents? (They might make more sense after you read my
> introductory
> > email which was swallowed by the reflector along with the .pdf
> > attachments...)
> >
> > Thanks and regards,
> > Doug
> >
> >
> >
>
>
> --
>
> This email may contain material that is confidential,
> privileged and/or attorney work product for the sole use of
> the intended recipient. Any review, reliance or distribution
> by others or forwarding without express permission is
> strictly prohibited. If you are not the intended recipient,
> please contact the sender and delete all copies.
> __
> ______ | \
> ______________________/ \__ / \
> \ H Dome ___/ |
> John Stickley E | a __ ___/ / \____
> Principal Engineer l | l | \ /
> Verification Solutions Group | f | \/ ____
> Mentor Graphics Corp. - MED C \ -- / /
> 17 E. Cedar Place a \ __/ / /
> Ramsey, NJ 07446 p | / ___/
> | / /
> mailto:John_Stickley@mentor.com \ /
> Phone: (201)818-2585 \ /
> ---------
>
This archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 13:07:08 PST