[sv-bc] RE: [sv-ac] [SV-AC] New upload 3478_inouts_drivers_111804e.docx

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> [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, and is
believed to be clean.