RE: My AI's from 7-9-09 Meeting

Reg'd IM 315 --  I thought the committee agreed to work to close this one by editing out mentions of any "task" syntax?

If not, I'd like to raise the issue again to advocate supporting functions only, for reasons of clarity. Since DPI code is not supposed to be time-consuming it makes little sense to allow "tasks" to be defined.


---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com<mailto:vreeland@broadcom.com>        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------

________________________________
From: owner-itc@server.eda.org [mailto:owner-itc@server.eda.org] On Behalf Of John Stickley
Sent: Thursday, July 23, 2009 6:16 AM
To: 'itc@eda.org'
Subject: My AI's from 7-9-09 Meeting

ITC-Techies,

As per my AI's from the July 9th meeting, I've listed
the current list of pending IMs for the 2.0 draft
and Mentor's recommendation for actions on them:

- 304, 319
  - Move to vote in mid-august as planned.

- 318
  - Move to vote in mid-august - This IM is basically a simple
    correction of the eom_set_auto_flush call. However, I
    also edited it to combine with 322 which makes it an error
    if eom_set_auto_flush() is called on a non-empty pipe.
    I've updated the document for this IM accordingly.

- 322
  - See above. We'd like to amend this to say if eom_set_auto_flush()
    is called on a non-empty pipe it is an error.

- 323
  - I suggest we remove since document is empty and it seems related
    to 318.


- 311
  - Defer to 2.1 for improved wording - Mentor disagrees with
    current wording for pipe determinism for reasons stated
    in our previous comments for this IM.

- 313 - Defer to 2.1
- 315 - Defer to 2.1
- 320 - Defer to 2.1

+ IM 314
  - Move to vote on in mid-august. This is just an improved example
    for time access and should raise no issues.

+ IM 302
  - Move to vote in mid-august.

Also, another AI I had from last week was to go back in and look
for text specifically allowing de-registering of notify callbacks
(i.e. to support "sticky" semantics for notify callbacks).

Indeed it looks like Shabtay had an IM suggesting we allow
de-register of notify callback by passing a NULL but it was
moved to the SCE-MI 2.1 list for some reason. I also remember
Per Bojsen bringing this up for discussion. Mentor recommends
we should put put this back in 2.0 list and coming up with specific
text updates to spec, and putting up for vote.

-- johnS


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.                      /\_/  K2  \_    \_

______________________________/\/            \     \

John Stickley                   \             \     \

Mgr., Acceleration Methodologies \             \________________

Mentor Graphics - MED             \_

                                    \   john_stickley@mentor.com<mailto:john_stickley@mentor.com>

                                     \     Phone: (201) 467-4385

________________________________________________________________

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

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