Re: sc_pause

Hi John,

I have no objection.

I think providing the state transition chart with related API
call (and simulation phase) will help to understand the overall
flow.
I was looking at Figure 28 of the LRM and thought it.

BTW, the label of Figure 28 "rb" transport may be "nb" transport.

Regards,
Kaz

-- 
Kaz Yoshinaga
Tel: +81-45-478-3228
email: yoshi@starc.or.jp
From: john.aynsley@doulos.com
Subject: RE: sc_pause
Date: Fri, 12 Nov 2010 13:49:13 +0000
> It seems we are all set. I will write up the sc_pause/sc_get_status 
> proposal in the LRM. As usual, shout if you want to raise objections.
> 
> John A
> 
> 
> 
> 
> 
> From:
> Bishnupriya Bhattacharya <bpriya@cadence.com>
> To:
> "john.aynsley@doulos.com" <john.aynsley@doulos.com>
> Cc:
> "alan.fitch@doulos.com" <alan.fitch@doulos.com>, 
> "owner-systemc-p1666-technical@eda.org" 
> <owner-systemc-p1666-technical@eda.org>, "systemc-p1666-technical@eda.org" 
> <systemc-p1666-technical@eda.org>, "Jeremiassen, Tor" <tor@ti.com>
> Date:
> 11/11/2010 16:33
> Subject:
> RE: sc_pause
> 
> 
> 
> John,
>  
> The implicit pause part is what I was trying to get to. Its clear now. 
>  
> The rest of the clarifications all look good.
>  
> Thanks,
> -Bishnupriya
> 
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com] 
> Sent: Thursday, November 11, 2010 2:20 PM
> To: Bishnupriya Bhattacharya
> Cc: alan.fitch@doulos.com; owner-systemc-p1666-technical@eda.org; 
> systemc-p1666-technical@eda.org; Jeremiassen, Tor
> Subject: RE: sc_pause
> 
> Bishnupriya, 
> 
> As it stands, the proposal says  "On return from  sc_start without sc_stop 
> having been called, the simulation is left in the paused state. "  In 
> other words, on return from sc_start() without sc_stop() having been 
> called, there is an implicit sc_pause(). 
> 
> In other words, the SC_RUNNING bit will only be set when sc_get_status() 
> is called from a process during the evaluation phase or from a primitive 
> channel during the update phase. 
> 
> Just to complete the picture, is_running() is false during 
> start_of_simulation() and end_of_simulation(), and we are changing the LRM 
> such that it is no longer required to be false when called from a 
> destructor. We are also adding the recommendation that sc_start() should 
> call sc_stop() when necessary, so that is_running() typically would return 
> false when called from a destructor. 
> 
> John A 
> 
> 
> 
> From: 
> Bishnupriya Bhattacharya <bpriya@cadence.com> 
> To: 
> "john.aynsley@doulos.com" <john.aynsley@doulos.com> 
> Cc: 
> "alan.fitch@doulos.com" <alan.fitch@doulos.com>, 
> "owner-systemc-p1666-technical@eda.org" 
> <owner-systemc-p1666-technical@eda.org>, "systemc-p1666-technical@eda.org" 
> <systemc-p1666-technical@eda.org>, "Jeremiassen, Tor" <tor@ti.com> 
> Date: 
> 10/11/2010 16:56 
> Subject: 
> RE: sc_pause
> 
> 
> 
> 
> John, 
>   
> Comments below on sc_sim_status(). 
> 
> From: john.aynsley@doulos.com [mailto:john.aynsley@doulos.com] 
> Sent: Wednesday, November 10, 2010 4:23 PM
> To: Bishnupriya Bhattacharya
> Cc: alan.fitch@doulos.com; owner-systemc-p1666-technical@eda.org; 
> systemc-p1666-technical@eda.org; Jeremiassen, Tor
> Subject: RE: sc_pause
> 
> #! SystemVerilog 
> join_none 
> disable fork; 
> 
> 
> Bishnupriya, 
> 
> On return from sc_start(whatever), I am saying the SC_RUNNING bit will 
> always be 0, and either the SC_STOPPED or the SC_PAUSED bit will be 1. 
>   
>>>> [bpriya: So in sc_main() in between sc_start() calls, SC_RUNNING bit 
> is always 0. The SC_STOPPED part is clear. I'm not clear about SC_PAUSED. 
> After a sc_start(), if the sc_start() did not return due to sc_stop(), is 
> SC_PAUSED bit set always set, irrespective of whether sc_pause() was 
> called or not? Or is it only set if sc_pause() was called()? ] 
>   
> Thanks, 
> -Bishnupriya  
> 
> I agree sc_pause() should always finish the delta cycle such that one 
> evaluation phase cannot be split across a pause. 
> 
> Re. resuming a process after a pause, what's wrong with: 
> 
>        sc_pause(); 
>        wait(SC_ZERO_TIME); 
> 
> ? 
> 
> John A 
> 
> 
> 
> From: 
> Bishnupriya Bhattacharya <bpriya@cadence.com> 
> To: 
> "alan.fitch@doulos.com" <alan.fitch@doulos.com>, "john.aynsley@doulos.com" 
> <john.aynsley@doulos.com> 
> Cc: 
> "owner-systemc-p1666-technical@eda.org" 
> <owner-systemc-p1666-technical@eda.org>, "systemc-p1666-technical@eda.org" 
> <systemc-p1666-technical@eda.org>, "Jeremiassen, Tor" <tor@ti.com> 
> Date: 
> 10/11/2010 10:22 
> Subject: 
> RE: sc_pause
> 
> 
> 
> 
> 
> John, 
>  
> Did you respond to Alan's second question below? If you did, I missed it. 
> I've the same question: 
>  
> Suppose sc_main() calls sc_start(), and a process calls 
> sc_pause(SC_STOP_IMMEDIATE). This will make sc_start() return to sc_main() 
> right after the current process finishes, and while there maybe processes 
> remaining in the runnable q. When the next sc_start() is issued from 
> sc_main(), I suppose these runnable processes should all execute? What 
> happens to the delta cycle count? Should the delta cycle count be the 
> same? Essentially here the eval phase of one delta cycle is spanning 
> across two sc_start() calls and across stuff that can happen in between in 
> sc_main(). Does this seem a little worrisome? e.g. if one of the runnable 
> processes gets killed in sc_main() before the next sc_start()? Well that 
> actually is taken care of by kill() semantics. Could anything else 
> unexpected happen? In any case, we need to clarify the behavior here. For 
> sc_stop(), we do not need to deal with this because simulation cannot 
> resume. 
>  
> "On return from  sc_start without sc_stop having been called, the 
> simulation is left in the paused state. On return from  sc_start after 
> sc_stop has been called, the simulation is left in the stopped state. In 
> either case, simulation will remain in the running state until all 
> processes have ceased executing prior to the return from sc_start" 
>  
> Clarification: If sc_start(100, SC_NS) returns to sc_main() w/o any 
> sc_pause() having been called, what does sc_sim_status() return? What if 
> sc_start() returns because of sc_pause()? In either cases, both the 
> SC_RUNNING bit and SC_PAUSED bit is set?   
>  
> One final comment. sc_pause() is an useful mechanism by which a process is 
> interrupting/pausing the simulation. In a SystemC simulator with an 
> interactive prompt, it can provide a natural point where control can 
> return to the prompt - similar to making sc_start() return - and users can 
> introspect or configure things perhaps at the prompt. Now suppose a 
> process determines that it needs some configuration/user-input, and it 
> calls sc_pause() to that purpose. But it further wants to wake up and get 
> scheduled when simulation resumes again. Is it warranted to provide an 
> event that is notified when simulation is resumed again with sc_start()? 
> This could be made generic, and not tied particularly to 
> sc_pause()/resumption - e.g. sc_start() can always notify an event at its 
> onset. 
>  
> void run() { 
>  while (1) { 
>    // do stuff 
>    if (condition) { 
>      sc_pause(); 
>      wait(sc_simulation_resume_event); // or wait(sc_start_event) 
>      ... 
>    } 
>  } 
> } 
>  
> We also have the option of tying it entirely to sc_pause() and making it 
> less generic - e.g. "sc_pause(bool block = false)". If you call 
> sc_pause(true) from thread process then it will block till simulation is 
> resumed again with sc_start() - the specifics can be left implementation 
> defined. The Cadence simulator has had a similar pause() functionality, 
> and this blocking feature has been found to be useful. What do people 
> think? 
>  
> Thanks, 
> -Bishnupriya 
> 
> From: owner-systemc-p1666-technical@eda.org [
> mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of 
> alan.fitch@doulos.com
> Sent: Monday, November 08, 2010 7:41 PM
> To: john.aynsley@doulos.com
> Cc: owner-systemc-p1666-technical@eda.org; 
> systemc-p1666-technical@eda.org; Jeremiassen, Tor
> Subject: Re: sc_pause
> 
> Hi John, 
> a couple of questions: 
> 
> just to clarify, if I had in sc_main 
> 
> sc_start(100, SC_NS);  // inside here the code calls sc_pause at say time 
> = 50 ns 
> sc_start (100, SC_NS);  // this would resume at 50 ns 
> 
> Secondly, if I called 
> 
>  sc_start(SC_ZERO_TIME);  // call sc_pause with SC_STOP_IMMEDIATE during 
> the evaluation phase 
> 
> // now what happens? do other runnable processes complete the rest of the 
> delta above when resumed 
> sc_start(1, SC_NS); 
> 
> regards 
> Alan 
> 
> -- 
> Alan Fitch
> Senior Consultant
> 
> Doulos - Developing Design Know-how
> VHDL * Verilog * SystemVerilog * SystemC * PSL * Perl * Tcl/Tk * Project 
> Services
> 
> Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, 
> UK
> Tel:  + 44 (0)1425 471223                       Email: 
> alan.fitch@doulos.com 
> Fax:  +44 (0)1425 471573                        http://www.doulos.com
> 
> --------------------------------------------------------------------------------
> Doulos Ltd is registered in England and Wales with company no. 3723454
> Its registered office is 4 Brackley Close, Bournemouth International 
> Airport,
> Christchurch, BH23 6SE, UK. 
> 
> This message (and associated files) may contain information that is 
> confidential, 
> proprietary, privileged, or subject to copyright. It is intended solely 
> for the use
> of the individual to whom it is addressed and others authorised to receive 
> it. If
> you have received this email in error, please notify the sender and delete 
> all
> copies. This message may contain personal views which are not the views of
> Doulos, unless specifically stated.
> 
> From: 
> john.aynsley@doulos.com 
> To: 
> systemc-p1666-technical@eda.org 
> Cc: 
> "Jeremiassen, Tor" <tor@ti.com> 
> Date: 
> 08/11/2010 13:59 
> Subject: 
> sc_pause 
> Sent by: 
> owner-systemc-p1666-technical@eda.org
> 
> 
> 
> 
> 
> 
> Folks, 
> 
> The next topic to finish off is the addition of sc_pause and sc_get_status
> , as originally proposed by Tor. We got to the point of being almost ready 
> to close this discussion months ago. I  summarize the current proposal 
> below. Please give this your careful consideration and either vote "yes" 
> or raise any objections you may have. 
> 
> Thanks, 
> 
> John A 
> 
> 
> 
> Add a function sc_pause that is similar to sc_stop except that it puts 
> simulation into the paused state. Simulation can be restarted from the 
> paused state by calling sc_start again. 
> 
> sc_pause uses sc_stop_mode to determine precisely when to pause (or we 
> could introduce a new sc_pause_mode, if people wish) 
> 
> sc_pause leaves the simulation time at its current value such that 
> sc_start would continue from that time 
> 
> On return from  sc_start without sc_stop having been called, the 
> simulation is left in the paused state. On return from  sc_start after 
> sc_stop has been called, the simulation is left in the stopped state. In 
> either case, simulation will remain in the running state until all 
> processes have ceased executing prior to the return from sc_start 
> 
> Make a change to the scheduler spec such that on return from sc_start() 
> due to event starvation, the simulation time remains at the time of the 
> last event. This can only come about after every process has either 
> terminated or executed wait(...) with no time-out. 
> 
> When paused, sc_is_running() shall return true. 
> 
> Change the LRM such that sc_is_running() is not obliged to return false 
> when called from a destructor; sc_is_running would return true unless 
> sc_stop had been called 
> 
> Add a global function sc_get_status whose value is a bit mask, used as 
> follows: 
> 
> if (sc_get_status() & (SC_PAUSED | 
>                                      SC_STOPPED | 
>                                      SC_END_OF_SIMULATION) ) 
>    ... 
> 
> The full list of simulation phases is: 
>      SC_ELABORATION 
>      SC_BEFORE_END_OF_ELABORATION 
>      SC_END_OF_ELABORATION 
>      SC_START_OF_SIMULATION 
>      SC_RUNNING 
>      SC_PAUSED 
>      SC_STOPPED 
>      SC_END_OF_SIMULATION 
> 
> 
> -- 
> 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. 
> 
> 
> 
> 
> 
> -- 
> 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.