RE: [sv-ec] input skew 0 clocking block behavior

From: Jonathan Bromley <jonathan.bromley_at_.....>
Date: Tue Feb 20 2007 - 08:16:23 PST
> I think that (2) 

[@(cb) guaranteed to happen after cb.invar update; 
consequently @(cb) happens after Observed if 
cb.invar is input #0]

> is likely quite undesirable; the event lag would
> have surprising effects since the event would not occur until
> after the nba region, etc.

It could easily cause another iteration around the outer 
loop in the same timeslot, yes.  However, I don't really
have a problem with removing the "event equivalence" claim;
indeed I'm rather ashamed that I didn't notice it was still
in the text, since I've for some time been of the opinion
that the explcit deferral of @(cb) is essential to get
reasonable behaviour from clocking inputs.

However, as you say the problem arises only if you want
design code to be able to do #0 sampling, and that's
a fairly odd thing to want to do; so I would be OK with
the "surprising effects".

> 3) disallow use of a #0 skewed input outside of a program.

But don't we just get the same problem again if we try to
do input #0 sampling of program variables by program code?

> or just kill off input # completely...

Ah, nirvana :-)
-- 
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.
Received on Tue Feb 20 08:20:54 2007

This archive was generated by hypermail 2.1.8 : Tue Feb 20 2007 - 08:21:09 PST