RE: [sv-ec] Using a clocking block's pseudo-event

From: Arturo Salz <Arturo.Salz_at_.....>
Date: Thu Jan 11 2007 - 11:00:22 PST
Jonathan,

I'd be happy to submit your proposal. Thanks for offering to write it.

The syntax you propose (cb.event) may be problematic. Note that event is
already a keyword that designates a type. Anyhow, we probably could make
it work, but I don't think it's as important (or even needed) to spend
the time needed to do so.

	Arturo

-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Jonathan Bromley
Sent: Thursday, January 11, 2007 10:51 AM
To: sv-ec@eda.org
Subject: RE: [sv-ec] Using a clocking block's pseudo-event

Arturo,

thanks for your response.

> I believe that extending the triggered method to a clocking block is a
> natural extension that makes a lot of sense. The only issue may be
> backward compatibility with clockvars named triggered, which 
> is probably a low probability occurrence.

I don't have write access to Mantis; I'd be happy to write up
a proposal and submit it indirectly, though.

> However, I don't believe that allowing a clocking block to be assigned
> to an event handle is as coherent. After all a clocking block 
> is not an event; it may support some of the same methods, 
> but that doesn't change its type. 

Syntactically you're right, of course, but it seems odd that 
we can "virtualize" just about any other event using an event
handle, but we can't do that with the event tied to a 
clocking.  If you're unhappy about
  event E = cb;
because of the obvious type discrepancy, how about we
permit the syntax
  cb.event
to gain explicit reference to the clocking's event?
That would also give us

  cb.event.triggered

with no risk of backward incompatibility.

I would be happy to see a semantic restriction
that events derived in this way should be "read-only",
so that they cannot be fired using -> or ->>.
On particularly sleepless nights I can imagine
meaningful uses for the procedural firing of a
clocking block, but the medication soon fixes that :-)
-- 
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.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Jan 11 11:00:52 2007

This archive was generated by hypermail 2.1.8 : Thu Jan 11 2007 - 11:01:02 PST