"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-2625Received on Thu Feb 16 06:12:07 2006
This archive was generated by hypermail 2.1.8 : Thu Feb 16 2006 - 06:12:33 PST