RE: [sv-bc] function task calling

What about the contents of Manti 1336 and 1615?

Shalom 

> -----Original Message-----
> From: Rich, Dave [mailto:Dave_Rich@mentor.com] 
> Sent: Monday, September 10, 2007 7:07 AM
> To: Bresticker, Shalom; Steven Sharp; 
> sv-bc@server.eda-stds.org; Brad.Pierce@synopsys.com
> Subject: 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.
> 
---------------------------------------------------------------------
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.