FW: Correction to minutes, meeting reminder and homework

        
        Brian,
        
        Does it make sense to add the reference implementation issue
        to the list?
        I think this falls under "simulation support"
        
        It sounded like the availability of a reference implementation for
        simulation would increase adoption of the standard and 
        improve interoperability.
        
        Regards,
        Jason
        
         
        
        > -----Original Message-----
        > From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf 
        > Of Brian Bailey
        > Sent: Wednesday, February 23, 2005 9:11 AM
        > To: itc@eda.org
        > Subject: Correction to minutes, meeting reminder and homework
        > 
        >         Hi everyone,
        >             My apologies to Jason Ruthfuss of Verisity for 
        > missing him out of the meeting attendee list.
        >         
        >         Our next meeting is this Thursday Feb 24th and 9:00am 
        > Pacific time.
        > The call in details are:
        >         
        >         From the US 888 742 8686
        >         International 303 928 2600
        >         Conference ID 6249294
        >         
        >         The objective for the meeting will be to do a sort of 
        > the high level requirements into must haves, like to have, 
        > need more information, and shouldn't be considered. In order 
        > to help that process along, I would like each company to go 
        > through the list before the meeting placing the tags that 
        > they think belong on each of the items. This is not a vote, 
        > and so every company has a say in this. Hopefully it will 
        > show those items that we do not need to discuss and allow us 
        > to concentrate on the ones which are marginal or not well
understood.
        >         
        >         Here again is the list:
        >         
        >         .	Encapsulation of the uncontrolled clock
        >         .	Variable length messages
        >         		mechanism for multi packet message at 1 time
        >         		mechanism for pipelined packets over time
        >         .	Random access to data fields
        >         .	Time and non-time consuming methods (0 time
sequential)
        >         .	Backward compatibility and concurrent usage of 
        > 1.0 and 2.0
        > transactors
        >         .	Simulation support should be reviewed
        >         .	Models developed and debugged in simulation 
        > must be movable
        > to emulation without changes.
        >         .	Determinism needs to be addressed - default to 
        > deterministic
        > - need to consider if non-determinism should be allowed 
        > (retained for backwards compatibility)
        >         .	Synchronism: DPI is synchronous but can be made to
be
        > non-synchronous: SCEMI is asynchronous and can be made 
        > synchronous. Which is preferred?
        >         .	Must change the acronym SC(Emulation) no longer 
        > acceptable.
        > Possibly Execution or Engine
        >         .	Ability to get multiple messages in zero time 
        > without having
        > to deal with uncontrolled time
        >         .	Solutions should not preclude optimizations for 
        > performance
        >         .	No extensions must break 1.0 semantics 
        > (stronger form, all
        > new semantics should be definable with combinations of old
semantics)
        >         .	Upgrading of models must be easy
        >         .	Streaming mode should be included
        >         .	Synchronization to (not just "support for") 
        > multi-threaded
        > C++ environments
        >         
        >         Thanks
        >         Brian
        > 
        >