RE: [sv-bc] function task calling

No it does not. the BNF uses system_tf_identifier generically, and
individual system routines are not in the BNF.

Dave


> -----Original Message-----
> From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> Sent: Sunday, September 09, 2007 8:59 PM
> To: Rich, Dave; Steven Sharp; sv-bc@server.eda-stds.org;
> Brad.Pierce@synopsys.com
> Subject: RE: [sv-bc] function task calling
> 
> So:
> 
> Does this require a change in the BNF?
> 
> Shalom
> 
> > -----Original Message-----
> > From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> > Sent: Sunday, September 09, 2007 11:41 PM
> > To: Bresticker, Shalom; Steven Sharp;
> > sv-bc@server.eda-stds.org; Brad.Pierce@synopsys.com
> > Subject: RE: [sv-bc] function task calling
> >
> > You and I have too long a history with Verilog. The only
> > reason we call system tasks "tasks" is because there were no
> > void function in Verilog.
> > And the Verilog LRM never made an exception for system that
> > could be called by a function. Now that we do have void
> > functions, this is the natural way to describe a routine that
> > is guaranteed not to block as well as having no return value.
> >
> > Also, there is no longer a reason to have routines that can
> > sometimes be called as a task, as sometimes called as a
> > function. They should always be defined as functions that
> > return a value, which may be discarded.
> >
> > Dave
> >
> >
> > > -----Original Message-----
> > > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> > > Sent: Sunday, September 09, 2007 8:53 AM
> > > To: Rich, Dave; Steven Sharp; sv-bc@server.eda-stds.org;
> > > Brad.Pierce@synopsys.com
> > > Subject: RE: [sv-bc] function task calling
> > >
> > > That is beginning to sound like a patch on top of a patch.
> > >
> > > Shalom
> > >
> > > > -----Original Message-----
> > > > From: Rich, Dave [mailto:Dave_Rich@mentor.com]
> > > > Sent: Sunday, September 09, 2007 6:51 PM
> > > > To: Bresticker, Shalom; Steven Sharp; sv-bc@server.eda-stds.org;
> > > > Brad.Pierce@synopsys.com
> > > > Subject: RE: [sv-bc] function task calling
> > > >
> > > > That's easy to deal with. They are still system functions.
> > > > It's just that they can be implicitly cast to a void return
type.
> > > >
> > > > Dave
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com]
> > > > > Sent: Sunday, September 09, 2007 8:45 AM
> > > > > To: Rich, Dave; Steven Sharp; sv-bc@server.eda-stds.org;
> > > > > Brad.Pierce@synopsys.com
> > > > > Subject: RE: [sv-bc] function task calling
> > > > >
> > > > > Although today there may be no system tasks which delay, there
> > could
> > > > be
> > > > > in the future.
> > > > >
> > > > > Note that we already have one system task, $cast, which
> > > > when called as
> > > > a
> > > > > function, is not of type void. We also decided that $system
> > > > would work
> > > > > that way. And in 1364-2001, $sformat was described that
> > way also.
> > > > >
> > > > > Shalom
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: owner-sv-bc@server.eda.org
> > > > > > [mailto:owner-sv-bc@server.eda.org] On Behalf Of Rich, Dave
> > > > > > Sent: Sunday, September 09, 2007 6:52 AM
> > > > > > To: Steven Sharp; sv-bc@server.eda-stds.org;
> > > > Brad.Pierce@synopsys.com
> > > > > > Subject: RE: [sv-bc] function task calling
> > > > > >
> > > > > > I think renaming system tasks to system functions is
> > > > something that
> > > > > > will have to eventually happen as a result of the merge.
> > > > Any method
> > > > > > that guarantees it will not consume time should be
> > defined as a
> > > > > > function, void or otherwise. In the end it will be a
> > lot clearer
> > > > > > that way.
> > > > > >
> > > > > > But there are 368 occurrences of 'system task' in the
> > > > LRM. I think
> > > > > > it should wait for the next draft, unless someone has the
> > > > energy to
> > > > > > take this on in the next two months.
> > > > > >
> > > > > > Dave
> > > > > >
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: owner-sv-bc@server.eda.org
> > > > [mailto:owner-sv-bc@server.eda.org]
> > > > > > On
> > > > > > > Behalf Of Steven Sharp
> > > > > > > Sent: Saturday, September 08, 2007 8:25 PM
> > > > > > > To: sv-bc@server.eda-stds.org; Brad.Pierce@synopsys.com
> > > > > > > Subject: RE: [sv-bc] function task calling
> > > > > > >
> > > > > > >
> > > > > > > >Could we add text saying that a system task is a
> > void system
> > > > > > function?
> > > > > > >
> > > > > > > It doesn't sound like you are suggesting that we replace
> > > > > > "system task"
> > > > > > > with "void system function" everywhere, which would be
> > > > > > daunting.  It
> > > > > > > sounds like you are suggesting a single statement saying
> > > > > > that system
> > > > > > > tasks can be regarded as void system functions.
> > > > > > >
> > > > > > > If this only affects the legality of calling them from
> > > > > > functions, then
> > > > > > > you would presumably want the statement to appear in the
> > > > > > section that
> > > > > > > says what is legal in a function.  Something like "System
> > tasks
> > > > are
> > > > > > > treated as if they are void system functions for this
> > purpose."
> > > > > > >
> > > > > > > That seems to me like a roundabout way of saying what you
> > > > > > mean, which
> > > > > > > is "System tasks can be called from functions."
> > > > > > >
> > > > > > > It sounds like you want the text to provide the rationale
> > > > > > for the rule
> > > > > > > in addition to the rule itself.  I don't have a problem
> > > > > > with that, as
> > > > > > > it makes the rules easier to understand and extrapolate
> > > > from.  But
> > > > I
> > > > > > am
> > > > > > > concerned that saying "system tasks are actually void
system
> > > > > > functions"
> > > > > > > will lead readers to believe that this means something
> > > > more than
> > > > > > > "system tasks can be called from functions".  This could
> > > > > > confuse them.
> > > > > > >
> > > > > > > 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.
> > > > > >
> > > > >
> > > >
> >
---------------------------------------------------------------------
> > > > > 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.
> > > >
> > >
> >
---------------------------------------------------------------------
> > > 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.
> >
> ---------------------------------------------------------------------
> 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.