The problem is still that such additional information can have a pretty negative effect on an implementation's ability to do various optimizations. That is, I suspect, part of the underlying message from Steven about assumptions regarding when/how resolution occurs in (most/all) implementations today in the presence of collapsed nets. In some/most existing tools things like a "drivers" command is not really expected or intended to be a complete and accurate listing of all "in the design" drivers, particularly in situations where an optimization might make logic reductions. And it would be highly surprising for any implementation to consider "connections" as drivers in Verilog/SV. So preserving "module level" granularity is likely going to hurt in various ways. And the "simple" kind of scenario that you suggest is exactly the kind of thing that is most amenable to very aggressive optimizations. The temptation is to then consider saying that the information is only "available" when an assertion is "somewhere" on a collapsed net. That is an approach that is very questionable as well in the presence of various implementations' support for separate or incremental compile and elab flows, particularly with "bind" (which was, after all, originally intended for late assertion injection!). I'd certainly need to spend much more time on this, but my general inclination is to question whether the value of this is worth what it might do for performance, composibility, and/or vendor specific restrictions or flows. Gord On 12/4/14, 2:29 PM, Ben Cohen wrote: > Can we put restrictions so as to make this possible? For example: > -Resolved signal is of type "wire" > - A module shall have a single assign to the output of a module or to > an internal signal of a module (from an "assign" statement, or from a > single always statement). > Example: > module dut(output wire x); > bit a; > assign x= a ? 0 : 1'bZ; > endmodule > > module top; > bit c; > wire x; > dut dut1(.*); > dut dut2(.*); > assign x= c ? 1 : 1'bZ; > endmodule > My goals are to make these drive functions work for assertions. If > they can work for other things, great; however, I don't mind putting > constraints to make it easier to implement. > Ben Cohen > > On Thu, Dec 4, 2014 at 1:52 PM, Steven Sharp <sharp@cadence.com > <mailto:sharp@cadence.com>> wrote: > > There are other issues with this proposal, particularly the idea > that the simulator already has this information available. > > This seems to be based on the idea that the drivers inside the > module will be resolved to a value, and then that result will be > resolved with the result of the drivers from outside. I believe > VHDL requires this kind of hierarchical resolution. Verilog does > not. I think implementations could do this for the built-in > nettypes, since I think their resolution functions are all > associative (with the possible exception of trireg, depending on > how you view it). Perhaps some simulators actually do this, at > least in some special cases involving cosimulation. But in the > normal case, the simulators I am familiar with resolve all the > drivers on the net in a single evaluation. So there are no > partial resolutions already available. > > For the user-defined nettypes, I believe that the LRM requires a > single resolution of all the drivers to a final value. The > user-defined resolution functions are not required to be > associative, so trying to do partial resolutions and then resolve > those results together could produce different results. As an > example, consider a resolution function that averages the > contribution of the drivers. There is a difference between > averaging 3 drivers together, and averaging 2 drivers together > then averaging that result with a third driver. The second value > would over-weight the third driver. So there is no way to provide > correct resolved values separately for the external and internal > drivers. > > Even if you restricted this to built-in nettypes that are > associative, and breaking up the resolutions into partial results > that were then combined to produce the final result, simply making > those partial results available would not be sufficient in some > cases. You would have to compute extra partial results that were > not needed for the final result. > > Consider a net in a parent module that is connected to two child > modules. There is a driver P in the parent and drivers C1 and C2 > in the two child modules. The first child module needs its > internal value C1, and the external value (P+C2). The final value > would be (C1+(P+C2)). But the second child module needs its > internal value C2, and the external value (P+C1). That external > value isn’t one of the values we already computed. We need to > compute both (P+C1) and (P+C2), even though they are not both > needed for the final result. > > Shalom may have been asking for something a little different: the > values of each of the drivers, rather than the resolved values of > various subsets of them. Those should be available. The > interface for this would need to be able to provide an arbitrary > number of driver values, rather than just the internal and > external values. As with user-defined resolution functions, a > dynamic array seems like the most appropriate data structure. The > ability to get the values of only the drivers on a particular side > of a port would also be possible, though more complex for the > implementation. In theory, if a user-defined nettype had an > associative resolution function, the user could call it themselves > with the driver values from each side to get the resolved values > for each. Doing something like this for the built-in nettypes > would be more problematic, for a variety of reasons. > > *From:*owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org> > [mailto:owner-sv-bc@eda.org <mailto:owner-sv-bc@eda.org>] *On > Behalf Of *Rich, Dave > *Sent:* Thursday, December 04, 2014 12:35 PM > *To:* hdlcohen@gmail.com <mailto:hdlcohen@gmail.com>; > sv-ac@eda.org <mailto:sv-ac@eda.org>; Korchemny, Dmitry > *Cc:* 'SV-BC' > *Subject:* [sv-bc] RE: [sv-ac] [SV-AC] New upload > 3478_inouts_drivers_111804e.docx > > One problem that I see with this and a number of othe proposals > coming from the SV-AC is the use of $somename functions. This is > not the way to add functionality to a language unless you expect > the user to be able to modify it using the VPI. The main > motivation for not doing it this way is that if the user misspells > the $somename function, they may not get an error message until > runtime after time 0. > > A much better solution would be using a language based syntax, > perhaps using built-in methods. > > Dave > > *From:*owner-sv-ac@eda.org <mailto:owner-sv-ac@eda.org> > [mailto:owner-sv-ac@eda.org] *On Behalf Of *Ben Cohen > *Sent:* Thursday, December 04, 2014 8:43 AM > *To:* sv-ac@eda.org <mailto:sv-ac@eda.org>; Korchemny, Dmitry > *Subject:* [sv-ac] [SV-AC] New upload 3478_inouts_drivers_111804e.docx > > I uploaded into http://www.eda-stds.org/svdb/view.php?id=3478 > > 3478_inouts_drivers_111804e.docx > <http://www.eda-stds.org/svdb/file_download.php?file_id=5953&type=bug> [^ > <http://www.eda-stds.org/svdb/file_download.php?file_id=5953&type=bug>] > (110,060 bytes) /2014-12-02 12:25/ > > Please review. > > Thanks Erik for pointing out the issue with the binding of an > assertion module with bidirects ports and for suggesting a > workable solution. The doc explains this in the "note" section of > the file. > > Ben > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, > and is > believed to be clean. > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, > and is > believed to be clean. > > > > -- > This message has been scanned for viruses and > dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is > believed to be clean. -- -------------------------------------------------------------------- Gordon Vreugdenhil 503-685-0808 Verification Technologies, 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 Thu Dec 4 15:14:34 2014
This archive was generated by hypermail 2.1.8 : Thu Dec 04 2014 - 15:14:40 PST