I agree with Mark's comments about the synthesis aspects. I also want to re-iterate Jonathan's concerns about virtual interfaces to make it clear how deep the problem really is. If, using Mark's example, we have: module top2; I i(); virtual I some_i; initial if (some_run_time_condition) begin some_i = i; i.L = 1; end M m(.imp(i.MP)); M2 m2 (.imp(i.MP)); endmodule Clearly we can easily introduce truly difficult situations for determining if a particular interface element has a single driver. Unless we want to make this a run-time check, a conservative approximation would require that if an interface was ever assigned to a virtual interface and *any* virtual interface handle assigned to an element of the virtual interface, then ALL potential interfaces would have that counted as a procedural driver. This is likely going to be pretty painful and will almost certainly cause all sorts of undesirable interactions. A run-time solution is going to impact simulation performance and will make such errors become latent and possibly show up via "stable" IP, etc. I don't think that would be at all desirable. The root problem here is that we are mixing two concepts -- a "topologically invariant" synthesis concept, and a highly dynamic testbench concept. The two simply do not play well together. My current preference is that the LRM should explicitly exclude assignments through virtual interfaces as being part of the "single driver" determination. Since such constructs are not synthesizable, if a design satisfies the "single driver" invariants without considering the virtual interface aspects, I believe that the end result will be Ok. I do have a related question however. Is there any deeper assumption about modport directions than there is for ports? I believe the answer is "no" based on various comments but I want to make sure that we're all on the same page. In particular, in Mark's full example, if you change modport MP (output L); to modport MP (input L); Is there any impact at all? I have always assumed that there isn't but we have had users asking about this. As with module ports and as the example in 24.5.4 explicitly indicates, "input" ports can be associated with constants and the like while "output", etc. cannot. But those are just basic port semantics and I am assuming that nothing more strict applies. Gord. Mark Hartoog wrote: > After reading through Mantis 2114 I have a few comments. > > Simulation tools are expected to accept the whole language. > Synthesis tools only accept a subset of the language that they > have designated as synthesizable. There will always be cases > where simulation tools accept a design, and synthesis tools > do not. > > That aside, in System Verilog an effort was made to design > the language so that simulation tools could check the > synthesizability of some constructs. This was the reason > the always_comb was added to the language. To allow simulation > tools to enforce some of the rules that synthesis tools require. > > Unfortunately, in the examples in 2114 you are not using > always_comb to drive these signals. You are using initial blocks, > which are not synthesizable constructs. Simulators must allow > multiple initial block processes to write to a single variable. > > If you convert one of the drivers to an always_comb, as shown below, > then there is at least one major simulator that will flag this as > an error, although we do allow customers to turn off this error > check and run the simulation anyway. > > interface I; > logic L; > modport MP (output L); > endinterface > > module M (I.MP imp); > always_comb > imp.L = 1; > endmodule > > module M2 (I.MP imp); > initial > #5 imp.L = 0; > endmodule > > module top2; > I i(); > M m(.imp(i.MP)); > M2 m2 (.imp(i.MP)); > endmodule > >> -----Original Message----- >> From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On >> Behalf Of Jonathan Bromley >> Sent: Tuesday, October 16, 2007 2:26 PM >> To: sv-bc@eda.org; sv-ec@eda.org >> Subject: [sv-ec] That modport direction issue again >> >> hi BC, EC, >> >> On a number of previous occasions I've nagged away at the >> issue of what it really means to have a modport with an item >> of "output" direction, without getting a definitive result. >> Synthesis implementors strongly take the position that it >> represents a continuous assignment to the corresponding >> interface item, but the LRM does not really justify this and >> all the major simulators take the other position, that the >> modport-type port represents an alias to the modport >> instance. The consequences of this divergence are unpleasant. >> I have created Mantis 2114 to ask for clarification. >> >> As I hope I've made clear in the bugnote, clarifying the LRM >> in the synthesis implementors' favour would severely impact >> the usability of interfaces and modports by outlawing some >> obvious idioms, including certain uses of virtual interface >> (which is why EC is copied, although I've marked the Mantis >> for BC since they are primarily responsible for interfaces). >> >> I am convinced that this is quite badly broken, and needs >> fixing. Unless someone can persuade me otherwise, I urge BC >> to take a look at this and get it on to their agenda if at >> all possible. I'm happy to do the legwork of writing a >> proposal if people can tell me what the consensus is. >> >> Thanks >> -- >> 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. >> >> >> > -- -------------------------------------------------------------------- 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 07:34:58 2007
This archive was generated by hypermail 2.1.8 : Wed Oct 17 2007 - 07:35:34 PDT