<resending - there were some bounces earlier today. Hopefully this one goes thru> -------- Original Message -------- Subject: Re: [sv-ec] Program Block / Reactive Region Use Cases & Requirements Date: Tue, 12 Dec 2006 11:45:29 -0800 From: Michael Burns <michael.burns@freescale.com> To: Slater Rob-R53680 <R.Slater@freescale.com> CC: sv-ec@eda.org References: <AE0260ADCB748A4B8FE092E3AA7E0670B8DF71@zil05exm11.fsl.freescale.net> Hi folks, I would like to separate the backwards compatibility into two separate issues - I believe they're getting a little mixed. First, this idea about making the program a procedural block rather than a hierarchical structure - I don't believe this is part of the overall program block semantics proposal, at least not yet. If the hierarchical structure is proposed to be eliminated in favor of the procedural program block, clearly that would break compatibility with 1800-2005. I'd expect this to be proposed as an additional syntax rather than a replacement (if possible - there may be a conflict with hierarchical program constructs defined in modules as allowed in 1800-2005). Second, it has come to my attention (from a discussion with Rob Slater) that the new program block semantics proposal as it is now may have a backwards compatibility issue as well. In 1800-2005, when program code makes a nonblocking assignment to a module variable, the module variable update event is scheduled in the NBA region (1800-2005 doesn't explicitly state this as far as I can find, but there's no other place to put it that makes sense). Presumably, this update occurs in the same timestep, but in the next "delta cycle" (e.g, in the next pass through the "outer loop" of the reference algorithm). The new proposal, however, says that since the assignment is happening in a program thread, the update is scheduled to occur in the new re-NBA region. The possible difference I see is in what happens after these program-created NBA updates; today, the design gets to go first (e.g., we go around the "big loop"), whereas with the new proposal, the testbench goes first (e.g., we go around the "small loop"). Here's an example: // the DUT module foo; reg a; // If someone turns on a, turn it off immediately. always @ (posedge a) a = 0; endmodule // the testbench program bar; // "driver" thread - just turn on foo.a at time 1. initial begin foo.a <= 0; #1 foo.a <= 1; end // "monitor" thread - look for foo.a being 1. initial forever @ (foo.a) if (a) $display("Saw 1 on foo.a"); end endprogram I believe that for this example, a simulator compliant to the new proposed semantics must display "Saw 1 on foo.a" whereas a simulator compliant to 1800-2005 must not. In other words, the new semantics changes the behavior of the monitor thread from missing the glitch to catching it. This kind of code is certainly not how anyone's recommending that testbenches or designs ought to be written; nonetheless, we cannot claim backwards compatibility with old standards if there are any cases for which it's broken. Furthermore, this behavior difference is not due to races coming out differently; 1800-2005 defines one unambiguous order for events in the above example, and the new proposal defines a different unambiguous order. Unless I've got this all wrong :) --Mike Slater Rob-R53680 wrote: > Hi, > > Dave below mentions that "[...] it breaks backwards compatibility with > something that was already broken." Is there agreement that the new > proposal breaks backward compatibility? > > If so, should the committee issue a warning about this so EDA companies > and their customers are forewarned? > > > Rob Slater > Freescale Semiconductor > > > -----Original Message----- > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > Rich, Dave > Sent: Friday, December 08, 2006 4:12 AM > To: Burns Michael-RA4884; Ryan.S.Warner@seagate.com > Cc: sv-ec@eda.org > Subject: RE: [sv-ec] Program Block / Reactive Region Use Cases & > Requirements > > See comments below > >> -----Original Message----- >> From: owner-sv-ec@server.eda.org [mailto:owner-sv-ec@server.eda.org] > On >> Behalf Of Michael Burns >> Sent: Thursday, December 07, 2006 2:08 PM >> To: Ryan.S.Warner@seagate.com >> Cc: sv-ec@server.eda.org >> Subject: Re: [sv-ec] Program Block / Reactive Region Use Cases & >> Requirements >> >> >> Hi folks, >> >> I have two comments (actually, the second is a question): >> >> 1. The syntax of this proposal would seem to break backwards > compatability >> with >> the existing 1800-2005 spec. > [DR>] But it breaks backwards compatibility with something that was > already broken. You are already in a heap of trouble if your threads > cross between programs and modules. > > I like this idea - basically the program is >> syntactically analogous to an initial or always rather than a module, >> correct? >> Too bad it wasn't done that way to begin with... >> >> 2. [general question, not specific to this proposal] With the new > proposed >> program execution semantics, is the clocking block now the one and > only >> way for >> a reactive thread to read and write values in the active/inactive/NBA >> update >> regions? > [DR>] I think so. As long as the clocking block s defined outside of a > program. >> 3. [I thought of another question] If a reactive testbench wanted to >> respond to >> some design event in zero time (e.g., TB sees a signal change on the > DUT >> and >> wants to drive a response back into the DUT in the same simulator > cycle), >> is >> this possible? I assume that if it was, it would at least entail a > "delta >> cycle" >> delay; is this the case? > [DR>] Yes, this is no different then using active/NBA events. But you > can't using clocking blocks or .triggered events because they require > time to advance. > > >> Thanks, >> Mike Burns >> >> Ryan.S.Warner@seagate.com wrote: >>> With the discussion of the region a task runs in being ruled by > where >> the >>> thread was started, let me propose an alternative to the possibility > for >>> the program block. It should just define a reactive process. So > the >>> following would be equivalent: >>> >>> // P1800 >>> program tb; >>> initial begin >>> // reactive process >>> end >>> endprogram >>> >>> // suggested change >>> module tb; >>> program begin >>> //reactive process >>> end >>> endmodule >>> >>> This is essentially what is being proposed anyway, correct? This > always >>> seemed the most natural representation of a program to me anyway. > It is >> a >>> thread (or set of threads), not a physical piece of hierarchy. >>> >>> Please correct me if I'm wrong here. But under the current > proposal, I >>> could put my entire testbench in modules (using classes if desired) > and >>> have it run in the reactive region. I'd just need an artificial > level >> of >>> hierarchy containing the program to start the testbench thread. In >> other >>> words: >>> >>> class sys_env extends rvm_env; >>> // blah blah >>> endclass >>> >>> > //---------------------------------------------------------------------- >> -- >>> //What I want to happen based on what I expect SV3.1 and P1800 today >>> automatic program sys_tb; >>> sys_env env; >>> initial begin >>> env = new; >>> env.run(); >>> end >>> endprogram >>> >>> module top; >>> sys_tb tb; >>> endmodule >>> >>> > //---------------------------------------------------------------------- >> -- >>> // Proposed change allows >>> program start_tb; >>> initial begin >>> top.env = new; >>> top.env.run(); >>> end >>> endprogram >>> >>> module top; >>> sys_env env; >>> start_tb start; >>> endmodule >>> >>> >>> > //---------------------------------------------------------------------- >> -- >>> // I propose >>> module top; >>> sys_env env; >>> program begin >>> env = new; >>> env.run(); >>> end >>> endmodule >>> >>> Regards, >>> Ryan Warner >>> ryan.s.warner@seagate.com >>> > > > -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-720-4852 Senior Staff Engineer Fax: 408-720-4850 Frontend Technologies - ASICs & Processors (FTAP) Sun Microsystems email: neil.korpusik@sun.com ---------------------------------------------------------------------Received on Tue Dec 12 14:25:33 2006
This archive was generated by hypermail 2.1.8 : Tue Dec 12 2006 - 14:25:47 PST