>> 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.Received on Wed Jun 13 08:21:27 2007
This archive was generated by hypermail 2.1.8 : Wed Jun 13 2007 - 08:23:14 PDT