RE: FW: SCE-MI 2.0 semantics queston

Bernard,

I think Per's response pretty well sums up anything I have
to add to this.

I agree with his assertion that you should certainly
avoid any DPI import calls inside combo blocks - as
he said, even as a general good practice irrespective
of the SCE-MI 2 context.

Although SCE-MI 2 pretty much steers clear of any
modeling subset restrictions on when DPI calls can
be made and when they can not (SCE-MI 2 imposes
interfacing rules but not modeling rules - yet),
we can probably postulate a few guidelines
on good practices for when they should be called.

Formost I would agree with Per's recommendation that
you only call imports from clocked sequential blocks.

Under such circumstances there would be implied
clock stoppage while the call is being carried
out on the C side.

The key advantage of the SCE-MI 2 use model is that
this stoppage is just that, implied, so that it does
not have to be the concern of the user - hence
improved ease-of-use.

Secondly, this use model ports cleanly to pure
S/W simulator environments that already support
SystemVerilog DPI.

-- johnS


-----Original Message-----
From: owner-itc@server.eda.org on behalf of Per Bojsen
Sent: Wed 6/13/2007 11:20 AM
To: bdeadman@sdvinc.com
Cc: itc@server.eda.org
Subject: Re: FW: SCE-MI 2.0 semantics queston
 
>> 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.