Hi all, I am deeply sorry. While reviewing the newest draft I did some cleaning up of my SV-EC email folder, and this stuff must have been slipped somewhere between my fingers. :-[ This is problem when you have about 50 mail filters to conquer somewhat the amount of email flooding into your account ... :-( To answer Stu's question: In my humble opinion (IMHO), it is not possible to fully and explicitely state into which region of a future time step an event is scheduled by VPI/PLI and DPI. The simple reason is that there are various ways to schedule an event, and if we do so, we might end up with changing the semantics of the related code to do so. Saying this, I consider "time step" as being equal to "time slot" of the corresponding reference algorithm, with the meaning that time[time slot A] != time[time slot B]. Since there is no real naming notation for the various possible simulation iterations defined by the scheduling semantics I use the following home-brewn within this email: - time slot: all simulation data processing at an unique time, basically related to the execute_time_slot() function of the reference algorithm. This means every time slot has its unique time. - delta cycle: all processing done within one iteration of the outer loop of the execute_time_slot() function - design cycle: all processing done within one iteration of the first inner loop of a delta cycle; _excluding_ the observed region. This means there is an inner loop from Active until Post-NBA. - testbench cycle: all processing done within one iteration of the second inner loop of a delta cycle However, within a particular time slot, this story is very much different. Here I believe we can and should restrict the influence that is possible by the VPI/PLI and DPI functions. It should be possible to control this relatively easy within the functions that can create events. The provided wording intended to restrict the effect of scheduling an event in this region to take effect only for a later time slot; however it might make sense to also permit a future delta cycle instead of only another time slot here. In any case it should never occur before the next delta cycle. As you already indicated I believe there is a similar ambiguity with some other PLI regions. E.g. I am not sure the arrows in the Figure 4-1 are correct w.r.t. the PLI regions pre-NBA, NBA, post-NBA and also pre-observed, observed, and post-observed. IMHO pre-NBA must always be executed _before_ NBA, and post-NBA must always be executed _after_ NBA. This would mean there is a feedback path only after post-NBA, but not by any of the three regions. Similar applies to the [pre-/post-]observed regions. Otherwise an event scheduled in pre-NBA would result in some more Active-Inactive execution before actually calling NBA; and also an event scheduled in NBA would not permit post-NBA to be called before calling the Active-Inactive regions again. IMHO, the series pre-NBA/NBA/post-NBA and pre-observed/observed/post-observed should be always executed as a single region. But this is a different discussion. I believe this is an area where the SV-CC committee should soon bring some clarity and supply the required definitions. I will try to start some discussion here during the next meeting. Saying this I just discovered that the pre-observed region disappeared from the draft 2. Is that intentional ? Hope this describes the original request. Best regards, -Michael Francoise Martinolle wrote: > > Michael, > > we need to answer Stu's question. > > > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > Stuart Sutherland > Sent: Wednesday, February 14, 2007 2:58 PM > To: 'Michael Rohleder'; 'Clifford E. Cummings' > Cc: sv-ec@eda.org; sv-ac@eda.org; sv-cc@eda.org > Subject: [sv-ec] RE: [sv-cc] PDF version of clean Scheduling Proposal > > Michael, > > I agree that a Pre-Observed region could be useful. I would like > clarification on the wording: > > >> - it has similar semantics than the Pre-Active region, in particular >> it can not schedule any >> event into the same time step (there is no path back to the Active >> region). >> > > This implies, but does not explicitly state, that the Pre-Observed > region could schedule an event in a future time step. If so, the region > in the future time step in which the event is scheduled should be > specified. I cannot be a future Pre-Observed region, since that has no > feedback path. > > I haven't looked, but there may be a similar ambiguity about where > future events are scheduled by PLI routines called from any other region > other than the Active region. > > Stu > ~~~~~~~~~~~~~~~~~~~~~~~~~ > Stuart Sutherland > Sutherland HDL, Inc. > stuart@sutherland-hdl.com > 503-692-0898 > > > >> -----Original Message----- >> From: owner-sv-cc@server.eda.org >> [mailto:owner-sv-cc@server.eda.org] On Behalf Of Michael Rohleder >> Sent: Wednesday, February 14, 2007 10:31 AM >> To: Clifford E. Cummings >> Cc: sv-ec@server.eda.org; sv-ac@server.eda.org; sv-cc@server.eda.org >> Subject: Re: [sv-cc] PDF version of clean Scheduling Proposal >> >> Hi Cliff, >> >> many thanks for sending this. >> >> This email contains some feedback about this document, and it is split >> > > >> into an official part (discussed within SV-CC) and a second part >> containing just feedback from myself. >> >> *Official part:* >> After reviewing the current proposal I have raised the request to add >> an additional PLI region (proposed name Pre-Observed) that has the >> following behavior: >> - it is a PLI-only region >> - it is called immediately before entering the Observed region >> - it has similar semantics than the Pre-Active region, in particular >> it can not schedule any >> event into the same time step (there is no path back to the Active >> region). I am not sure >> what is the best phrasing here; the one in the Preponed region >> might be too restrictive ... >> >> We have discussed this within SV-CC and this request has been accepted >> > > >> by the committee. >> >> The reason for this request is that I believe a callback is required >> and useful when the design has fully settled, but there is not yet any >> > > >> activity created by the testbench or assertion side. Post-NBA is not >> useful, because you don't know whether this is the last iteration of >> the 'inner' design loop. Post-Observed is not useful, because the >> assertions may have created new events already. This new region must >> not create new event for the same time step to avoid situations where >> two tools are fighting to be the last one invoked after the design has >> > > >> settled. >> >> I hope this is sufficient. Let me know when you want to have an update >> > > >> in the official format. >> >> *Second part:* >> >> There was some focus on creating a consistent naming of the regions. >> However I don't understand >> why the region "Reactive" was not renamed to be "Re-Active". >> All regions >> but this one use the Re- >> prefix. I am not really religious here, but this looks interesting to >> me. >> >> That's all. >> >> Best regards, >> -Michael >> >> >> Clifford E. Cummings wrote: >> >>> Sorry - >>> >>> I meant to send the PDF version of the clean event scheduling >>> proposal. Attached. >>> >>> Regards - Cliff >>> >>> ---------------------------------------------------- >>> Cliff Cummings - Sunburst Design, Inc. >>> 14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005 >>> Phone: 503-641-8446 / FAX: 503-641-8486 cliffc@sunburst-design.com / >>> > > >>> www.sunburst-design.com Expert Verilog, SystemVerilog, Synthesis and >>> > > >>> Verification Training >>> >>> >> >> -- >> 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. > > > -- NOTE: The content of this message may contain personal statements which are not neccessarily the view of Freescale, unless specifically stated. ___________________________________________________ | | | Michael Rohleder Tel: +49-89-92103-259 | / )| Principal Staff Engineer Fax: +49-89-92103-101 |( \ / / | Freescale Semiconductor, www.freescale.com | \ \ _( (_ | _ New Product Development Center _ | _) )_ (((\ \>|_/ > Schatzbogen 7, D-81829 Muenchen, Germany < \_|</ /))) (\\\\ \_/ / mailto:michael.rohleder@freescale.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \ This e-mail, and any associated attachments have been classified as: [ ] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary Freescale Halbleiter Deutschland GmbH Schatzbogen 7 D-81829 Muenchen www.freescale.com Sitz der Gesellschaft/Registered Office: Muenchen Registergericht/Registered Court: Amtsgericht Muenchen HR B 151590 Geschaeftsfuehrer/General Manager: Juergen Weyer, Karen Roscher, John Pence, Oliver Kaltenbach, Andreas Wild USt.-ID-Nr./VAT-ID-No. DE813898243 Steuernummer/Tax No. 143/138/30552 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Apr 11 05:51:23 2007
This archive was generated by hypermail 2.1.8 : Wed Apr 11 2007 - 05:51:46 PDT