RE: P1666 Ballot resolution discussion

John,

You say these issues came up while updating the PoC simulator. I’m curious what tests you were running that uncovered them, or was it just obvious while coding (inspection)?

EricR


From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com
Sent: Tuesday, April 26, 2011 1:22 PM
To: P1666 Technical WG
Subject: Re: P1666 Ballot resolution discussion

All,

The biggest set of issues we have to address were pointed to by Cadence in their ballot comments, and were raised as a result of implementing the proposed changes to 1666 within the OSCI proof-of-concept simulator (by Andy, Bishnupriya, Philipp, and myself). These issues split into the process corner cases, clarifications to the LRM wording, and minor specification changes.

In this email, I will address just the process control corner cases.

While implementing the proof-of-concept simulator, we have discovered a number of corner-case interactions between the process control methods where the LRM is currently ambiguous. On further investigation, we have uncovered some deep issues that we have been unable to resolve based on the statements given in the LRM as it stands. It may be that a deeper analysis of the use cases for the process control methods might provide a resolution, but in the absence of that analysis, we propose that certain interactions between the process control methods become implemention-defined in the LRM. This will leave room for more specific semantics to be defined in the future as and when the uses cases are clarified.

We propose the following clarification to the LRM, which is NOT implementation-defined: The six methods suspend, resume, disable, enable, sync_reset_on, sync_reset_off set and clear the values of three independent flags, regardless of the order in which those methods are called, and taking precedence over the corner cases identified below. For example, given two successive calls to resume() with no intervening call to suspend(), the second call would be a no-op.

We then propose that in each of the following corner cases, the behavior is implementation-defined (and the OSCI PoC simulator will emit an error for the time being)

  1. Attempting to resume a target process that is disabled. (That is, attempting to move a process from the state where the suspend flag is true and the disabled flag is true to the state where the suspend flag is false.)

  2a. Attempting to put a target process that is suspended into the synchronous reset state (including a call to sync_reset_on or a synchronous or asynchronous reset signal going active)

  2b. Attempting to suspend a target process that is in the synchronous reset state (as a result of a call to sync_reset_on or a synchronous or asynchronous reset signal being active)

  3. Attempting to disable a target process that is waiting with a time-out (whether or not the time-out is accompanied by an event or an event list)

In effect, because of the error emitted by the PoC simulator, we are putting a guard band around the above set of corner-cases in order to shield the user from the following unexpected interactions:

  1. The alternative would be running a process while it was disabled, or running a process when enable was called, or ignoring resume, any of which would be surprising to the user

  2. The alternative would leave an ambiguity concerning when the synchronous reset was sampled: at the time of the event that caused the process to be resumed, or at the time the process was actually resumed. Either would be surprising to the user.

  3. The alternative would lead to orphaned processes, where a process could not become runnable again unless it were reset.


The above is the proposed resolution. Does anyone object or have further specific comments?

Thanks,

John A


-----owner-systemc-p1666@eda.org wrote: -----
To: "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org>, "systemc-p1666@eda.org" <systemc-p1666@eda.org>
From: Stan Krolikoski
Sent by: owner-systemc-p1666@eda.org
Date: 04/26/2011 03:58PM
Subject: P1666 Ballot resolution discussion
Hi,

As most of you know by now, the P1666 LRM passed the initial Ballot unanimously. However, there were several issues discovered that must now be “resolved” before the “Recirculation Ballot” can start. John Aynsley has proposed solutions to each of the issues that he will be explaining on the P1666 technical reflector.

I want to ensure a high quality LRM, but also want to make sure that the review process is not open-ended. With this in mind, comments/discussions on John’s fixes will be allowed during the next 10 days, i.e. until 5 PM PDT on Friday May 6, and those discussions will only cover the issues that were discovered during the P1666 Balloting process. New issues will be turned over to the OSCI Language Working Group.

Stan




[cid:image002.jpg@01CC058E.90193DD0]



Stan Krolikoski | Group Director IP/EDA Standards & Alliances,
                                Strategic Business Alliances

P: 1.408.944.7260 M: 1.925.336.9343 www.cadence.com<http://www.cadence.com>











--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
=
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.