Greetings ITC Techies, I would like to send out a quick e-mail just to confirm how many people will be attending the face-to-face next week on Feb. 9th as planned. Please let me know if you plan to attend either in person or by teleconference. Secondly, I've been thinking about SCE-MI 2/TLM compatibility. Since we're somewhat behind schedule from our original 2005 goal to have the SCE-MI 2 standard released I'd like to take a slightly more aggressive posture and suggest that we bundle in some capability for TLM compliance in order to keep SCE-MI 2 fresh and to keep the interest alive. As defined now the pipes are not TLM compliant. Yet they have a fairly strong use model for streaming, variable-length messaging, and data shaping that I don't think we should change as this feature will serve some important application use models that need streaming. However, I'm thinking that in addition to the streaming and variable length message use model we should strongly consider also supporting a fully TLM compliant use model. I realize that this is a new requirement but I'm concerned about the usefulness of the SCE-MI 2 standard if it will not properly support TLM applications. Toward that end, I'd like to put forth a proposal that provides a TLM compliant use model in addition to the streaming use model. This new capability is similar to the pipes capability in that in can be easily built over DPI compliant simulators. But it has some differences in semantics that have to do with supporting non-blocking (but still deterministic) access operations in addition to blocking ones, and supporting user specified buffer depth for batching. More of a fifo model (in the sense of tlm_fifos) than a streaming model. As I said, I don't want to change the streaming use model we've set in place. That is important in and of itself. But I think SCE-MI 2 will be incomplete and will have "missed the boat" if we do not include TLM support. I can have a proposal ready to put on the table next week for the face-to-face if others are agreeable. -- johnSReceived on Mon Jan 30 08:21:20 2006
This archive was generated by hypermail 2.1.8 : Mon Jan 30 2006 - 08:22:13 PST