RE: Streaming, batching, concurrent and alternating

Russ,

 

My comments below.

 

________________________________

From: Russell Vreeland [mailto:vreeland@broadcom.com] 
Sent: Tuesday, June 21, 2005 11:51 AM
To: Shabtay Matalon; bojsen@zaiqtech.com
Cc: itc@eda.org
Subject: RE: Streaming, batching, concurrent and alternating

 

 

[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] I agree that determinism should be the default. Alternating
mode is also deterministic by definition as you stated and thus I
proposed that it should be the default. I think we should have further
discussion on "streaming being implemented right" when we drill into
more detailed discussion at the committee. You indicated for example
that you need a threading package to make it deterministic and we
avoided so far building an interface that assumes the use of threads. I
hope that you can make some suggestions how streaming could be supported
such that that it will be deterministic.

 

[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.

[Shabtay] The scenario that you described illustrates the importance of
"reactivity control" that I described in the paper. In the scenario that
you have presented, the end user should not modify the default setting
of the channel as using a reactive test on a "batched" channel can yield
a dead lock. On the other hand, it's quite possible that the software
side monitors certain interfaces independently wrt others. Under this
scenario, delayed arrival is acceptable to the test as Per pointed out.

I already agreed with you that the determinism should be the default.
But I don't think that it will satisfy end user performance goals if
SCE-MI will be unnecessarily constrained. Many testbenches are either
not fully reactive and some are even non-reactive at all.  I thus think
that it is important that we provide the "knobs" to users to obtain
higher level of performance knowing the characteristics of their
specific test environment. While we do that, we should also make sure
that modelers who create transactors for both simulation and
acceleration mode are not negatively impacted due to these performance
optimizations. Batching allows for performance optimization and yet
doesn't impede on the portability of transactors from simulation to
acceleration and from once accelerated environment to another.

Let me know if you disagree with this.

 

  
  
  
> 
>Per 
> 
>