[Shabtay] >Do you both agree that using "concurrent" as the reciprocal to alternating is a better name? No. I prefer talking about deterministic vs. non-deterministic. Alternating is by definition deterministic, but "concurrent" can be either. If "streaming" is implemented right, some concurrency can be achieved and it will still be deterministic. Determinism is the key distinction. Also, we agreed for SCEMI 2.0 that determinism would be the default (unlike SCEMI 1.1 where the user must take care to design the appropriate clock control to get it). [Shabtay >Correct. Assume that a cycle stamp defines the time a message is delivered. Or even assume that the message embodies various cycle stamp values read explicitly by means that the infrastructure provides. The end user may determine the level of batching required by its testbench environment for output messages on a given interface (same may apply on the producing side). The messages will arrive on each channel in order, but multiple output messages will arrive at the same time, each message with continuously increasing cycle stamp values. In SCE-MI 1.1 this is not allowed. You can get into serious trouble batching output messages from different times (cycle stamps) for delivery. Suppose output message A is produced at cycle stamp N and is batched with output message B at cycle stamp N+1000. If follows that the "batched" output message isn't sent over to sw until at least N +1000 (causality). Now, suppose sw has an algorithm where when it receives an output message A, it needs to send an input message to some other port 500 cycle stamps later. What is sw to do? This system will either be non-deterministic or will be deterministic in an absurd way (where batching introduces delays that aren't present in the real environment). Output messages must get to sw in zero time after they were produced. SCEMI 1.1 is correct not to allow this kind of batching but doesn't go far enough by requiring that hw stop its own clock when output messages are pending. > >Per > >Received on Tue Jun 21 11:51:10 2005
This archive was generated by hypermail 2.1.8 : Tue Jun 21 2005 - 11:51:20 PDT