Ambar Sarkar wrote: > Dave, > > > > I think I understand the rationale here, especially about rooted > threads. One more question. Given that we do not want functions to > interact with the scheduler, we are in effect forbidding functions to > trigger events as well, correct? Triggering events is very different than blocking on an event. The 1364 text says "contains triggering events" which means "could possibly block waiting on any kind of event". It does not mean "could cause events in other threads to be triggered". By "time consuming" I think that Dave meant "could cause the currently evaluating thread to block and be rescheduled". That is certainly what the structural 1364 restrictions do. Is #0 really "time consuming"? It is certainly illegal in functions. Don't read too much into the "time consuming" phrase. Functions can't cause the thread to block. Fork-join_none is a very odd thing in the context of a function. Since it is non-blocking, one could argue that it should be legal. Since any "thread" within a function fork/join is still constrained by the rules of the function (no blocking), the utility of the construct is pretty limited. In 1800 in particular, you couldn't use a semaphore, call tasks, etc, etc. which means no synchronization activity between the new thread and anything else in the system. For fork-join_none within a function, one could argue that it would be compliant to implement fork-join_none as though it were a fork-join since the conceptual "independent threads" (which can't block) can all be "scheduled" immediately after the "join_none" and before the next sequential statement per LRM scheduling rules. At this point, I think that both the utility of fork-join_none or even fork-join_any is questionable (I don't like fork-join in functions for that reason as well) and since it is likely to cause confusion in the user base, I'd really prefer to just make it illegal. Does anyone have a compelling use model for allowing this? Gord. > > > Just saying that we disallow time-consuming statements in functions > leaves a lot of room for misinterpretation, IMHO. > > > > Regards, > > -Ambar > > > > ------------------------------------------------------------------------ > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > Rich, Dave > Sent: Thursday, February 16, 2006 9:12 AM > To: Ambar Sarkar; sv-ec@eda.org; sv-bc@eda.org > Subject: RE: [sv-ec] Can a function contain a fork/join/any/none? > > > > “time consuming” would mean anything that could block a > thread(process). But there are really two separate issues here. One is > the fact that functions are not supposed to interact with the scheduler. > Events get created outside the function as outputs are assigned, but the > function does no scheduling. We also don’t have to worry about active > region functions versus inactive-region(program block) functions either. > > > > But the other major issue is that time consuming threads roots can start > from more places than just always or initial blocks if you allow a > function to call a fork_join_none. They can start form continuous > assignments or in variable declarations. And those variable declarations > could be in a package, which in turn are not supposed to contain any > rooted threads. > > > > Dave > > > > > > ------------------------------------------------------------------------ > > From: Ambar Sarkar [mailto:ambar.sarkar@paradigm-works.com] > Sent: Thursday, February 16, 2006 4:14 AM > To: Rich, Dave; sv-ec@eda.org; sv-bc@eda.org > Subject: RE: [sv-ec] Can a function contain a fork/join/any/none? > > > > Dave, > > > > Is there a definition of the term “time consuming”? A fork/join none(not > the others) is non time consuming as far as I understand. Or is it being > seen as the conceptual equivalent of a task call and thus recommended > against in function calls? > > > > Regards, > > -Ambar > > > > ------------------------------------------------------------------------ > > From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of > Rich, Dave > Sent: Thursday, February 16, 2006 12:33 AM > To: sv-ec@eda.org; sv-bc@eda.org > Subject: [sv-ec] Can a function contain a fork/join/any/none? > > > > A number of people have asked me the above question, and my immediate > answer has been no. However, it looks like a number of things that were > ruled out by the BNF in 1364 by having separate function_statement and > statement productions, have been let back in by the 1800 BNF. Also, > there are a number of new constructs in SystemVerilog that may need > restrictions for use by a function. The fork/join_none was added to > SystemVerilog, but since there are restrictions on any time controlling > statements, or task enables, it doesn’t seem to make much sense to allow it. > > > > I’m not sure which committee should have this issue, but I think the > sv-bc should create some guarantees about what a function is and is not > allowed to do. The sv-ec may have to review which added constructs make > or break those guarantees. > > > > This is mantis 1336. > > > > Dave > > > > > > David Rich > Verification Technologist > Design Verification & Test Division > Mentor Graphics Corporation > dave_rich@mentor.com > Office: 408 487-7206 > Cell: 510 589-2625 > > > -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.comReceived on Thu Feb 16 07:02:38 2006
This archive was generated by hypermail 2.1.8 : Thu Feb 16 2006 - 07:03:02 PST