It looks like this concept of getting the value of drivers of out ports involves some complexities. Well, at least on paper, it looked promising! After more thoughts, a way around this problem is demonstrated in the following example using SV'09. Basically, if a user is concerned about outputs connected to multiple drivers, the RTL model needs to calculate the output on a wire without the effect of outside drivers. In the dut model below, that would be the (*assign *y= oe ? data : 1'bZ; ). The RTL would then do a copy of the computed value onto the output port ( *assign *x=y;) The assertion module that is bound to the dut needs to check the 'bZ case on the wire that is not affected by outside drivers (the *wire y* in this model). When the driver is in effect, the actual output can be checked in the assertion. Basically, it's a way around it, but that would work! *module *dut(*inout wire *x); *bit *oe, clk, data; wire y; // Need this for assertions, temp wire without drivers effect *assign *y= oe ? data : 1'bZ; // predicted value, without outside drivers effects *assign *x=y; *endmodule* *module* bind2dut(*input bit *clk, oe, y, x, data); ap_no_oe: *assert property*(@(posedge clk) !oe |-> y=='bZ); ap_oe: *assert property*(@(posedge clk) oe |-> x==data); *endmodule *: bind2dut *module *top; bit c; wire x; dut dut1(.*); dut dut2(.*); *assign *x= c ? 1 : 1'bZ; *bind *dut bind2dut bind2dut1(.*); *endmodule* Ben Cohen On Thu, Dec 4, 2014 at 9:45 PM, Arturo Salz <Arturo.Salz@synopsys.com> wrote: > I would like to echo the sentiments expressed by both Gord and Steven. > In addition I wanted to comment on Shalom’s idea of being able to examine > the “external” drivers of a bidirectional primitive (tran). Yes, having > that capability in the language would allow user code to model a basic > bidirectional switch, but in my experience all such schemes tend to fall > apart when users stack such devices back to back. What works for a simple > configuration breaks in a slightly modified one – the apparent positive > feedback can create infinite oscillations and non-convergent solution. This > kind of stuff is trivially handled by actual (i.e., analog) solvers. > > > > Arturo > > > > *From:* owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] *On Behalf Of *Gordon > Vreugdenhil > *Sent:* Thursday, December 04, 2014 3:14 PM > *To:* hdlcohen@gmail.com; Steven Sharp > *Cc:* Rich, Dave; sv-ac@eda.org; Korchemny, Dmitry; SV-BC > *Subject:* Re: [sv-bc] Re: [sv-ac] [SV-AC] New upload > 3478_inouts_drivers_111804e.docx > > > > > 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> 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] *On Behalf Of *Rich, > Dave > *Sent:* Thursday, December 04, 2014 12:35 PM > *To:* hdlcohen@gmail.com; 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 > <owner-sv-ac@eda.org>] *On Behalf Of *Ben Cohen > *Sent:* Thursday, December 04, 2014 8:43 AM > *To:* 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* <http://www.mailscanner.info/>, and is > believed to be clean. > -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Dec 4 23:07:41 2014
This archive was generated by hypermail 2.1.8 : Thu Dec 04 2014 - 23:07:46 PST