> 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