Re: Updated doc

Hi,

Here are my answers to the review questions from Changes.doc:

Section 4.0 page 24
JS raises an issue related to portability and conformance. Resolution required.

 >>>>> The paragraph should only need minor clarification to satisfy the
 >>>>> complaint from John.  The pipes interface is intended to be specified
 >>>>> such that it can be implemented over pure DPI and an application
 >>>>> should then be portable provided a pipes implementation is available
 >>>>> on the platform.

Section 4.7.3 page 34
JS proposes updating the examples to be P1800 compliant

 >>>>> Yes/agreed.

Section 4.7.3 page 34
JS proposes removing reference within P1800

 >>>>> Yes/agreed.

Section 4.7.3 page 35
JS proposes changing return type to int as per P1800

 >>>>> Yes/agreed.

Section 4.7.4 page 35
JS proposes wording change

 >>>>> Yes/agreed.

Section 4.7.7 page 36
SM proposed typographic corrections

 >>>>> Yes/agreed.

Figure 4.9 page 37
SM proposes changing incorrect function call

 >>>>> Need more clarification from Shabtay as to what problem he is seeing.
 >>>>> The code snippet looks OK to me.

Section 4.8.1 page 38
SM proposed clarification

 >>>>> No/disagree.

Section 4.8.1 page 39
JS proposed wording changes

 >>>>> Yes/agree.

Section 4.8.2 page 39
SM proposes removal of this section
JS proposes making it blue italics

 >>>>> Agree with Shabtay to remove section 4.8.2 and 4.8.3.
 >>>>> We can put the section in a separate IM document for future reference
 >>>>> if needed.

 >>>>> Actually, it is not clear which section Shabtay is proposing to
 >>>>> delete.  Is it 4.8.2 or 4.8.3?

Section 4.8.3 page 40
JS, SM Proposed changes, deletions and additions

 >>>>> Shabtay proposes deletion according to the way OpenOffice presents
 >>>>> the marked up document to me.

 >>>>> I'm not sure I agree that we need to explicitly state as part of
 >>>>> the normative spec that the pipes interface *can* be implemented
 >>>>> over DPI.  That paragraph is written as an attribute of the spec,
 >>>>> not a requirement.  In any event, it is a meta-requirement, i.e.,
 >>>>> a goal for the spec we developed.  So, we set out to define a
 >>>>> spec where that meta-requirement would be true.  In a sense, this
 >>>>> makes the paragraph redundant in the normative section.

 >>>>> I propose to collect all the meta-requirements and state them
 >>>>> crisply in section 4.

 >>>>> I also see the proposed added paragraph from John as a meta-requirement
 >>>>> because it talks about multiple implementations.

Section 4.8.3.1 page 41
SM states that this section needs to be rewritten. Proposal required

 >>>>> Need to see proposal first.

Section 4.8.7 page 43
SM proposes deletion of text

 >>>>> I don't see a section 4.8.7.

Section 5.7 page 91
SM proposes changing API to Interface throughout this section

 >>>>> Why? Need clarification as to reason.

Section 5.7.2.2 page 94
SM proposes making section blue italic

 >>>>> Blue italics will be trimmed from the final document.  I
 >>>>> don't see the need.  Either remove the text, convert it to
 >>>>> a note, or keep it as is.

Section 5.7.4.1.1 page 96
SM proposes removal of section

 >>>>> Yes/agreed.  However in the code above the section, remove
 >>>>> the line that says `<implementation goes here>'.

Section 5.7.4.1.1 and 5.7.4.2.1 page 97
SM asks for clarification on flush and EOM flag

 >>>>> I think Shabtay's understanding is correct.  But the sentence
 >>>>> he commented on does not state that flush adds an EOM marker.
 >>>>> It is referring instead to EOM flags causing flushes in auto
 >>>>> flush mode.

 >>>>> I think the `same as above' comment in 5.7.4.2.1 refers
 >>>>> to the removal of section comment in 5.7.4.1.1 in which
 >>>>> case I agree as for section 5.7.4.1.1.

Section 5.7.5.1.1 page 101
SM proposes deletion of text

 >>>>> Yes, make it a note.

Section 5.7.5.1.1 page 102
SM says needs to change with IM304

 >>>>> Yes/agreed.

Section 5.7.5.1.4 page 106
SM proposes deletion of section

 >>>>> Note sure what section Shabtay is proposing to remove.

Section 5.7.5.3 page 106
SM says clarification necessary

 >>>>> For the blocking calls, data must be provided for the HDL
 >>>>> side to resume, right?

Section 5.7.4.4 page 107
SM proposes making informative

 >>>>> Yes, either that or move it to section 4 as part of the use
 >>>>> case discussion.

Section 5.7.5.4.1 page 108
SM proposes moving section to become section 4.8.8

 >>>>> Yes/agreed.

Thanks,
Per <per.bojsen@amd.com>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.