Stu,
I looked this over. Since I am a PLI ignoramous, I just have minor editorial
comments (some are leftovers from original text):
It looks like you prepared this from old versions of sections 20 and 21.
1. The word 'section' should be 'clause'.
2. When referring to a sub-clause, such as 10.2, one does not use the word
'clause', but just the number, such as "refer to 10.2".
3. In 20, para. 1, "currect" should be "current".
4. In 20.4, para. 1, 2nd sentence should end with a verb, such as "do".
5. In 20.4, para. 4, 2nd sentence, delete comma after "HDL".
6. In 20.7 and elsewhere, quotation marks in code should be plain straight
up and down, instead of 'smart', slanted marks.
7. In 20.8, para. 1, delete comman after "include files".
8. In 21.1.1, sentence 1, "functions to be defined" should be "can be
defined" or "may be defined"?
9. 21.1.2 should precede 21.1.1, since elsewhere compiletf precedes calltf?
10. In 21.1.14, line 5, "or a net" should be "on a net"?
Thanks,
Shalom
On Wed, 24 Nov 2004, Charles Dawson wrote:
> From: "Stuart Sutherland" <stuart@sutherland-hdl.com>
> To: <chas@cadence.com>
> Cc: <sv-cc@server.eda.org>
> Subject: Proposal to (almost) deprecate TF and ACC routines
> Date: Wed, 24 Nov 2004 07:16:02 -0800
>
> Chas.,
>
> I have had an action item for some time to review and modify the proposal
> for deprecating the TF and ACC routines from the 1364 standard. If it isn't
> too late, here is what I came up with...
>
> Stu
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> Proposal to (almost) deprecate the old PLI TF and ACC libraries.
>
> Background: The 1364 PLI task force approved deprecating the older TF and
> ACC libraries. However, the limited scope of the new P1364-2005 PAR, along
> with concerns about completely deprecating TF and ACC that have been
> expressed within the P1800 working group, may prevent this happening for the
> P1364-2005 standard. This proposal removes the old TF and ACC libraries
> from the main body of the 1364 LRM, but does not fully deprecate them from
> the 1364 standard. Instead, the proposal moves the sections on the TF and
> ACC routines to the annexes of the LRM, but keeps them as a normative part
> of the standard. By moving the older routines to the annex, the P1364-2005
> LRM will emphasize that the VPI is the primary Verilog procedural interface,
> and the older routines are included for documentation.
>
> The changes are:
>
> Copy Section 21, PLI TF and ACC interface mechanism, to Annex F
> Move Section 22, Using ACC routines, to Annex J
> Move Section 23, ACC routine definitions, to Annex K
> Move Section 24, Using TF routines, to Annex G
> Move Section 25, TF routine definitions, to Annex H
> Move Section 26, Using VPI routines, to Section 22
> Move Section 27, VPI routine definitions, to Section 23
> Move Annex E, acc_user.h, to Annex L
> Move Annex F, veriuser.h, to Annex I
> Move Annex G, vpi_user.h, to Annex E
>
> Changes to Section 20:
> A modified section 20 with the changes highlighted is attached as
> new_section_20.pdf.
>
> Changes to Section 21:
> A modified section 21 with the changes highlighted is attached as
> new_section_21.pdf.
>
> Changes to Section 26 (new section number is 22)
> Delete all of subsections 26.1 and 26.2 (these topics are covered in the
> new section 21).
>
>
> When these changes are completed, the new chapter/annex order and names will
> be:
> Chapter 20: PLI overview
> Chapter 21: PLI VPI interface mechanism
> Chapter 22: Using VPI routines
> Chapter 23: VPI routine definitions
> Annex E: vpi_user.h
> Annex F: PLI TF and ACC interface mechanism
> Annex G: Using TF routines
> Annex H: TF routine definitions
> Annex I: veriuser.h
> Annex J: Using ACC routines
> Annex K: ACC routine definitions
> Annex L: acc_user.h
-- Shalom Bresticker Shalom.Bresticker @freescale.com Design & Verification Methodology Tel: +972 9 9522268 Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890 POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478 [ ]Freescale Internal Use Only [ ]Freescale Confidential ProprietaryReceived on Sat Nov 27 10:20:49 2004
This archive was generated by hypermail 2.1.8 : Sat Nov 27 2004 - 10:21:12 PST