Resending, as it never made it to the reflector
________________________________________
From: Jeremiassen, Tor
Sent: Friday, May 14, 2010 10:53 AM
To: 'David C Black'; john.aynsley@doulos.com
Cc: Jerome CORNET; systemc-p1666-technical@eda.org
Subject: RE: Process Control Extensions
David,
I think this is an issue that we need to work through in the OSCI working groups. I'm not convinced it even belongs in the CCI working group, as that is a working group that focuses on tool to model interfaces. This is really an interface from the tool to the simulator (which may be integrated to some degree in the tool). Unless we introduce process priorities as a mandatory, functionality related change in SystemC I don't see the need for bringing it into P1666, or for that matter OSCI CCI WG.
Best regards,
Tor
--- Tor Jeremiassen, Ph.D. Simulation and Modeling CTO SDO Foundational Tools Texas Instruments Ph: 281 274 3483 P.O. Box 1443, MS 730 Fax: 281 274 2703 Houston, TX 77251-1443 Email: tor@ti.com ________________________________________ From: David C Black [mailto:dcblack@xtreme-eda.com] Sent: Friday, May 14, 2010 9:58 AM To: john.aynsley@doulos.com Cc: Jeremiassen, Tor; Jerome CORNET; systemc-p1666-technical@eda.org Subject: Re: Process Control Extensions Perhaps this concept is better left as a feature that is accessible via the CCI API. In other words, a specific simulator implementation might have some parameters settable via the CCI to invoke randomized process ordering or provide simulator process hints. The user could communicate process names via the CCI along with their priorities. The advantage to such an approach is that code supporting the feature need not be tied into the compilation of your code. Of course I am assuming we don't need to dynamically change the priority hints (i.e. only something you do during setup early or prior to the beginning of simulation. Comments? On May 14, 2010, at 9:10 AM, john.aynsley@doulos.com wrote: Tor, I sympathize with that view, but I am swaying in the direction that everything we want to do regarding process execution order is non-functional; it concerns either simulator performance or providing some tool assistance to detect accidental reliance on process ordering artefacts. Maybe every simulator that implements priority tips should also be obliged to switch to random process selection from time-to-time, or at least provide it as a run-time switch 8=) John A From: "Jeremiassen, Tor" <tor@ti.com> To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, Jerome CORNET <jerome.cornet@st.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org> Date: 14/05/2010 15:01 Subject: RE: Process Control Extensions ________________________________________ All, I am having some reservations with respect to the whole process priority concept. I think my problems are rooted in the fact that it would be a hint that would be optional to support in a simulator. A programmer may easily write models targeting this behavior such that the behavior of the model is different on a simulator supporting the process priority scheme compared to one that does not. While we may claim that such a model is non-conforming, it fails to prevent the eventual development of an "island of compatibility" and will, I suspect, reduce de facto interoperability. As a concept, I think process priorities would be a valuable addition to SystemC. However, I do believe that if we are going to add them, we need to make it mandatory, and we really need to take care in how we formulate the scheme. I am not convinced that P1666 is the right place for doing this, though if that is the members' wishes, I'll happily pitch in. Best regards, Tor Jeremiassen --- Tor Jeremiassen, Ph.D. Simulation and Modeling CTO SDO Foundational Tools Texas Instruments Ph: 281 274 3483 P.O. Box 1443, MS 730 Fax: 281 274 2703 Houston, TX 77251-1443 Email: tor@ti.com ________________________________________ From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com Sent: Friday, May 14, 2010 6:23 AM To: Jerome CORNET; systemc-p1666-technical@eda.org Subject: Re: Process Control Extensions Jerome, Does ST foresee the process priority hint being used as a way to produce pseudo-random process execution order within an evaluation phase as a way of improving test case coverage? If this were the case then a simulator that supports the "priority hint" would have superior capability going beyond mere simulation speed. I don't see a problem with this. We could even add a set_priority_random() ! John A From: Jerome CORNET <jerome.cornet@st.com> To: "Jeremiassen, Tor" <tor@ti.com> Cc: Stuart Swan <stuart@cadence.com>, "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org> Date: 11/05/2010 09:19 Subject: Re: Process Control Extensions ________________________________________ Tor, all, sorry, my explanation was lacking real-world numbers which I will fix right away. So, I will take again the example of a SystemC TLM platform interacting with an IP mapped on a hardware emulator. We have many such platforms at ST. Let us consider the following scenario: the system produces images in loop. To do this it depends on results computed by the IP mapped on the emulator, as well as computations performed by the embedded software itself. In other words, the embedded software "delegates" part of the computation to the IP in the emulator, then perform its own duties. It takes some time for the hardware IP to perform its computation and send back the result. In our typical case, we are at around 1 fps (depends on the frame resolution). And on the embedded software front, we are now running into situations where the embedded software execution itself takes more and more time. All in one, this results in increased workstation time taken to complete an evaluation phase of the scheduler (as the main process executing the embedded software is taking more and more time). In some situations, the evaluation phase takes more than one second (1.6 to be precise). The result of the benchmark really depends on the process order execution chosen by the scheduler, and may change if you add other processes in the loop. But it is obvious that we have to prioritize the processes that will result in the IP on emulator starting its computations, as the sooner it will start the better. The worst case is if the emulator starts at the end of the evaluation phase, as we then add 1 second of penalty waiting for the result. With the numbers I given that is one second in addition to 1.6 already taken by the SystemC simulation. So in this example we can gain (or lose depending on which side you look at it) up to 62 % percent per evaluation phase. Process priorities ensures that you will never lose anything, whatever the process execution order is, and provided you have got a "priority-aware" simulator. I have focused here on the hardware emulator example, but there is room to exploit this feature in many other situations. Regards, Jerome On 5/8/2010 5:43 AM, Jeremiassen, Tor wrote: I'm not going to oppose this, but has ST done any benchmarking with respect to the utility of such a proposal? It would be good to have some quantitative idea of the possible performance benefit before making it part of the standard. Best regards, Tor Jerermiassen --- Tor Jeremiassen, Ph.D. Simulation and Modeling CTO SDO Foundational Tools Texas Instruments Ph: 281 274 3483 P.O. Box 1443, MS 730 Fax: 281 274 2703 Houston, TX 77251-1443 Email: tor@ti.com ________________________________________ From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of Stuart Swan Sent: Friday, May 07, 2010 11:58 PM To: john.aynsley@doulos.com; systemc-p1666-technical@eda.org Subject: RE: Process Control Extensions John, All- I think I'm in favor of the process priority "hints", as long as it is absolutely clear in the standard that they are just hints and that a compliant implementation is always free to ignore them. Thanks Stuart From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com Sent: Friday, May 07, 2010 4:00 AM To: systemc-p1666-technical@eda.org Subject: RE: Process Control Extensions All, Does anyone have any specific objections or counter-proposals concerning the Process Control Extensions, or is everyone positive about them as they stand? (Of course, I am not trying to rule out any improvements or clarifications as we refine the spec.) How about ST's proposal for process priorities as hints? Adding actual process priorities to SystemC would seem to be a radical change that would impact the scheduler, process control, and might introduce the possibility of new use models. On the other hand, ST's proposal is only for "hints", in which case, do we want to change the IEEE standard "merely" to incorporate scheduler optimization hints? Thanks, John A -----Stuart Swan <stuart@cadence.com> wrote: ----- To: "john.aynsley@doulos.com" <john.aynsley@doulos.com>, "systemc-p1666-technical@eda.org" <systemc-p1666-technical@eda.org> From: Stuart Swan <stuart@cadence.com> Date: 05/06/2010 10:05PM Subject: RE: Process Control Extensions John- Some quick answers embedded below to your questions.. Thanks Stuart From: owner-systemc-p1666-technical@eda.org [mailto:owner-systemc-p1666-technical@eda.org] On Behalf Of john.aynsley@doulos.com Sent: Wednesday, May 05, 2010 7:18 AM To: systemc-p1666-technical@eda.org Subject: Process Control Extensions Issues/Questions * Should we now deprecate SC_CTHREAD or keep SC_CTHREAD as a first-class feature of SystemC, or something else? SC_CTHREAD has been around for so long that it won't go away anytime soon. One option is to say something in the LRM such as "SC_CTHREAD is now redundant since all of its features are now available with SC_THREAD, so SC_CTHREAD may be deprecated and removed from the standard at some point in the future." * Should we invite input from the members of the OSCI Synthesis WG on the subject of clocked threads and synchronous and asynchronous resets? * ST (Jerome) has proposed that we add process priorities. Does this P1666 WG wish to pursue that proposal? If so, how do process priorities interact with the process control extensions? If I understood Jerome's proposal, the priorities are just "hints" and can always be ignored. So it seems to me one option is to say that from the perspective of the process control extensions, the priorities have no implications on the standard. * Is include_descendants intended to find descendents of intermediate processes that have already terminated, i.e. children of dead children? I think it is supposed to get them all, Bishnupriya needs to confirm. * Do we need to try out these ideas in a proof-of-concept implementation, particularly given that the process control extensions are already (at least partially) implemented in the OSCI POC simulator? I will volunteer to create a set of regression tests. We accept your offer! Having such openly available tests will be very helpful in getting the features implemented properly in all simulators. We have donated some tests for process control constructs to OSCI. More tests are clearly needed. We have also implemented all of the constructs in our simulator and will run any tests that people offer against our implementation and provide the log results. John A -- 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. -- 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 C Black, XtremeEDA ESL Practice Leader http://www.Xtreme-EDA.com (Consulting, Services & Training for all your ESL, verification and DFT needs) Voice: 512.850.4322 Skype:dcblack FAX: 888.467.4609 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon May 17 13:30:28 2010
This archive was generated by hypermail 2.1.8 : Mon May 17 2010 - 13:30:28 PDT