Re: FW: From Bernard

Bernard,

Per's comments clearly address any responses I would have made.

In other words, the "secret ingredient" is that on an emulator
platform, you can automatically stop "real" clocks as needed to
implicitly allow communications to the C side that would have
otherwise had to have been done explicitly in SCE-MI 1.1 -
even if there are multiple instances of such communications among
multiple transactors in a single time step.

This does two things:

1. Simplifies transactor writing considerably because the user
    no longer needs to worry about stopping clocks.

2. Guarantees deterministic behavior that users take for
    granted in pure S/W simulation environments that support DPI.

To elaborate on point #2, I would put back a challenge to you:

How would you model the same scenario that you described to me
for multiple transactors communicating with the C side in a pure
S/W simulator environment assuming that S/W simulator supports DPI ?
Can your transactors be executed in such an environment ?

Whatever answer you come up with should be the same for emulation.
And it is implied that to guarantee identical deterministic operation,
the emulator platform infrastructure would have to implicitly suspend
users' clocks where necessary.

More ...

Per Bojsen wrote:
> 
>>You should be able to write your transactor in a way that you do not
>>lose a `controlled' clock cycle.  That would be a serious problem as
>>it would amount to loss of coverage in the stimulus your transactor
>>would be able to provide.  I am struggling with how to provide a
>>convincing argument as to why this shouldn't be an issue.  Perhaps
>>the best way is to write up a complete example?  John, do we have
>>something available that would illustrate back-to-back transactions
>>without dead cycles?

johnS:
I believe the producer-consumer dual pipeline examples in the public
distribution sort of do this - or at least could be modified to.
Although I would rather try to illustrate this with the simple
AHB/APB example that Bernard mentions below.

Support for back-to-back transactions would be dependent on
implementations of modeling subsets around the DPI but let me
try to sketch a scenario for back to back transactions that
could be made to work for a S/W simulator that supports DPI:

import "DPI-C" context function void my_dpi_import_call(
     bit [63:0] previous_transaction_completion_result );

export "DPI-C" my_dpi_export_call;

function void my_dpi_export_call(
    bit [63:0] next_transaction_initiation_data )
    next_transaction = next_transaction_initiation_data;
endfunction

// This transactor's FSM ...
always @( posedge clk ) begin
     if( reset ) begin
         // Do the reset thing ...
     end
     else if( dut_result_from_previous_transaction_recognized ) begin
         my_dpi_import_call( dut_result_data );
         enable_next_dut_transaction <= 1;
         dut_bound_data <= next_transaction;
     end
end

In this scenario the FSM above initiates a "next transaction"
in a clock immediately following receipt of the result
from the previous transaction. This is because the assignment
to next_transaction is blocking and therefore its new value
is available for assignment to dut_bound_data - assuming
that my_dpi_export_call() is called from within my_dpi_import_call().

This could have been made simpler by having
my_dpi_import_call() return the next transaction data
directly.

But going through the export handles a potentially more
general case.

Most importantly, recognize that the above could work
if multiple transactors perform similar operations on
their own FSMs the same posedge clk that this one does.

More ...

B. Deadman wrote:
> 
> 
> Hi Per,
> 
> I'd like to clarify that I see lss issues with what I would term a 
> master/initiator style transactor which is dictating the sequence oif 
> transactions - my concern is with slave/responders that have to obtain 
> the response value from the testbench - it's there that I either risk 
> multiple function calls or can't get the output signals set early enough.
> 
> I'm presently on vacation and will be back late Wednesday.  I believe 
> have a very simple hybrid of APB & AHB that we use for training purposes 
> which will exhibit this issue.  Once I get back I'll check this out, but 
> I'd be happy to release it to indiviudal users to evaluate this issue, 
> though not to place the material in the public domain.

johnS:
I'd definitely like to see this example and can look at it under
NDA if necessary.

-- johnS
<eom>

> 
> If John has similar material we're members of the Mentor Vanguard(?) 
> program if that expedites release of the material.
> 
> Regards
> 
> Bernard
> 
> 
> 


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


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