Re: FW: SCE-MI 2.0 semantics queston

Hi Bernard,

I'm sure John S. will offer his perspective as well, but here
are some quick answers to your questions.

> We're beginning to look at how we convert our existing SCE-MI 1.1 
> generator to create 2.0 compliant code,

The first point to make is that the SCE-MI 1.1 macro-based modeling
style is still supported in SCE-MI 2, so you do not actually have
to convert to run on SCE-MI 2 compliant implementations.  However,
I can see how it might be useful to convert to the DPI subset of
SCE-MI 2 as it would allow you to run your generated code on
any SystemVerilog simulator.

> 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

Yes, you definitely do not want to do this.  The DPI function
call should be moved to the clocked process or the if condition
should be written such that it is guaranteed to only change once
per clock cycle, e.g., by ensuring all signals in the expression
are synchronous.

Another way to do this is to switch to a one-process state machine
style, e.g.,

   always @(posedge CLK or posedge RESET)
   begin
     if (RESET)
       // Reset code here
     else
     begin
       case (CurrentState)
         SomeState:
           if (signalA && signalB)
           begin
             new_data = my_function( detected_transaction );
           end
       endcase
     end
   end

You can also move the if statement to the top of the else
block if new_data is a common subexpression.  Also, if signalA
and signalB are flop outputs, you still see only one call of
my_function() in your code.

> 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?

That's correct.  We specifically disallowed this for several reasons
but mainly to avoid some complicated semantic issues when combining
the two use models (macro-based and function-based).  You are allowed
to use macro-based and function-based transactors in the same testbench,
but you can't mix macro-based and function-based features in a
transactor.

 > 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.

This is a more advanced usage and perhaps is another reason why you
may not want to move to DPI for such transactors.  I assume the
recalculation is needed to allow you to reduce the amount of
communication between the two sides?  Otherwise you could consider
moving the data processing/formatting to the C++ side.

Hope this helps,
Per Bojsen



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