Packages should only contain declarations, presumably those which can be shared by a design. This was the whole point of creating a separate design unit. Packages can be separately compiled and referenced by many designs. Except for variable initial value assignments, no processes were allowed in packages, this is a main differentiator. I think that these limitations should remain. If a process is required, modules should be used. With the following restrictions: no hierarchical reference, no processes, only sharable declarations of objects, types, functions and tasks, a package design unit enforces a better design methodology. If we are allowing processes in packages, we are loosing this benefit. I agree with Dave that this is going to be a slippery slope and soon a package will just be a module. I am against doing this. Francoise ' -----Original Message----- From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Warmke, Doug Sent: Monday, May 22, 2006 2:16 AM To: Arturo Salz; sv-ec@eda.org Subject: RE: [sv-ec] RE: [sv-bc] Final blocks in packages Hi Arturo, Actually my part of the discussion was only exploring what it would take to "keep processes out of packages", as the LRM currently requires: Packages must not contain any processes. Therefore, wire declarations with implicit continuous assignments are not allowed. But you have a valid point: Why does that requirement even exist? Like you, I personally don't see too many problems with that. And it's difficult to enforce, especially with dynamic processes that get spawned by functions and constructors called by package code. (Which basically means variable declaration assignments) Dave has mentioned he doesn't like processes in packages, since that gets in the way of his "slippery slope in the woods" answer. But I think we have all slid down that slope. We have to recognize that package VDA's can unleash side-effects, and we must address those in the LRM in order to maintain implementation compatability. Are there any other reasons people don't like processes in packages? Regards, Doug > -----Original Message----- > From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] > Sent: Friday, May 19, 2006 12:21 AM > To: Warmke, Doug; sv-ec@eda.org > Subject: RE: [sv-ec] RE: [sv-bc] Final blocks in packages > > Doug, > > I'm sorry. I forgot to put the fork in my example. It should have > been: > > package p; > event ev; > task wait_for_ev(); > fork > @ev; > join_none > endtask > endpackage > > You also write that "they need to be kept out of packages", and later > you state that it would be OK to call such code from some other scope > (module or program). So I assume that we do agree that the existing > language is too restrictive. > > I understand that initial blocks, always blocks, and continuous > assignments are currently not allowed in packages. > And I'm OK with that limitation although I don't believe it is > fundamental in any way. In fact, if your final block proposal passes, > people will likely wonder about the lack of symmetry (why not allow > initial blocks as well). I think the only truly problematic construct > is the continuous assignment. > > So what's so problematic about a process originating within a package? > > As for the debate regarding thread vs. declarative scope in the > reactive region scheduling discussions, I didn't think we had enough > time to work out a change in the semantics at the time. But, I'd be > happy to revisit the decision. > > Arturo > > -----Original Message----- > From: Warmke, Doug [mailto:doug_warmke@mentor.com] > Sent: Thursday, May 18, 2006 11:38 PM > To: Arturo Salz; sv-ec@eda.org > Subject: RE: [sv-ec] RE: [sv-bc] Final blocks in packages > > Arturo, > > The event control operator is not defined as a Verilog process. > In referring to Clause 11 on Processes, only "initial" and "always" > are described as Verilog static processes. Then the > always_comb/always_latch/always_ff family are added as SV static > processes. Finally, dynamic processes are discussed. > > Here is some pertinent text from later in Clause 7. > > 11.7 Process execution threads > SystemVerilog creates a thread of execution for the following: > - Each initial block > - Each always block > - Each parallel statement in a fork...join (or join_any or > join_none) statement group > - Each dynamic process > Each continuous assignment can also be considered its own thread. > > These are the things that need to be kept out of packages. > I agree that limiting constructs like event control, delay control, or > wait statements would be a serious limitation. > The current wording does not do that, since it explicitly discusses > only legitimate process types. > > In thinking more about my proposal, though, I thought of another > problem that probably needs some attention: > > The problem is that for an arbitrary task or function in a package, > that task or function may be simply imported into a module scope. > And called within that scope. In that case, it should be perfectly > fine if the task or function spawned dynamic processes. My wording > would cut off this possibility, which I don't think is a good thing. > Imposing this restriction might be worth it in order to gain strong > and clear semantics around thread creation in package scope, but we > can probably do better. > > Somehow the proposal needs to state that a process execution thread > cannot *originate* within a package. That may be difficult to do, > given the extensive debate on thread vs. > declarative scope that occurred in the reactive region scheduling > discussions last year. > > Regards, > Doug > > > > > -----Original Message----- > > From: Arturo Salz [mailto:Arturo.Salz@synopsys.com] > > Sent: Thursday, May 18, 2006 11:03 PM > > To: Warmke, Doug; sv-ec@eda.org > > Subject: RE: [sv-ec] RE: [sv-bc] Final blocks in packages > > > > Doug, > > > > By "implicit process" I meant a process that is not explicitly > > initiated by user code, such as a continuous assign. I consider a > > fork/join (in any flavor) as an explicit process, regardless of > > whether it happens in a constructor or some other task. > > > > I strongly disagree with the your new wording, in particular the > > restriction on fork/join_* in any procedural code within > the package. > > That restriction would make it illegal to write any kind of > monitor or > > time-consuming transactor in a package. Are you really > suggesting we > > disallow something like: > > > > package p; > > event ev; > > task wait_for_ev(); > > @ev; > > endtask > > endpackage > > > > Your suggested wording does remove the ambiguity, but it > might render > > packages useless for many applications. > > Ultimately, I don't understand if there's even a problem with code > > residing in packages creating processes. Is there a problem? I'd be > > happy to write a proposal to reword the paragraph, but I'd like to > > understand the issues. > > > > Arturo > > > > -----Original Message----- > > From: Warmke, Doug [mailto:doug_warmke@mentor.com] > > Sent: Tuesday, May 16, 2006 7:50 AM > > To: Arturo Salz; Rich, Dave; Brad Pierce; sv-ec@eda.org > > Subject: RE: [sv-ec] RE: [sv-bc] Final blocks in packages > > > > Arturo, > > > > The LRM doesn't mention the term "implicit process". > > By that, do you mean a dynamic process created in the class > > constructor code? > > > > If so, I think the LRM already covers this, although it could be > > worded better. From 19.2: > > > > Packages must not contain any processes. > > Therefore, wire declarations with implicit > > continuous assignments are not allowed. > > > > This could be changed to: > > > > Packages shall not contain any processes, > > whether static or dynamic. Therefore the use > > of any continuous assignment (whether implicit > > or explicit) is not allowed. Neither is the > > use of fork/join_none or fork/join_any in > > procedural code declared in a package. > > > > In a certain way I don't like the detailing in the last two > sentences, > > since it's not strictly necessary, and might be construed as an > > inclusive list of forbidden constructs. > > However, in the absence of those sentences I could see potential > > ambiguity, so I prefer to have them than not have them. > > > > Note that since packages can't include hierarchical > references to any > > non-package items, the final sentence is sufficient to forbid all > > dynamic process creation by any code executed from within a package. > > > > If someone wants to take a swag at writing a better version of this > > paragraph, I would turn it into a proposal and submit a Mantis item > > for it. > > > > Note that I'd still like to see final blocks in packages as an > > exception to this rule, for the reasons mentioned in > > http://www.eda.org/sv-bc/hm/4421.html. > > > > Regards, > > Doug > > > > > > > > > -----Original Message----- > > > From: owner-sv-ec@server.eda.org > > > [mailto:owner-sv-ec@server.eda.org] On Behalf Of Arturo Salz > > > Sent: Monday, May 15, 2006 2:06 PM > > > To: Rich, Dave; Brad Pierce; sv-ec@server.eda.org > > > Subject: RE: [sv-ec] RE: [sv-bc] Final blocks in packages > > > > > > Dave is correct. The LRM allows any type data of > initialization in > > > packages. It does not distinguish class constructors from > any other > > > type of function. The LRM does disallow processes within > > packages, but > > > the language is unclear since it does not specify what "contain a > > > process" > > > means. Does it mean a task containing statements that can > > fork off a > > > process, or does it mean implicitly initializing a process > > --- as, for > > > example, described by the following sentence regarding continuous > > > assignments. Prohibiting any sort of process from within a > > package may > > > be too restrictive and perhaps arbitrary. This language is > > in need of > > > clarification. > > > > > > As for Doug's original question, initializing class variables in > > > packages is definitely useful, though most of the time the > > objects are > > > not created --- instead, they are initialized to null. > > There are some > > > uses for starting processes from within a class; typically > > some sort > > > of monitor. But that type of implicit process creation is > > rare because > > > typically tests exhibit other order dependencies --- e.g., the > > > environment and configuration must be initialized first. Usually, > > > transactors are started under explicit user control. > > > Therefore, I think > > > that a restriction to disallow implicit process creation > > with packages > > > is not a bad thing at this time. As Doug wrote, if we > > discover a use > > > model that requires such a feature, we can consider relaxing this > > > restriction. > > > > > > Arturo > > > > > > -----Original Message----- > > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On > Behalf Of > > > Rich, Dave > > > Sent: Monday, May 15, 2006 1:25 PM > > > To: Brad Pierce; sv-ec@eda.org > > > Subject: [sv-ec] RE: [sv-bc] Final blocks in packages > > > > > > Responding to just sv-ec to keep the traffic down, > > > > > > I talked with Doug earlier today and we came to the > conclusion that > > > calling a constructor is no different than initializing > any kind of > > > variable with a function call, all of which is currently legal. > > > > > > What's currently illegal in a package is anything within > > the language > > > that creates a thread. The PLI, of course, can do lots of > > things that > > > can't be done through the source text. > > > > > > Dave > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: owner-sv-bc@server.eda.org > > [mailto:owner-sv-bc@server.eda.org] > > > On > > > > Behalf Of Brad Pierce > > > > Sent: Monday, May 15, 2006 12:40 PM > > > > To: sv-ec@server.eda.org > > > > Cc: sv-bc@server.eda.org > > > > Subject: Re: [sv-bc] Final blocks in packages > > > > > > > > Doug, > > > > > > > > Is it legal today to initialize class variables in a > > package scope? > > > > > > > > -- Brad > > > > > > > > -----Original Message----- > > > > From: Warmke, Doug [mailto:doug_warmke@mentor.com] > > > > Sent: Monday, May 15, 2006 7:57 AM > > > > To: Vreugdenhil, Gordon; Brad Pierce > > > > Cc: sv-bc@eda.org > > > > Subject: RE: [sv-bc] Final blocks in packages > > > > > > > > Hi all, > > > > > > > > One question that has come to my mind during this debate: > > > > > > > > How useful do folks feel it would be to allow the > > initialization > > > > of class variables declared in package scope? > > > > > > > > I can personally envision some uses of that construct. > > > > But I'm wondering if other people are already using it or are > > > > planning on using it? If it turns out to be a very > > useful or high > > > > demand feature, it will be worth investing some time into > > exploring > > > > "threads in packages" more deeply. > > > > > > > > If folks don't care about it too much, then we should lower the > > > > priority on the discussion. > > > > > > > > One thing to watch out for, though, is letting the barn > door open > > > > too early. If some implementations do allow the use of > "new" in > > > > package VDA's, then we will likely have to deal with > all this at > > > > some point in the future, and it could be thorny. > > > > > > > > Regards, > > > > Doug > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: owner-sv-bc@server.eda.org > > > > > [mailto:owner-sv-bc@server.eda.org] On Behalf Of > > > Vreugdenhil, Gordon > > > > > Sent: Wednesday, May 10, 2006 10:15 AM > > > > > To: Brad Pierce > > > > > Cc: sv-bc@server.eda.org > > > > > Subject: Re: [sv-bc] Final blocks in packages > > > > > > > > > > > > > > > > > > > > Brad Pierce wrote: > > > > > > > > > > > Do variable declaration assignments in a package occur > > > only if the > > > > > > variable is imported? > > > > > > > > > > > > > > > If the "variable" is imported? No - that would be far > > to fine a > > > > > granularity to handle. Package dependencies are > > determined at the > > > > > "package" level -- as far as I am concerned, if a > > package is used > > > > > in the design (referenced in an import or included via > > some other > > > > > vendor mechanism) then all of its initializations occur. A > > > > > reference to the package is sufficient -- no actual > > import needs > > > > > to occur. Obviously, as with any declaration, if the > effect of > > > > > the initialization is not observable in the design, an > > > > > implementation can optimize such initialization away. > > > > > > > > > > > > > > > Gord. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- Brad > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > > > > > > > From: Rich, Dave [mailto:Dave_Rich@mentor.com] > > > > > > Sent: Tuesday, May 09, 2006 6:40 PM > > > > > > To: Brad Pierce; sv-bc@eda.org > > > > > > Subject: RE: [sv-bc] Final blocks in packages > > > > > > > > > > > > > > > > > > > > > > > > Does someone have to import the package or refer to an item > > > > > in a packed > > > > > > for the final block to execute? I would think so; otherwise > > > > > it would be > > > > > > difficult to manage the exclusion of packages that you did > > > > > not want to > > > > > > execute. > > > > > > > > > > > > > > > > > > > > > > > > Independently of whether final blocks in packages are a > > > > > "good idea", I > > > > > > don't think it is a priority worth discussing right now. > > > > > > > > > > > > > > > > > > > > > > > > Dave > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ---------- > > > > > > > > > > > > From: owner-sv-bc@server.eda.org > > > > > [mailto:owner-sv-bc@server.eda.org] On > > > > > > Behalf Of Brad Pierce > > > > > > Sent: Tuesday, May 09, 2006 6:29 PM > > > > > > To: sv-bc@server.eda.org > > > > > > Subject: Re: [sv-bc] Final blocks in packages > > > > > > > > > > > > > > > > > > > > > > > > Following up on http://www.eda.org/sv-bc/hm/4421.html , > > > > > does any extra > > > > > > text need to be added to explain how final blocks in > > > > > packages execute? > > > > > > > > > > > > > > > > > > > > > > > > In my opinion, no. I think it would be sufficient for a > > > > > proposal only > > > > > > to add final blocks to the 19.2 list of items that can be > > > > > shared via > > > > > > packages and in the BNF to move "final_construct" out of > > > > > its current > > > > > > locations and into "package_or_generate_item_declaration". > > > > > > > > > > > > > > > > > > > > > > > > Independently of whether final blocks in packages is a > > > > > "good idea", does > > > > > > the above seem like a sufficient way to modify the LRM > > > if it were? > > > > > > > > > > > > > > > > > > > > > > > > -- Brad > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > -------------------------------------------------------------------- > > > > > Gordon Vreugdenhil 503-685-0808 > > > > > Model Technology (Mentor Graphics) > > > gordonv@model.com > > > > > > > > > > > > > > > > > > > >Received on Mon May 22 06:33:30 2006
This archive was generated by hypermail 2.1.8 : Mon May 22 2006 - 06:34:00 PDT