>> SVDB 909 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=909 >> >> SVDB 1265 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1265 >> >> SVDB 1278 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1278 >> >> SVDB 1360 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1360 >> >> SVDB 1487 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1487 >> >> SVDB 1489 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1489 >> >> SVDB 1573 ___Yes _X_No >> http://www.eda.org/svdb/view.php?id=1573 I have a problem with defining what it means for a port to be "used as an output (input)". That would presumably be defining the algorithm used to detect such a misdeclared port and coerce it. Since I am not aware of any implementation that actually uses such an algorithm for this, I have a problem with claiming anything about it. I think that this sentence should describe what actually happens, which is something like "Because of the port collapsing described in 22.3.3.7, ports declared as input or output may be coerced to inout." If there is a desire to force implementations to coerce ports when possible, then there should be text saying that port collapsing must be done whenever possible (and clarifying some of the cases where it may not be clear whether it is possible). Also, this is independent of the original question of whether it is legal to assign to an input port. Even if the port is not coerced, and remains an input port, it is still legal to assign to it. Connecting something to the inside of an input port just creates a continuous assignment to it from the expression on the outside. For a variable, that prevents any other assignments to it. But for a net, multiple continuous assignments are perfectly legal. The resolved value won't be visible on the other side of the input port because of the unidirectional nature of the continuous assignment. That is what makes it an input port. >> SVDB 1610 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1610 Shouldn't we try to provide a standard compiler-generated naming convention for unnamed blocks? I would suggest following the pattern used for generate blocks, but with "genblk" replaced with something like "unmblk". >> SVDB 1645 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1645 >> >> SVDB 1750 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1750 >> >> SVDB 1993 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=1993 >> >> SVDB 2006 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=2006 I assume we are voting to close this as a duplicate? >> SVDB 2029 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=2029 >> >> SVDB 2081 ___Yes _X_No >> http://www.eda.org/svdb/view.php?id=2081 The change to the text has lost the prohibition on delay controls (which were improperly called timing controls before, but at least it was close). Also, it disallows intra-assignment delays even when they are not blocking delays, as in nonblocking assignments. Whether or not there is a desire to prohibit nonblocking assignments, it should not depend on whether they have intra-assignment delays. >> SVDB 2092 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=2092 >> >> SVDB 2097 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=2097 >> >> SVDB 2102 _X_Yes ___No >> http://www.eda.org/svdb/view.php?id=2102 >> >> SVDB 2140 ___Yes _X_No >> http://www.eda.org/svdb/view.php?id=2140 I think this needs some more discussion, and some time for others to propose a reasonable alternative that handles escaped identifiers better. However, since I am skeptical about finding an alternative that is compatible with the existing text-oriented rules, I would be willing to vote in favor of this if an alternative approach is not suggested soon. Steven Sharp sharp@cadence.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Fri Oct 26 18:45:14 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 26 2007 - 18:45:40 PDT