[sv-ec] Proposal for triggered property of clocking block

I don't have write access to Mantis, but Arturo has kindly 
offered to post the following proposal on my behalf.  It
proposes that the .triggered property of events should also
be valid for clocking blocks.

Plain-text version of the proposal below; when I sent the
PDF as an attachment it didn't make it to the email reflector.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROPOSAL: Triggered property of a clocking block

Background
==========

SystemVerilog adds the new .triggered property of any event or event
handle. The triggered property of an event becomes true as soon as the
event is triggered (as the result of a ->or ->>operation) and remains
true until the end of the timeslot in which it became true. Similarly,
every sequence instance has a .triggered property which becomes true in
the Observed region of any timeslot in which a match of the sequence
reaches completion, and remains true until the end of that timeslot.
(References: 1800-2005 clauses 10.11, 14.5, 14.5.4, 14.7.2, 17.4, 17.10,
17.12.6)

SystemVerilog also adds clocking blocks, and provides for the identifier
of a clocking block to be used in an @(...)event control. Such an event 
control then waits for the clocking block's clocking event to be 
triggered. (References: 1800-2005 clauses 10.10, 15.9)

Proposed enhancement
====================

It would be useful and pleasingly symmetrical if the implied event of a
clocking block also had a .triggered property. I propose the addition 
of a .triggered property for every clocking block, yielding a value 
of type bit that is usually zero, but goes true (1'b1) whenever 
the clocking block's event is triggered and remains true until 
the end of the same timeslot.

Proposed LRM changes - option 1
(low impact on the language, but has some backward-compatibility issues)
========================================================================

It's clear that this change should be added to clause 15 (clocking
blocks) but that clause is currently under extensive review
so it seems futile to suggest any specific edits. However, clause 15.9
clearly refers to the related issue of the clocking block's
implied event so we suggest as a starting point the following addition:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
15.9.1 Clocking block .triggered property
The implicit event associated with a clocking block shall be triggered by
satisfaction of the clocking block's event
expression, as described above [in the existing text of 15.9]. This
triggering shall not only trigger an implicit event whose
name is the same as the name of the clocking block, but shall also set
the clocking block's triggered property, which then
shall remain true until the end of the timeslot in which it was set. This
triggered property may be tested using the
method-like syntax clocking_name.triggered. As with the
.triggered property of an event or sequence, this
.triggered property may be used in any expression as a simple value of
type bit, or it may be used in a level-sensitive
wait() timing control.

It shall be an error for a clocking block to have any clockvar named
triggered.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Note the backward-incompatibility caused by the hijacking of 
the name triggered, which otherwise could be a legitimate
name for a clockvar (since triggered is not a reserved word).

Proposed LRM changes - option 2
(more gain, more pain, avoids backward-compatibility problems)
==============================================================

As an alternative to the above proposal, it may be possible to 
generalise the idea somewhat, and also to remove the backward
compatibility problem, by finding some way to make explicit 
reference to a clocking block's implied event. The ability to
reference this event, pass it as a task argument and so forth 
(in other words, to treat the clocking's implied event in every 
way as a first-class event, except that it cannot be fired 
procedurally using ->or ->>) would be very valuable in some 
situations.  I have suggested elsewhere the syntax 
clocking_name.event to provide this, but Arturo noted that 
event is already the name of a type and therefore its use 
in a method-like context might cause some difficulties. 
Perhaps, then, a typecast-like syntax might do the job: 
event'(clocking_name)

In either case we then have access to the clocking's event using only the
clocking's name. This event expression could then
be assigned to event handles, passed as a task argument, used in
wait_order, used to trigger coverage groups, and
generally act like a proper event; and, of course, it would be possible
to query its .triggered property either directly or
through an event handle to which it had been assigned.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- 
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223                   Email: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573                           Web: http://www.doulos.com

The contents of this message may contain personal views which 
are not the views of Doulos Ltd., unless specifically stated.

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