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

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