Re: Pipe proposal feedback

Bryan,

Thanks for your input.

Comments embedded ...

Bryan Sniderman wrote:
> 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

johnS:
I think these could be useful.

I think 2.a.iii. and 2.b. above can be done with the new 
set_buffer_depth() calls I've proposed. In the particular case of
2.a.iii. you'd set_buffer_depth to an amount equal to at least one
message (as per Per's new terminology) worth of buffer.

And I think 2.a.ii. is the new set_eom_auto_flush() proposed call

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

johnS:
Precisely. EOM was always meant to be optional. It is a user aid
to be used as they wish. It avoids the need to add an extra data
flag to your message so that if your message is 64 bits, you don't
have to make it 65 bits and possibly waste another 31 bits of storage
leading to the next svBitVecVal.

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

johnS:
I agree with this.

>          1. 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
>          2. Additionally, have the ability to override the global pipe
>             mode on a per pipe basis (more rare – user tweaking if required)

johnS:
Yes - so long as it also done at init time as you suggested above.

>          3. 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:
>          1. If one PIPE is set to reactive, this may adversely affect
>             the performance of the testbench (if that pipe is used
>             frequently)
>          2. 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)
>          3. 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
>          4. 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)
>          5. 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.

johnS:
Yes I agree we want streaming as the default - for all your
well stated reasons 1-4. And I agree with 5 as a good coding
practice although it is not enforceable by the infrastructure - i.e.
you cannot create a "global flush" for reasons we examined closely
at the face-to-face.

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

johnS:
Well stated.

>  

-- johnS

______________________________/\/            \     \
John Stickley                   \             \     \
Mgr., Acceleration Methodologies \             \________________
Mentor Graphics - MED             \_
________________________________________________________________