RE: Mantis 850: final step

From: Helwig Graham-A11558 <Graham.Helwig_at_.....>
Date: Thu Oct 27 2005 - 21:53:14 PDT
Hello Marq,
 
When Verilog-AMS LRM is merged with system Verilog then it is reasonable to make final block execution sensitive to both digital and analog $finish events. 
 
The finish block and @final_step should equivalent w.r.t. there sensitivity to $stop system task calls.  
 
The equivalence of final block and @final_step w.r.t $finish hinges on the the behavior of analog $finish system task and its behavior with respect to the analog soling mechanism. The problem is that the text  in section 10.4.1 ("$finish simply make the simulator exit") does not help very much. When does it exit w.r.t. the current time point that is being solved?
 
I see two possible solutions:
1) Stop immediately and not complete the current analog time point. 
2) Stop after time point is completed (and the digital simulator has synchronized with the analog time).
 
If the 1st behavior is used, then @final_step should be insensitive to $finish system task and it should be only sensitive to the pre-defined end-of-simulation time events. Then final block and @final_step are different. If the 2nd behavior is used, then there is scope for @final_step event to sensitive $finish system task calls. Then Final block and @final_step are similar. 
 
The following example suggests the 1st behavior for $finish is the better one to use.
 
    electrical a;
    real num, demon;
    analog begin
      if (denom==0) begin
         $strobe("ERROR: divide by zero.");
         $finish;
      end
      V(a) <+ num/denom;
    end
 
So whatever the behavior is selected to be it needs to be clear defined in the LRM. Then @final_step behavior w.r.t. $finish can be defined and document in the LRM. 
 
Regards
Graham


  _____  

From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Marq Kole
Sent: Thursday, October 27, 2005 11:53 PM
To: verilog-ams
Subject: Re: Mantis 850: final step



Graham, 

In a Verilog-AMS environment, one could use the final block next to the analog block; there would be no need to do the same thing in @final_step. In pure Verilog-A on the other hand, the combination $finish and @final_step have currently different semantics than in pure digital SV the combination $finish and final block. 

It would break a lot of existing code to change the current Verilog-A behavior. Even though it is not possible to change the values of analog port variables anymore in the @final_step, one can still read them, and write them out to file - a file that is not necessarily open if $finish is called early (say in the @initial_step). 

analog begin 
  @(initial_step) begin 
    if (Vx < 0) begin 
      $strobe("Vx is smaller than 0, aborting ..."); 
      $finish; 
    end 
    fp = $fopen("output.tbl"); 
  end 

  @(final_step) 
    $fstrobe(fp, "Vout = %g, V(out)); 

end 

final begin 
  $strobe("$finish called ..."); 
end 

As the final block and the @final_step event are different animals, I do not see a reason to make their behaviors equivalent - one is handled by a continuous-time solver, the other by a discrete event handler. 

In summary: if you need postprocessing after a $finish, you can add a final block (in SV-AMS), if you want the simulation to stop immediately, use a @final_step event. 

Regards, 
Marq 


Marq Kole
Competence Leader Analog Simulation, Philips ED&T










Helwig Graham-A11558 <Graham.Helwig@freescale.com> 


Sent by: 
owner-verilog-ams@eda.org 


26-10-2005 02:51 


To
Chandrasekaran Srikanth-A12788 <Srikanth.Chandrasekaran@freescale.com> 

cc
verilog-ams <verilog-ams@eda.org> 

Subject
Mantis 850: final step 

Classification

	




Hello Sri, 
  
There was some discussion about how @final_step should behave w.r.t. $stop and $finish system tasks. System Verilog v3.1a has defined a final block (similar to initial blocks). For example: 
  
    final begin 
        $display("$finish has been called."); 
    end 
  
It would reasonable to make digital final block and analog @final_step event behave the same way. 
  
Regards 
Graham 
  
  
Received on Thu Oct 27 21:55:06 2005

This archive was generated by hypermail 2.1.8 : Thu Oct 27 2005 - 21:55:49 PDT