RE: $finish and final_step

David,
comments below. 
Thanks,
--Martin

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of David Miller
Sent: Thursday, March 27, 2008 12:59 PM
To: Xavier Bestel
Cc: Verilog-AMS LRM Committee
Subject: Re: $finish and final_step

Hi Xavier,

oleary>final_step is not a block - it is a statement allowed in the
analog block (which is part of the problem I think)

I agree that final_step blocks can contain more than just "cleaning" 
statements. It is quite valid if they contain assignments etc. (although
maybe potentially dangerous).
oleary>otherwise I agree with this issue.

Perhaps it is better to look $finish and the execution of final_step
blocks separately.

Here is how I look at it:

$finish simply means that we want simulator to converge on the current
time step and exit nicely.

When a simulation exits nicely, it should then perform one extra
iteration that evaluates the analog instances as well as evaluating any
final_step blocks present. The solution array passed in should be the
one from the previous iteration that contains the converged values, and
no changes that are made by this extra iteration will have any affect on
this final converged solution.

I don't think that only final_step blocks should be executed during the
final_step. All statements in the analog block should be evaluated
except those
  statements contained in any initial_step blocks.

So this flow means:
  - the model sends a $finish
  - the simulator takes notice and converges on this time step
  - Once converged, the simulator will then perform 1 more extra
iteration informing the analog instances that the simulation has
completed.
  - For this extra iteration the instances will evaluate all valid
statements (including those in final_step blocks) however, any change to
the solution will have no affect.

oleary>this looks pretty complex and maybe confusing to explain. Also it
doesn't seem to cover the case of a $finish in a digital block - it
might be better to have a final block like system verilog does with
clear restrictions on what analog statements are allowed in it (e.g. not
contribution statements)

But maybe this is becoming too implementation specific.

I guess what I want to ensure is that whenever a simulation exits nicely
(either tran ran to completion or perhaps a $finish was encountered) the
analog instances are reevaluated to include any final_step blocks.

$finish is not only to exit a simulation early, a lot of digital-centric
designers that I see actually use $finish inside the digital initial
block with a delay as the only way to exit the simulation. For example:
   initial begin
     #500 $finish;
   end

Cheers...
Dave



Xavier Bestel wrote:
> Hi,
> 
> it looks to me that:
> - final_step blocks may contain way more than just "cleaning" 
> statements
> - final_step blocks may be anywhere in the analog block, and as 
> verilog-AMS has a requirement of executing its statements in sequence,

> you can re-execute a block once you have already done the following
one.
> 
> So the only reasonable way of executing final_step blocks seems to do 
> it while executing the analog block.
> So, if $finish implies final_step, it means:
> - the model sends a $finish
> - the simulator takes notice and doesn't accept the step
> - the simulator reexecutes the step in "final_step" mode
> 
> (in real life, it may of course be way more complex because e.g. the 
> final step won't converge, or it will modify the digital side, etc.).
> 
> All this would tend to preferring the solution where $finish just 
> stops the simu, without final_step. That's fine, but then we have no 
> way of finishing the simu early *and* calling final_step (which may do

> some useful final diagnostics like seen in some examples from the
LRM).
> 
> 	Xav
> 
> On Thu, 2008-03-27 at 15:46 +0000, Neugebauer Kurt wrote:
>> Hi Dave,
>>
>> Exactly, that's how I would like to have it work. 
>>
>> Kurt
>>
>> -----Original Message-----
>> From: Miller Dave
>> Sent: Thursday, March 27, 2008 4:33 PM
>> To: Neugebauer Kurt; Martin O'Leary
>> Cc: Verilog-AMS LRM Committee
>> Subject: Re: $finish and final_step
>>
>> Hi Kurt, Martin.
>> I am not sure I follow what you mean. $finish should not result in 
>> another timestep being executed to resolve final_step blocks should
it?
>> It simply requires that the analog engine performs one iteration on 
>> the analog instances.
>>
>> final_step blocks should (as far as I understand) be executed after 
>> the simulation has completed and reached a solution. So time is not 
>> advanced, there is no impact to the circuit solution, etc. final_step

>> is simply to clean up file handles, print any strobes etc.
>>
>> If $finish is encountered in digital then it would inform analog 
>> solver that it
>>   has completed. Analog would then simply execute final step blocks 
>> and stop the overall simulation. No need for analog to perform 
>> another solve or matrix load as it would have temporarily converged 
>> before calling digital.
>>
>> Is this not how it should work?
>>
>> Yes LRM2.2 did say that $finish just stops the simulation but during 
>> reviews I thought we came to the conclusion that stopping an 
>> analog/ams simulation (via $finish or just normal simulation 
>> completion) would include execution of final_step blocks.
>>
>> Cheers...
>> Dave
>>
>>
>> Neugebauer Kurt wrote:
>>> Hi,
>>>
>>> Martin is right, the question is what Design/verification wants
here.
>>> $finish; in digital is used for end of verification (all tests
>>> complete) or in by event triggered subroutine (i.e. test failure). 
>>> There is no need for analog @final_step block to trigger a final 
>>> digital event/subroutine, because the digital engine (event 
>>> triggered) is always in the state wanted.
>>> Digital $finish triggering analog final_step: I'm not sure, but do 
>>> we need it to i.e. close open output files, do post processing steps

>>> in the analog solver (analog assertions), ... ?
>>>
>>> Kurt Neugebauer
>>>
>>>
>>> -----Original Message-----
>>> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] 
>>> On Behalf Of Martin O'Leary
>>> Sent: Thursday, March 27, 2008 12:37 AM
>>> To: Miller Dave; Xavier Bestel
>>> Cc: Verilog-AMS LRM Committee
>>> Subject: RE: $finish and final_step
>>>
>>> David, Xavier
>>> I don't think it is such a straight-forward thing to say. The answer

>>> below seems to only cover $finish executed in an analog block.
>>>
>>> In digital, a $finish immediately terminates the simulation. For 
>>> AMS, it doesn't make sense to me that we require digital to then 
>>> execute the analog solver to do another time step in order to 
>>> execute the @final_step blocks after a $finish is encountered when 
>>> normally a digital simulators terminate immediately when a $finish
occurs.
>>>
>>> Also LRM2.2 says that $finish "simply makes the simulator exit" so 
>>> this would seem to not be a backwardly compatible change.
>>>
>>> Thanks,
>>> --Martin
>>>
>>> -----Original Message-----
>>> From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] 
>>> On Behalf Of David Miller
>>> Sent: Wednesday, March 26, 2008 8:35 AM
>>> To: Xavier Bestel
>>> Cc: Verilog-AMS LRM Committee
>>> Subject: Re: $finish and final_step
>>>
>>> Hello Xavier,
>>>
>>> yes, $finish should cleanly stop the simulation by converging on 
>>> this timestep and executing any final_step blocks.
>>>
>>> $stop should converge on the current timestep but not execute 
>>> final_step blocks.
>>>
>>> Main difference between $finish and $stop is that $stop is more like

>>> a pause - the simulation can be resumed. $finish terminates the 
>>> simulation.
>>>
>>> I am not sure why this is not highlighted in the LRM - I know that 
>>> we discuss the simulation control tasks but seems that adding in 
>>> this behaviour explicitly was missed. I will make a note to get it 
>>> added into next draft of 2.3
>>>
>>>
>>> Cheers...
>>> Dave
>>>
>>>
>>> Xavier Bestel wrote:
>>>> Hi,
>>>>
>>>> should $finish execute the step again with final_step events on ?
>>>> I didn't see it specified in the LRM, in a way or in the other.
>>>>
>>>> Thanks,
>>>> 	Xav
>>>>
>>>>
>>> --
>>> =====================================
>>> -- David Miller
>>> -- Design Technology (Austin)
>>> -- Freescale Semiconductor
>>> -- Ph : 512 996-7377 Fax: x7755
>>> =====================================
>>>
>>> --
>>> 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.
>>>
>>>
>>>
>> --
>> =====================================
>> -- David Miller
>> -- Design Technology (Austin)
>> -- Freescale Semiconductor
>> -- Ph : 512 996-7377 Fax: x7755
>> =====================================
>>
> 
> 

--
=====================================
-- David Miller
-- Design Technology (Austin)
-- Freescale Semiconductor
-- Ph : 512 996-7377 Fax: x7755
=====================================

--
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.