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

Bernard,

I don't know if this fully resolves your concern
but it seems to me that if you make an import
call from a the clocked FSM process, and that import obtains
some the transaction data and passes it back
via an output argument, the output data
could then be applied immediately in the
decisions made in the current state calculation
combo block.

Granted this may rule out separation of next_state
calculation logic from the processing in the current state
clocked block if you want to rule out multiple
glitchy function calls.

But given that output args have blocking semantics,
you would see new values immediately in the current state
block:

always @( posedge clk ) begin
  if ( reset ) begin
    // Do the reset thing ...

  else
    case( state ):
      GET_TRANSACTION_STATE: begin

        dpi_import_call(argument);
           
        // Locally prepare transaction based on state values ...
	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;

        state <= PROCESS_TRANSACTION_STATE;
      end

      PROCESS_TRANSACTION_STATE:
        // Your transaction is ready - wait for DUT response. 
	...
    endcase
end

-- johnS

-----Original Message-----
From: owner-itc@server.eda.org on behalf of Brian Bailey
Sent: Thu 6/14/2007 10:53 AM
To: itc@server.eda.org
Subject: 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.



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