RE: [sv-bc] function task calling

Again, as someone, maybe you, suggested, one solution for the 2008
revision is to state, maybe in 5.6.3, that system tasks are/can be
considered as system functions.

Is there a need to distinguish between built-in system functions and
user-defined system functions?

Thanks,
Shalom
 

> -----Original Message-----
> From: owner-sv-bc@server.eda.org 
> [mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave
> Sent: Monday, September 10, 2007 8:56 PM
> To: Mark Hartoog; Maidment, Matthew R; Brad Pierce; 
> sv-bc@server.eda-stds.org
> Subject: RE: [sv-bc] function task calling
> 
> For those members of the sv-bc that do not follow the sv-ec, 
> this issue is covered by 1336. You cannot call a task from a 
> function except for one special case: statements inside a 
> fork/join_none may allow blocking statements. That case 
> requires that you look at the root of the call stack, which 
> mist be from an initial or always block.
> 
> I think it would be much simpler to change the terminology of 
> a system task to system function. (Although the work in 
> making such a proposal would be significant).
> 
> 
> Dave
> 
> 
> > -----Original Message-----
> > From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org]
> On
> > Behalf Of Mark Hartoog
> > Sent: Monday, September 10, 2007 10:12 AM
> > To: Maidment, Matthew R; Brad Pierce; sv-bc@server.eda-stds.org
> > Subject: RE: [sv-bc] function task calling
> > 
> > If the call is to a class virtual task, it is very 
> complicate to check 
> > all possible implementations of the task.
> > 
> > > -----Original Message-----
> > > From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On 
> Behalf Of 
> > > Maidment, Matthew R
> > > Sent: Saturday, September 08, 2007 11:25 AM
> > > To: Brad Pierce; sv-bc@eda-stds.org
> > > Subject: RE: [sv-bc] function task calling
> > >
> > > Does this imply traversing any potential call stack to identify 
> > > those tasks that have statements that are illegal in a function?
> > > I think this is impractical.
> > >
> > > --
> > > Matt Maidment
> > > mmaidmen@ichips.intel.com
> > >
> > >
> > > >-----Original Message-----
> > > >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] 
> On Behalf Of 
> > > >Brad Pierce
> > > >Sent: Saturday, September 08, 2007 11:21 AM
> > > >To: sv-bc@eda-stds.org
> > > >Subject: RE: [sv-bc] function task calling
> > > >
> > > >Rather than a blanket prohibition on task enables in function 
> > > >definitions, should the prohibition in 13.4.b be 
> weakened to only 
> > > >disallow enables of tasks with statements that would be 
> illegal in
> a
> > > >function?
> > > >
> > > >-- Brad
> > > >
> > > >-----Original Message-----
> > > >From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] 
> On Behalf Of 
> > > >Steven Sharp
> > > >Sent: Friday, September 07, 2007 11:28 AM
> > > >To: sv-bc@eda-stds.org; shalom.bresticker@intel.com
> > > >Subject: Re: [sv-bc] function task calling
> > > >
> > > >
> > > >>Since functions are not allowed to call tasks, how can 
> a function 
> > > >>contain a call to $display?
> > > >
> > > >Functions are not allowed to delay.  Functions are not
> > > allowed to call
> > > >tasks because a task could delay, indirectly delaying 
> the function.
> > > >
> > > >System tasks cannot delay, so there is no problem with allowing 
> > > >functions to call them.  In SV terms, all system tasks are
> > > essentially
> > > >void functions.
> > > >
> > > >
> > > >>What types of built-in system tasks are functions 
> allowed to call?
> > > >
> > > >I am not aware of any built-in system task that can delay,
> > > so I don't
> > > >think there is any restriction.  I don't think there is 
> a way for a 
> > > >user-defined system task to delay either, so I don't think
> > > there is any
> > > >need for a restriction there either.
> > > >
> > > >I think this restriction is a case where "task" means
> > > "task", not "task
> > > >or system task."
> > > >
> > > >Steven Sharp
> > > >sharp@cadence.com
> > > >
> > > >
> > > >--
> > > >This message has been scanned for viruses and dangerous 
> content by 
> > > >MailScanner, and is believed to be clean.
> > > >
> > > >
> > > >--
> > > >This message has been scanned for viruses and dangerous 
> content by 
> > > >MailScanner, and is believed to be clean.
> > > >
> > >
> > > --
> > > This message has been scanned for viruses and dangerous 
> content by 
> > > MailScanner, and is believed to be clean.
> > >
> > >
> > >
> > 
> > --
> > This message has been scanned for viruses and dangerous content by 
> > MailScanner, and is believed to be clean.
> > 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> 
---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.