Follwup from Bernard Deadman

Forwarding for Bernard


Hi John,

Thanks for the feedback, however unfortunately I don't think that 
achieves the result I'm looking for.

In order to try and clarify the semantics of our present SCE-MI 1.1 
solution I've attached a diagram.  In this diagram the sequence is:

1) a new transaction is recognized at the posedge of clock 2.  Note that 
we can have multiple transactors clocking on the same posedge.

2) recognition of the transaction causes the controlled clock to be 
stalled while the response is obtained, which in this case arrives by 
clock 5 - note that several transactors may have been serviced in this 
interval, and this may represent the last response to be obtained.

3) new output signal states are set immediately after posedge 5, which 
may be dependent on the response obtained from the testbench

4) the protocol proceeds and the next 'real' edge evaluated is at 
posedge 6 - it's my understanding that the intermediate un-controlled 
clocks can be removed and the protocol rules will be met exactly.


I can see how we can use a function-based interface to calculate the 
next state correctly, however I'm still at a loss to understand how the 
semantics work with synthesizable Verilog to support the sequence I've 
described where we get the output signals set correctly.  It's certainly 
feasible if the transactor is able to stall the clock in the same manner 
as allowed in SCE-MI 1.1 however without that feature I'm pretty sure we 
are going to 'lose' a controlled clock cycle, thereby potentially 
violating protocol rules in some designs.  My hunch is serial 
packet-based protocols will be more tolerant of this issue than the 
parallel bus protocols I'm working with at present.

Regards

Bernard



Stickley, John wrote:
>
> 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.