>From: "Rich, Dave" <Dave_Rich@mentor.com> >I believe that port coercion can only happen if both sides of the >connection are nets, not just if the port declarations are nets. As soon >as one side has a variable, then the rules for connections to variables >indicate that an implicit continuous assignment is created, thus the >direction can no longer be coerced. This is correct. Notice that the ports are coerced to inout, and only nets can be connected on both sides of inout ports. >This section really belongs in 22.3.3.3 Port connection rules for nets, >just before mentioning additional rules in 22.3.3.7 or you could put >this in the latter section. Port coercion is really due in part to the >fact that the port is collapsed. In the implementations I am familiar with, port coercion is due entirely to the fact that the port is collapsed. This idea that port coercion is a deliberate attempt by the tool to fix an incorrect port direction was a figment of someone's imagination. What happened is that Verilog-XL collapses ports whenever it can, for performance reasons. It does this independently of the declared or correct port direction. When it does this, the port becomes an inout. Apparently someone noticed that their incorrectly declared port was working anyway, and concluded that the tool had detected their mistake and fixed it. This imagined "fixing" then got specified in the LRM. 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 19 10:09:21 2007
This archive was generated by hypermail 2.1.8 : Fri Oct 19 2007 - 10:09:30 PDT