RE: Streaming, batching, concurrent and alternating

Russ,

 

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

If a user uses those knobs and introduces the slightest indeterminism,
he might as well just put the system in free running mode and forget
about knobs. Wouldn't this be easier for a not fully reactive testbench?

[Shabtay] The only difference is that I'd like to also see queuing
implemented in alternative mode. 

 I'd like to see a knob that puts an interface into a careful streaming
mode that guarantees determinism.

[Shabtay] I have not seen any lack of determinism when queuing is used
in alternating mode. Same transactors could run in both modes and also
in simulation and acceleration mode. Results are consistent. If the user
wants to turn queuing OFF, this could be done even during run time.  

Is a "free running mode" knob something we've overlooked? I've just
assumed the ability to turn off clock control (or the SCEMI 2.0
equivalent of it) but all we've discussed is the knob to turn on/off
streaming for a particular interface suibable for streaming. I would
support this 2nd "knob", but I would contend it would negate the need
for any others.

[Shabtay] Seems like more room for discussion then, as I am supporting a
superset of what you are suggesting.

 Maybe it could be an argument to scemi->Init();

[Shabtay] This is one option. 

  
  
  
  
> 
>Per 
> 
>