RE: Pipe proposal feedback

Hi Brian,

 

This is highly valuable input. I have injected my comments in line.

 

Shabtay

 

________________________________

From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf Of Bryan
Sniderman
Sent: Friday, March 03, 2006 11:56 AM
To: itc@eda.org
Subject: 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 

[Shabtay] I agree of course, but I won't call it debug 1. Some
transactors would only work properly in this mode and will break in
streaming mode given the latency introduced. I would simply call it
Reactive mode.

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

[Shabtay] This is good suggestion that could be even used during model
development. I endorse it, but call it Debug mode.

	b.	H/W depth of the pipe - since this needs be compiled

[Shabtay] I raised this point already and others thought it is not
required given that consistency across multiple implementations could be
obtained at flush synchronization points. I am wondering if you see this
as sufficient or not.

 

In addition, as the infrastructure may not be aware of user' transaction
length it should provide the knobs to adjust the H/W depth of the pipe
to squeeze the maximum performance in the context of the user's
application. The pipes proposal only addressed HW depth in relationship
with the largest element which may not be sufficient in my opinion. 

 

However, I am not sure that it is worth the time to define a common
method for setting H/W depth of the pipe. How important it is that we
define a unified way to set this attribute?

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

[Shabtay] I am not sure why you care about width? Can you explain?

 

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

[Shabtay] Users could use model specific flags, but if they do, the
infrastructure won't be able to recognize transaction boundaries and
align HW/SW synchronization semantics around it in Reactive mode.

 

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)

[Shabtay] I think that eliminating mode flipping at run time is an
unnecessary restriction. You could change mode from reactive to
streaming and vice versa w/o loosing data. I haven't looked into it
deeply, but my sense is that even switching to debug mode would be
useful if you wish to debug a long test and not pay a performance
penalty until you reach your debug window. You run in streaming mode and
then flip mode to debug. The consumers will receive bursts of elements
until the mode "settles".

	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)

[Shabtay] Agree with all the above.

	c.	Note:  Data shaping & S/W depth x width can be
configured any time

[Shabtay] Data shaping - agree. What you mean by SW depth x width and
why do you need it?

 

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)

[Shabtay] This is an important point and the main motivation for my
request for implicit synchronizations. Modelers are not required to
build streaming capability into the models. When switching from Reactive
or Debug mode to streaming, the models will stream. The only option that
modelers are granted is to prevent the model from streaming using
explicit flush call that could not be overridden.

	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

[Shabtay] Seems like there was misunderstanding about setting Reactive
as the default. I view default mode as the default bring-up mode.
Nothing should prevent you from bringing up the environment in Streaming
mode by calling 3a as you proposed upon construction.

	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.

[Shabtay] I know we discussed that during the face to face, but this
issue is still open. We concluded that we could not use a single global
flush on both inputs and outputs. What I suggest that we look at placing
to individual global flush calls from the SW side only (meaning
global_flush_input and global_flush_output).  I think we should discuss
that focusing on which conditions should cause the global flush to
return. 

 

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

[Shabtay] I hope that we are all in agreement that what you do in
emulation/acceleration mode, you can do in simulation. This included
simulating steaming mode. Nothing in the spec should preclude that
option.

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

[Shabtay] Both reactive and debug mode could be used for debugging. But
this is for global setting. As you proposed per channel control, you
should be able to use any combination as you want. A useful example is
CPU that first configures the environment via a reactive bus interface
before running some serial interfaces in streaming mode until the next
configuration change takes place. This will require all the capabilities
I advocated above including changing mode setting during run time.