FW: BOUNCE itc@eda.org: Non-member submission from [Bernard Deadman <bdeadman@sdvinc.com>]

Forwarding from Bernard

Hi Per,

Thanks for the feedback.

We don't use this coding style in SCE-MI 1.1 - there we latch the 
response from the testbench during an un-controlled clock cycle, before 
determining the next state and/or output signal in preparation for 
releasing the clock control, so that the signals are set for the next 
controlled clock.  I'd like to be able to swap out the SCE-MI 1.1 
communication mechanism for the DPI calls however the lack of a clock 
control in the function-based solution makes this impossible.   FYI : 
the reason we can't stay with SCE-MI 1.1 is one major vendor is not 
committed to resolving issues we've pointed out in his implementation, 
but seems more likely to support 2.0, therefore we have to make 2.0 work 
if possible.

Moving back to the 2.0 implementation, we're returning full transaction 
data from the testbench, which can be 100's or 1000's of bits wide.  We 
need to make decisions about the next state and output values based on 
slices from that vector.  Are you familiar with the AXI protocol?  That 
has an xLAST signal that needs to get set if the burst length is going 
to be zero, and xVALID signals that need to get set if the delay is 
zero, therefore even in this simple case we need to make two decisions 
about the returned data are well as latch it into local transaction 
storage, for example


if( argument[ length_slice ] == 0 )
    begin
    if( argument[ delay_slice ] == 0 )
       begin
       xLAST = 1; xVALID = 1; xDATA = argument[ data_slice ];
       end
    else
       begin
       xLAST = 1; xVALID = 0; xDATA = 0;
       end
    end
else
    begin
    if( argument[ delay_slice ] == 0 )
       begin
       xLAST = 0; xVALID = 1; xDATA = argument[ data_slice ];
       end
    else
       begin
       xLAST = 0; xVALID = 0; xDATA = 0;
       end
    end

local_storage = argument;


In summary the semantics of this are very hard to resolve because the 
same decision process has to be based on local transaction storage for 
~90% of cycles and the function return value for the remainder.

Does anyone have a real example of the use of function-based DPI calls 
to obtain response values from a testbench, particularly where the 
response has to be sliced, because at the moment I'm struggling a see a 
way through this problem.

Thanks,

Bernard




Per Bojsen wrote:
>>> always @ *
>>>     begin
>>>     // combinational process to calculate state & transaction data
>>>
>>>     if( signalA && signalB )
>>>         begin
>>>         new_data = my_function( detected_transaction );
>>>        end
>>>
>>>     end
>
> Thinking a little more about this it was occurring to me that
> this is probably not a desirable coding style even in simulation
> only code since if signalA and signalB are asynchronous you may
> have race conditions which could lead to several calls of
> my_function() and perhaps even a different number of calls
> depending on simulator and what else exists in the code.  This
> essentially could impact determinism especially if my_function()
> has side effects such as calling a random number generator for
> random stimulus.
>
> So to guarantee determinism I would recommend moving the DPI
> calls to a clocked process.
>
> John, I'd like to hear your perspective on this issue as well.
> Perhaps we should open an IM as this is an interesting issue
> which should probably be addressed in at least an app note.
>
> Per
>
>


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.