Mark Hartoog wrote: > > This is, however, something that is likely to cause problems > for users. The simulator is using a last writer wins > resolution function, which may lead to unexpected behavior > that will surprise users. > > Since it is very expensive and a lot of overhead to do the > single driver rule through virtual interfaces at run time, > it makes sense to exclude it for efficiency reasons, but when > possible I think we should not be adding blanket waivers of > the single driver rule for all test bench constructs. Definitely -- this is something that tools likely want to try to be helpful about but for which I don't think we can realistically mandate an "accurate" answer in the LRM. I agree that we need to be careful in exempting testbench constructs from semantic rules. There are very few situations in which that would be desirable, but I think that this situation is one of them. [...] > I think module are not allowed to write to variable input ports. > I'm not sure what other semantics you are thinking of. Well, that is part of the question. Are modport "inputs" like port inputs in that they aren't really "ref"? A module isn't permitted to write to an input port variable because it has a continuous driver so any sequential write conflicts. But we've already said (I think) that the "output" is not really a continuous assign. Does that hold for "input" or does "input" in fact behave continuously? I wasn't very clear in my earlier comments -- I was thinking about module *net* ports which collapse and are essentially directionless in such cases. Are modport "ref" semantics similar? If modports for variables don't impose continuous assignment semantics, then it should be immaterial what their direction is stated to be, shouldn't it? Gord. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Model Technology (Mentor Graphics) gordonv@model.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed Oct 17 09:55:14 2007
This archive was generated by hypermail 2.1.8 : Wed Oct 17 2007 - 09:55:24 PDT