>Date: Wed, 12 Dec 2007 07:04:29 -0800 >From: Gordon Vreugdenhil <gordonv@model.com> >My understanding is that the port coercion description exists in the >LRM as a concession to implementations which may choose to not collapse >nets. The port coercion gives a mechanism to approximate the effect >of collapsing. I would have to see historical support to believe that. I suspect that the description exists because users saw this apparent coercion, without realizing that it was just a side-effect of aggressive port-collapsing in Verilog-XL. Since they had come to rely on it, and did not see coercion specified in the LRM, this description was invented to describe what they thought was happening. It is no coincidence that the coercion always results in an inout rather than an input or output: a collapsed port acts like an inout. In fact, in Verilog-XL there is no distinction between an inout and a collapsed port. Inouts are implemented by forcing port collapsing. So from Verilog-XL's perspective, saying that a port must be coerced to inout would be equivalent to saying it must be collapsed. There may be other implementations that have applied this description as a way to match the effects of XL's port collapsing without having to do the port collapsing. I don't have a problem with that. It is mostly transparent. I do have a problem with specifying that coercion must be done under any specific conditions that an implementation must detect. Perhaps another option would be to add to the section on port collapsing something saying that implementations were free to treat ports as inouts even if they do not collapse them. This would cover those implementations that do not want to collapse ports, but still want to get the inout behavior that users have relied on. 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 Thu Dec 13 13:10:13 2007
This archive was generated by hypermail 2.1.8 : Thu Dec 13 2007 - 13:10:22 PST