Hello, I have question about treating time during registration of time related callbacks (Verilog LRM 2005, p. 27.33.2): should it be absolute or relative? What is the distinction between cbAtStartOfSimTime and cbAfterDelay in the meaning of time? If cbAtStartOfSimTime has absolute time does it mean that registering this callback for past time rises an error? What about other callbacks in this section? IMHO all callbacks except cbAfterDelay should interpret time as absolute. The worts is that every simulator I could check (asking our customers or looking on discussion lists) behaves in different way. Example: At simulation time 10 I register two callbacks: void f() { PLI_INT32 cb( p_cb_data ) { return 0; } s_vpi_time time = { vpiSimTime, 0, 11 }; vpi_register_cb( cbAtStartOfSimulationTime, cb, 0 , &time }; vpi_register_cb( cbAfterDelay, cb, 0 , &time }; } I know that cbAfterDelay should execute @21 but what about cbAtStartOfSimulationTime? Should it be @11 or @21, too? If the latter is true then what is the distinction between them? Below there are aligned definitions for these callbacks from Verilog LRM 2005: cbAtStartOfSimulationTime: Callback shall occur before execution of events in a specified time queue. A callback can be set for any time, even if no event is present. cbAfterDelay : Callback shall occur after a specified amount of time, before execution of events in a specified time queue. A callback can be set for any time, even if no event is present. This also applies to cbNBASynch, cbReadWriteSynch, cbAtEndOfSimTime, cbReadOnlySynch? From this LRM exceprt cb_data_p->[time->low,time->high,time->real] These fields shall contain the requested time of the callback or the delay before the callback. it seems to me that there is a distinction for relative and absolute time but it is not clear which time interpretation should be applied to a particular callback. Best Regards, Krzysztof Konopko Leader Application Engineer Aldec -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Feb 28 22:43:54 2008
This archive was generated by hypermail 2.1.8 : Thu Feb 28 2008 - 22:44:06 PST