Doug, I can't attend SV-EC today, but some comments on your interesting points: > 1. Cliff has shown that we need to allow procedural > assignments to variables that are also driven by > clocking outputs. This is useful for initialization. > This will require exempting clocking blocks from the > strictures about multiple writers to variables from > different processes (something I will put in 890). Forgive my ignorance, but *what* strictures? If we think of a clocking output as making NBAs to its target variable (see below for the difference if the clocking output's target is a net) then the only problem would arise if someone tried to do a *continuous assign* to the same variable "round the back" of the clocking, and I think it would be reasonable to disallow that conflict. > A question now arises about continuous assignments > to variables that are also driven by clocking outputs. > What should we do with those? I'd go for outlawing it. That would be consistent with the conceptual model in which a variable that is a clocking output suffers NBAs from the clocking (admittedly NBAs that got there in a slightly odd way, but NBAs nonetheless). You can't make NBAs to a variable that is also driven by a continuous assignment. On the other hand, non-clocking continuous assigns to a *net* that is also a clocking output should be OK, if you accept the model I proposed a while ago in which the clocking writes to a hidden internal variable by NBA and then that variable is driven out on to the target net by an implicit continuous assign within the clocking. The only missing detail would be the need to specify the drive strength of that implicit continuous assign. I suggest it should be (strong0, strong1), but you might consider making it configurable thus: wire W; clocking cb @(...); output (strong0, weak1) #2 W; endclocking A while ago I put together a few pictures relating to this. I haven't heard any specific objections to their content, and they might be useful as a focus for some discussion, so I attach them again here. They talk about the resolution behaviour I'd like to abolish, but that's another question :-) > 4. Generalizing on 3, what does it even mean to have > clocking variables that are of dynamic types? > The LRM only discusses and shows integral values. > Should we introduce a rule that limits clocking > variables to be of integral types? If you don't have clocking drive resolution then it's reasonably easy: If you could legally do an NBA to it, then it's OK for a clocking to drive it. -- 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 archive was generated by hypermail 2.1.8 : Mon Jan 22 2007 - 11:14:01 PST