RE: Streaming, batching, concurrent and alternating

Shabtay,

It's late but I have a few terse comments to try to answer your last two
emails.

1) "Determinism between pure HDL runs on VCS/MTI/IUS does not even exist as
each vendor only managed to achieve high level of determinism in their space
but not among their simulators"

I find that very surprising. The last time I saw a non-deterministic
simulation/emulation run was at least as far back as 2001. I have seen the
common race condition error of the indeterminate order of evaluation of
parallel same delta cycle events which can change simulation results when a
re-elaboration occurs -- these are not really non-deterministic; the sims
are repeatable as long as the snapshot is not re-elaborated. We have some
fairly simple rules for using SCEMI 1.1 deterministically and these have
been foolproof. We don't try streaming (but have thought a lot about it)
because the performance gains that come from it are generally overrated
except in certain, well, "streaming" scenarios (lots of audio, video, etc.
being streamed through a chip). 

But generally speaking, determinism exists, is alive and well at BRCM. We
wouldn't want to live without it.

2) "I would like to learn more from you Russ how you see this free running
streaming working"

Streaming and free running don't intersect. Streaming by my definition is
achieving a certain measure of concurrency limited by the need to preserve
determinism. Streaming must be deterministic. Free running is almost always
non-deterministic.

3) > a. Determinism - I think we'll need to decide an acceptable 
> level of determinism in each as absolute determinism is not 
> existent. 

I disagree. We commonly do emulation runs that take days to complete. Bugs
are found, sometimes after many quadrillions of clock cycles. To trace on
the bug, we have to repeat the emulation run. Without absolute determinism,
our debug methodology would not work.

4) > I suggest that you take the time to understand the batching 
> knob proposal.  I think that you have established an opinion 
> prematurely.

I don't think so. I can completely understand the rationale for batching. My
take on it is this: if batching is to be done in a concurrent mode of
execution, then batching is synonymous with streaming (ruling out
non-deterministic batching as anathema to our goals). We should provide a
streaming capability, even if it's usefulness is (I believe) overrated. If
it is to be done in an alternating mode of execution, then batching is one
or many zero-time transfers (definition of alternating). These are best left
to the infrastructure generator of the particular vendor's tool, to
determine the optimum performance, and should be invisible to the user. I
can't think of a scenario where providing user control for this would
outweigh the negative effects of moving away from the goals of simplicity,
ease-of-use, and a high level of abstraction. You may disagree, but having
users twiddle with how the infrastructure should move data is a low-level
user interface.

 I do agree that we have perhaps exhausted this stream of emails on these
related subjects for now, and a working group discussion might be a better
next step.

---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------



> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf 
> Of Shabtay Matalon
> Sent: Wednesday, June 22, 2005 4:23 PM
> To: Bojsen, Per; vreeland@broadcom.com; John Stickley
> Cc: itc@eda.org
> Subject: RE: Streaming, batching, concurrent and alternating
> 
> 
> Russ, 
> 
> Maybe instead of continuing with this stream of emails, we 
> should each take some time to make sure that we understand 
> each other positions.  I admit that I don't understand yet 
> how can you build "true streaming mode" (for example by Per's 
> definition) with emulation finite speed and memory resources. 
> I asked for some clarification in my pervious email.
> 
> I suggest that you take the time to understand the batching 
> knob proposal.  I think that you have established an opinion 
> prematurely.
> 
> I actually think that my batching proposal can serve your 
> streaming requirements such that it becomes as sub-mode in 
> the concurrent execution model. I also think that users who 
> wish to use only an alternating execution model should not be 
> precluded from using fifos. 
> 
> We need to review both proposals along the following two 
> important criterions
> 
> a. Determinism - I think we'll need to decide an acceptable 
> level of determinism in each as absolute determinism is not 
> existent. b. Reusability of transactors - The most important 
> criteria is ease of modeling and reuse of transactors from 
> simulation to acceleration.
> 
> Maybe a working group session at the committee can address that.
> 
> Shabtay
> 
> 
> >> I think you'll agree that once the mechanism introduces *actual* 
> >> non-deterministic behavior, then the free-running use model may as 
> >> well be used?
> >
> >If by actual non-deterministic behavior you mean behavior that it is 
> >impossible for the user to constrain to become deterministic 
> no matter 
> >what he does, then I would agree.  But I don't see Shabtay's 
> batching 
> >`knobs' being in this category except perhaps for the 
> free-run switch 
> >(was it you or Shabtay that first introduced that?).
> >
> >Per
> >
> >--
> >Per Bojsen                                Email: 
> <bojsen@zaiqtech.com>
> >Zaiq Technologies, Inc.                   WWW:
> http://www.zaiqtech.com
> >78 Dragon Ct.                             Tel:   781 721 8229
> >Woburn, MA 01801                          Fax:   781 932 7488
> >
> >
> 
> 
>