Pipe proposal feedback

Hi all,

 

Here is my $0.02 with respect to PIPEs from the last few meetings (with
the exception of last week, when I was away).  Given this topic is still
active, I wanted to provide some feedback.

 

            - Bryan

 

------------------------------------------------------------------------
------

 

Regarding these various PIPE modes & discussion, here is my opinion
(unfortunately it was difficult to break into the conversation):

 

1.	There should be a query available to the user for model
capabilities (including valid PIPE modes)
2.	PIPEs should at least have the following configuration options:

	a.	 Mode:

                                                               i.
Streaming 

                                                             ii.
Reactive (based on EOM)  aka debug1 

                                                            iii.
Reactive (based on a per-call mode) aka debug2 

	b.	H/W depth of the pipe - since this needs be compiled
	c.	H/W max width of the pipe - since this needs to be
compiled

 

Q:  Is the EOM flag required or optional?  I assume models can opt to
use it or embed model specific flags in their data elements

 

3.	Pipe configuration options can *only* be set at init time ie.
the 'mode' of the pipe cannot be flipped at runtime (unknown side
effects)

	a.	It would be useful to have the ability to set *all*
pipes to the same mode (from the TB) - eg. via a static class variable 
	b.	Additionally, have the ability to override the global
pipe mode on a per pipe basis (more rare - user tweaking if required)
	c.	Note:  Data shaping & S/W depth x width can be
configured any time

 

4.	Pipe Mode default - ' streaming'.  If not I envision the
following issues:

	a.	If one PIPE is set to reactive, this may adversely
affect the performance of the testbench (if that pipe is used
frequently)
	b.	If reactive is the default, there is a concern that
modelers will only build models to work in that mode (and  will have no
incentive to fully support streaming)
	c.	Reactive mode should be used for debugging and bring up
generally.  If there are problems in streaming, this can be a 'safe'
fallback mode until a solution found
	d.	Streaming mode is the desired mode to run with the
accelerator (or else we are wasting precious resources).  We have a
strong desire to maximize efficiency and minimize switching between S/W
& H/W (which is costly in terms of time)
	e.	All models *should* flush if they are aware that the
last element is sent (that guarantees it will work in both streaming and
reactive modes).  That should be a base recommended rule and a safe
practice.

 

5.	Simulation vs Acceleration 

	a.	For basic simulation, we may set the PIPEs to either
streaming or reactive.  We would use streaming when we want to: 

                                                               i.
Run the simulation more efficiently (ie. switching over DPI/PLI vs the
simulator).

                                                             ii.
Ensure that that streaming TB works before going to the accelerator
(generally:  the accelerator/emulator is a shared resource, so we need
to minimize the time we spend on it 'debugging' models & the
environment.  As a result, we want to debug as much as possible under
simulation (ie. support streaming under simulation).

	b.	Reactive should be a fallback mode or during pure
simulation when simplicity is best or for debugging.