[sv-bc] RE: [sv-ac] RE: Time consuming tasks in always_ff

From: Steven Sharp <sharp@cadence.com>
Date: Tue Jul 19 2011 - 15:05:55 PDT

I assume that this is not an issue. If it is, then the same issue can occur with function calls. In SV, they can schedule events directly using nonblocking assignments and fork..join_none, and indirectly by writing to variables that other processes are waiting on.

From: Stuart Sutherland [mailto:stuart@sutherland-hdl.com]
Sent: Tuesday, July 19, 2011 4:30 PM
To: Steven Sharp; 'Korchemny, Dmitry'; 'Maidment, Matthew R'; 'sv-bc'
Cc: sv-ac@eda-stds.org
Subject: RE: [sv-ac] RE: Time consuming tasks in always_ff

System Tasks do not advance simulation time directly, but can schedule events in various regions of the current time step and future time steps. Does that need to be taken into consideration?

Stu
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Stuart Sutherland
Sutherland HDL, Inc.
stuart@sutherland-hdl.com
503-692-0898
www.sutherland-hdl.com<http://www.sutherland-hdl.com>

From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Steven Sharp
Sent: Tuesday, July 19, 2011 1:06 PM
To: Korchemny, Dmitry; Maidment, Matthew R; 'sv-bc (sv-bc@eda.org)'
Cc: sv-ac@eda-stds.org
Subject: [sv-ac] RE: Time consuming tasks in always_ff

I don't believe that any system tasks are time consuming. You need to recognize that there is a difference between a SystemVerilog task and a system task.

From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Tuesday, July 19, 2011 11:23 AM
To: Maidment, Matthew R; 'sv-bc (sv-bc@eda.org)'
Cc: sv-ac@eda-stds.org
Subject: [sv-bc] RE: Time consuming tasks in always_ff

We want to allow tasks in checkers, e.g. $display for debug or information purposes. This enhancement is straightforward in case the task is not time consuming, hence my question.

Thanks,
Dmitry

From: Maidment, Matthew R
Sent: Tuesday, July 19, 2011 18:19
To: Korchemny, Dmitry; 'sv-bc (sv-bc@eda.org)'
Cc: sv-ac@eda-stds.org
Subject: RE: Time consuming tasks in always_ff

The LRM states the intent:

The always_ff procedure can be used to model synthesizable sequential logic behavior

Your question seems to imply that you want to deviate from this or exploit a loophole for your interests.

What is the motivation for the question?

Matt

--
Matt Maidment
mmaidmen@ichips.intel.com<mailto:mmaidmen@ichips.intel.com>
From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Tuesday, July 19, 2011 4:20 AM
To: 'sv-bc (sv-bc@eda.org)'
Cc: sv-ac@eda-stds.org
Subject: [sv-ac] Time consuming tasks in always_ff
Hi all,
In 9.2.2.4 it is written that "The always_ff procedure imposes the restriction that it contains one and only one event control and no blocking timing controls." However, it is not written explicitly that there cannot be calls to task with such event controls. How should I interpret this statement?
Thanks,
Dmitry
---------------------------------------------------------------------
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<http://www.mailscanner.info/>, 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<http://www.mailscanner.info/>, and is
believed to be clean.
--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Tue Jul 19 15:06:45 2011

This archive was generated by hypermail 2.1.8 : Tue Jul 19 2011 - 15:06:50 PDT