Correction to minutes, meeting reminder and homework

From: Brian Bailey <brian_bailey_at_.....>
Date: Wed Feb 23 2005 - 09:10:48 PST
        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
Received on Wed Feb 23 09:10:51 2005

This archive was generated by hypermail 2.1.8 : Wed Feb 23 2005 - 09:11:09 PST