[sv-champions] Re: [sv-bc] Update to Scheduling proposal for reballot issue

From: Karen Pieper <Karen.Pieper_at_.....>
Date: Thu Jul 07 2005 - 13:35:07 PDT
>From: owner-sv-champions@eda.org
>Date: Thu, 7 Jul 2005 12:45:08 -0700 (PDT)
>X-Authentication-Warning: server.eda.org: majordom set sender to owner-sv-champions@eda.org using -f
>To: sv-champions-approval@eda.org
>Subject: BOUNCE sv-champions@eda.org:    Non-member submission from [Gordon Vreugdenhil <gordonv@model.com>]   
>X-Virus-Scanned: ClamAV 0.83/971/Thu Jul  7 03:08:01 2005 on server.eda.org
>X-Virus-Status: Clean
>X-pstn-levels:     (S:99.90000/99.90000 R:95.9108 P:95.9108 M:97.0232 C:98.7678 )
>X-pstn-settings: 1 (0.1500:0.1500) gt3 gt2 gt1 r p m c 
>X-pstn-addresses: from <owner-sv-champions@eda.org> [691/20] 
>
>>From pieper Thu Jul  7 12:45:07 2005
>Received: from relay1.mentorg.com (relay1.mentorg.com [192.94.38.131])
>        by server.eda.org (8.12.10/8.12.0.Beta7) with ESMTP id j67Jj6I1006086;
>        Thu, 7 Jul 2005 12:45:06 -0700 (PDT)
>Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58])
>        by relay1.mentorg.com with esmtp 
>        id 1DqcJ0-00034q-00 from gordon_vreugdenhil@mentor.com ; Thu, 07 Jul 2005 12:45:06 -0700
>Received: from SVR-ORW-EXC-07.mgc.mentorg.com ([147.34.98.95]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.211);
>        Thu, 7 Jul 2005 12:45:06 -0700
>Received: from [147.34.77.152] ([147.34.77.152]) by SVR-ORW-EXC-07.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.211);
>        Thu, 7 Jul 2005 12:45:05 -0700
>Message-ID: <42CD8640.4000709@model.com>
>Date: Thu, 07 Jul 2005 12:45:04 -0700
>From: Gordon Vreugdenhil <gordonv@model.com>
>User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
>X-Accept-Language: en-us, en
>MIME-Version: 1.0
>To: Karen Pieper <Karen.Pieper@synopsys.com>
>CC: sv-champions@server.eda.org, sv-cc@server.eda.org, sv-bc@server.eda.org,
>        sv-ec@server.eda.org, sv-ac@server.eda.org
>Subject: Re: [sv-bc] Update to Scheduling proposal for reballot issue
>References: <5.1.0.14.2.20050706172311.017fedd0@pophost.synopsys.com>
>In-Reply-To: <5.1.0.14.2.20050706172311.017fedd0@pophost.synopsys.com>
>Content-Type: text/plain; charset=us-ascii; format=flowed
>Content-Transfer-Encoding: 7bit
>X-OriginalArrivalTime: 07 Jul 2005 19:45:05.0982 (UTC) FILETIME=[5FD98DE0:01C5832C]
>X-Virus-Scanned: ClamAV 0.83/971/Thu Jul  7 03:08:01 2005 on server.eda.org
>X-Virus-Status: Clean
>
>Karen Pieper wrote:
>
> > Hi, all,
> >
> > A new proposal for Mantis issue 794 (event scheduling) has been
> > uploaded in response to feedback we have received on the original
> > proposal.  Please review and offer feedback if you have any.
> > We will be voting on this issue and the others in the reballot
> > spreadsheet in  Friday's Champions meeting.
>
>
>With respect to the new scheduling section (Mantis 794),
>the diagram is fine, but I don't think the pseudocode is
>correct (i.e. consistent with the diagram).
>
>Here is what is in the proposal:
>
>-------------------
>
>     execute_time_slot
>     {
>         execute_region (preponed);
>         execute_region (pre-active);
><1>     while (any region in [active ... pre-postponed] is non-empty) {
>             while (any region in [active ... post-observed] is non-empty) {
>                 execute_region (active);
>                 R = first non-empty region in [active ... post-observed];
>                 if (R is non-empty)
>                     move events in R to the active region;
>             }
>             while (any region in [reactive ... re-inactive] is non-empty) {
>                 execute_region (reactive);
>                 R = first non-empty region in [reactive ... re-inactive];
>                 if (R is non-empty)
>                     move events in R to the reactive region;
>             }
>             if (pre-postponed is non-empty)
>                 execute_region (pre-postponed);
>         }
>         execute_region (postponed);
>     }
>
>-------------------
>
>Note that we don't get back to <1> without doing the
>pre-postponed (if there is anything there).  So any
>cbAtEndOfSimTime happens before the loop back.
>
>That isn't what is intended by the diagram.
>
>Here are two corrected variants of the pseudocode:
>
>
>-------------------
>Variant 1
>-------------------
>
>     execute_time_slot
>     {
>         execute_region (preponed);
>         execute_region (pre-active);
>         while (any region in [active ... pre-postponed] is non-empty) {
>             while (any region in [active ... re-inactive] is non-empty) {
>                 while (any region in [active ... post-observed] is non-empty) {
>                     execute_region (active);
>                     R = first non-empty region in [active ... post-observed];
>                     if (R is non-empty)
>                         move events in R to the active region;
>                 }
>                 while (any region in [reactive ... re-inactive] is non-empty) {
>                     execute_region (reactive);
>                     R = first non-empty region in [reactive ... re-inactive];
>                     if (R is non-empty)
>                         move events in R to the reactive region;
>                 }
>             }
>             execute_region (pre-postponed);
>         }
>         execute_region (postponed);
>     }
>
>-------------------
>Variant 2
>-------------------
>
>     execute_time_slot
>     {
>         execute_region (preponed);
>         execute_region (pre-active);
>         while (any region in [active ... pre-postponed] is non-empty) {
>             while (any region in [active ... post-observed] is non-empty) {
>                 execute_region (active);
>                 R = first non-empty region in [active ... post-observed];
>                 if (R is non-empty)
>                     move events in R to the active region;
>             }
>             while (any region in [reactive ... re-inactive] is non-empty) {
>                 didReactive = TRUE;
>                 execute_region (reactive);
>                 R = first non-empty region in [reactive ... re-inactive];
>                 if (R is non-empty)
>                     move events in R to the reactive region;
>             }
>             if (all regions in [active ... re-inactive] are empty)
>                 execute_region (pre-postponed);
>         }
>         execute_region (postponed);
>     }
>-------------------
>
>
>The triple loop form (Variant 1) is probably preferable, but either form
>is acceptable.
>
>
>Gord.
>-- 
>--------------------------------------------------------------------
>Gordon Vreugdenhil,  Staff Engineer               503-685-0808
>Model Technology (Mentor Graphics)                gordonv@model.com
Received on Thu Jul 7 13:34:26 2005

This archive was generated by hypermail 2.1.8 : Thu Jul 07 2005 - 13:34:27 PDT