Scott, I disagree with you for the $finish on the digital side: (1) results from a mixed signal simulation should be consistent: signals from essentially the same simulation (from a user point of view) should all end at the same time, whether that is the given end of the simulation time or the result of a $finish call; (2) the digital event clearly affects the analog run, as finishing the digital simulation would affect all connections between the digital and the analog at the exact timepoint of the digital $finish. So indeed as Prasanna suggest, the analog should back up to the time point where the digital $finish is executed, as only until that time the simulation results can be guaranteed to be accurate and consistent. The analog simulation should then also finish. The signal changes on the D2A interface due to the $finish are in no way different for the synchronization between the two engines than signal changes due to signal assignments. (3) the standard says that the simulator should exit when encountering a $finish. In order to achieve consistent behaviour between a single engine and multi-engine approach to mixed-signal simulation, this should mean that all simulation processes should finish, i.e. both the analog and the digital simulator should finish at the same time. Regards, Marq Marq Kole Competence Leader Analog Simulation, Philips ED&T Building WAY 3.069, Professor Holstlaan 4,5656 AA Eindhoven, The Netherlands Tel. +31 40 27 44875, Fax. +31 40 27 44700 marq.kole@philips.com, www.research.philips.com "Scott Cranston" <cranston@cadence.com> Sent by: owner-verilog-ams@eda.org 21-04-2005 14:16 To: <verilog-ams@eda.org> cc: (bcc: Marq Kole/EHV/RESEARCH/PHILIPS) Subject: RE: $finish and @(final_step()) Classification: For a $finish on the digital side, the analog simulation should just be allowed to "free-run" until its stop time. For a $finish in analog, Marq has summed it up pretty well. -- Scott +++-----Original Message----- +++From: owner-verilog-ams@eda.org +++[mailto:owner-verilog-ams@eda.org] On Behalf Of Tamhankar +++Prasanna-A14507 +++Sent: Thursday, April 21, 2005 3:57 AM +++To: verilog-ams@eda.org +++Subject: $finish and @(final_step()) +++ +++Hi all, +++ +++LRM says "final_step generates global events only on the +++last point in an analysis" (section 6.7.4), however, should +++final_step event trigger if a $finish is encountered ? +++Consider a case where say some files were opened (in +++initial_step) and are to be closed in final_step. If a +++$finish event happens before the simulator reaches the +++simulation end time, it will be nice to trigger the +++final_step so as to close all the files. +++ +++I have included two example modules below, the first one is +++purely analog, second one is mixed signal. +++ +++module analogFinish; +++ +++ analog begin +++ +++ @(initial_step("static")) begin +++ // some file opens +++ end +++ if ($abstime > 0.7) begin +++ $strobe("%m About to call analog finish"); +++ $finish(0); +++ end +++ +++ @(final_step("tran")) begin +++ $strobe("%m >> Time %g: '@(final_step('tran'))' event +++has fired.", $abstime); +++ // some file closes +++ end +++ end +++endmodule +++ +++`timescale 1ms / 1ms +++module digitalFinish; +++ initial begin +++ #700; +++ $display("Time %g: Digital $finish(0) is about to +++occur.", $realtime); +++ $finish(0); +++ end +++ analog begin +++ @(initial_step("static")) begin +++ // some file open +++ end +++ +++ @(final_step("tran")) begin +++ $strobe("%m >> Time %g: '@(final_step('tran'))' event +++has fired.", $abstime); +++ // some file close +++ end +++ end +++endmodule +++ +++Also, in this module digitalFinish, assume that the analog +++and the digital engines synchronized at 0.6 seconds. Analog +++takes a step to say 0.74 seconds and then the digital tries +++to catch up, but at 0.7 (#700) encounters a $finish. Should +++the analog engine then synchronize with digital by +++backing-up from 0.74 to 0.7 and then end the simulation ? +++ +++Best regards, +++Prasanna +++ +++Received on Thu Apr 21 06:30:41 2005
This archive was generated by hypermail 2.1.8 : Thu Apr 21 2005 - 06:30:55 PDT