FW: SCE-MI 2.0 semantics queston

Forwarding to the refrlector

-----Original Message-----
From: Bernard Deadman [mailto:bdeadman@sdvinc.com] 
Sent: Wednesday, June 13, 2007 5:45 AM
To: Brian Bailey
Subject: SCE-MI 2.0 semantics queston

We're beginning to look at how we convert our existing SCE-MI 1.1 
generator to create 2.0 compliant code, however we've come across a 
semantic question to which I can't see an obvious solution.  Our 1.1 
"slave" transactors need to obtain response values from the C++ domain 
once they recognize a transaction coming from the DUT.  At present they 
stall the controlled clock while they send a message to the workstation 
and wait for a response.  I believe the nearest equivalent to this in 
the function-based 2.0 environment is for the synthesizable transactor 
to make a function call to the C++, and for the response to be provided 
in a nested call into the Verilog-domain, ie nest figure 8 inside figure 
9 (page 34).

My concern is how we handle the response in the synthesizable Verilog.  
Our generated verilog is a classic two-process style, where one process 
is combinational and calculates the next state(s), while the second 
updates the latches.  It's essentially:


always @ *
    begin
    // combinational process to calculate state & transaction data

    new_state = ???? ;

    end


always @ ( posedge clock or negedge reset )
    begin
    // latch the new state

    state <= new_state;

    end


How are the semantics of the function call expected to work in this 
coding style?  My concern is if we place the function in the 
combinational process, for example

always @ *
    begin
    // combinational process to calculate state & transaction data

    if( signalA && signalB )
        begin
        new_data = my_function( detected_transaction );
       end

    end

while correct, the function can potentially get called many times, 
generating a lot more SCE-MI traffic than necessary, with a consequent 
performance issue.


If I read the documentation correctly, we're also not allowed to embed 
clock control macro's in function-based transactors.  Was there a reason 
this was not allowed?  I can see situations where we've "stolen" an 
un-controlled clock cycle to move or re-calcuate data inside the 
transactor after communication with the testbench, however the apparent 
inability to do this in function-based 2.0 is going to force us to use 
more multi-port storage than we presently generate.

Thanks in advance for your help and advice.

Regards

Bernard
PS - I was also going to send these questions to John Stickley as you 
suggested, however I don't have an up-to-date address for him.

-- 
====================================================================
SDV Inc.   Austin,   TX,   USA    Phone:   (512) 431-5126
Sussex, England   Phone +44-(0)1243-842111  Mobile +44-(0)798-1982762
Email:    bdeadman@sdvinc.com   Website:   www.sdvinc.com




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