Subject: RE: [sv-cc] Further comments on Novas proposal
From: Bassam Tabbara (bassam@novas.com)
Date: Sun Dec 07 2003 - 10:22:49 PST
Thanks Doug for the detailed proof-read, some comments below.
> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> Behalf Of Warmke, Doug
> Sent: Saturday, December 06, 2003 4:17 PM
> To: sv-cc@eda.org
> Subject: [sv-cc] Further comments on Novas proposal
>
>
> Team,
>
> Here is another round of comments from our VPI expert
> on Novas' proposal.
>
> Regards,
> Doug
>
> Page 4
>
> End of section 29.3.2:
> "A collection objects" --> "A collection object"
Ok.
> Page 5
>
> End of section 29.3.2.1
> "This methods are" --> "These methods are"
Ok.
> "to applying vpi_control()" --> "to applying vpi_control()
> or vpi_goto()"
No, vpi_goto() cannot be applied on a single trvsObj so the sentence is
correct as is.
> Section 29.4 diagram:
> Using the VPI object model diagram rules, the names in the ovals
> should be:
> nets
> net array
> regs
> reg array
> variables
> memory
> primitive
> primitive array
Ok.
> Has "concurrent assertion" been defined as a VPI type yet?
It should be, it is in the SV VPI extensions we are working on, but
anyway this is a "placeholder".
> Should "memory word" be added to the diagram or should "memory"
> be removed since I think the task force wants to
> deprecate memories
> in favor of arrays?
VPI extensions have "memory", we should update both if needed.
> vpiTrvsObj does not need to be specified for the iterator arrow
> because that's implied by the name "trvsObj" in the oval.
It doesn't hurt to be clear.
> Page 6
>
> Figure 29-3 - I still think the iteration arrow should go from
> objCollection to traversable and another one from trvsCollection
> to trvsObj.
I followed the way VPI diagrams are drawn (arrow only from the class
name on the top).
> Table 29-1
> First entry - "Create iterator" --> "Create an iterator"
> "Extend with" --> "Extended with"
> Second entry - "Add a new types" --> "Add new types"
Ok.
> Page 8
>
> Two paragraphs above 29.7.2:
> "entry point for the give tool" --> "entry point for the tool"
Ok.
> Page 9
>
> Table 29-3 - "for obtaining handle" --> "for obtaining a handle"
> Also, make the table a little wider to avoid the bizarre
> wrapping of vpi_handle_by_multi_index().
Ok.
> Page 11
>
> Paragraph above 29.7.4.1
> "an initial vpi_control() to" --> "an initial vpi_control() or
> vpi_goto() to set"
Same as above for a single trvsObj can only call vpi_control().
> Page 12
>
> Section 29.7.4.2
> "time0" --> "time 0"
Ok.
> Page 14
>
> First (non-code) paragraph:
> Put a space between collection and loadCollection.
> "is allowed in tool" --> "is allowed in the tool"
> "to create iterator" --> "to create the iterator"
> "and then use vpi_scan()" --> "and then using vpi_scan()"
> "tool allows provides" --> pick either allows or provides
Ok.
> Second paragraph:
> "and may be its sub-scopes" --> "and maybe its subscopes"
Ok.
> Page 17
>
> vpi_control() - Under Related routines there is an extra "only"
> in the sentence.
Ok.
> Page 20
>
> Under Related routines there is an extra "only" in the sentence.
Ok.
This archive was generated by hypermail 2b28 : Sun Dec 07 2003 - 10:23:38 PST