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 > >Received on Sun Dec 10 00:04:37 2006
This archive was generated by hypermail 2.1.8 : Sun Dec 10 2006 - 00:05:25 PST