RE: [sv-bc] function task calling

From: Rich, Dave <Dave_Rich_at_.....>
Date: Sun Sep 09 2007 - 15:10:37 PDT
You and I have too long a history with Verilog. The only reason we call
system tasks "tasks" is because there were no void functions in Verilog.
And the Verilog LRM never made an exception for system tasks 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 not having a return value.

Also, there is no longer a good 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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sun Sep 9 15:12:09 2007

This archive was generated by hypermail 2.1.8 : Sun Sep 09 2007 - 15:12:28 PDT