Re: Clarification question on port direction

From: Kevin Cameron <dkc_at_.....>
Date: Thu May 04 2006 - 01:32:52 PDT
It's best to view port direction as advisory, in a mixed signal 
situation where you just add a capacitance onto a logic "input" port 
you've  added a contribution that makes it an output (if you view ports 
with drivers or contributions in the module being outputs).

The original port direction stuff in Verilog-A was added to keep someone 
with a digital background happy, and Cadence's Verilog-A implementation 
mostly ignored port direction whereas Mentor's (later) implementation 
was somewhat strict resulting in designs at Nat Semi not being portable.

Probably best to say port direction only applies to drivers/receivers 
and not to contributions.

Kev.

Jonathan David wrote:

>I would think that they would have to be  REQUIRED for
>Logic or Mixed signal situations.. for a Verilog-A
>subset used as a compact device model it could be just
>assumed that all the connections are inout.. 
>but in any mixed signal situation, I wouldn't want any
>mistake about what direction the signal is.. 
>(unless we are going to have tools that can figure out
>the direction based on what is connected to the net..
>only appropriate for structural models?
>
>Of course I now try to declare the direction in the
>module port list.. 
>module test( output y_p, y_n, inout vdd, gnd, input a,
>b, c, d)
>
>We can't make it OPTIONAL unless 1364-2005 does...
>
>Jonathan.
>
>
>--- "Muranyi, Arpad" <arpad.muranyi@intel.com> wrote:
>
>  
>
>>Hello everyone,
>>
>>Sorry for another clarification question, but there
>>may be
>>an ambiguity in the LRM regarding the port
>>directions.  I
>>am trying to figure out whether these are required
>>or not,
>>because one tool we tried goes on happily without
>>them but
>>another will issue error messages.
>>
>>The 1st paragraph of section 7.1 in LRM v2.2 says:
>>
>>"A module definition is enclosed between the
>>keywords module and endmodule, as shown
>>in Syntax 7-1. The identifier following the keyword
>>module is the name of the module
>>being defined. The optional list of ports specify an
>>ordered list of the module's ports. The
>>order used can be significant when instantiating the
>>module (see Section 7.1.2). The
>>identifiers in this list shall be declared in input,
>>output, or inout declaration statements
>>within the module definition. The module items
>>define what constitutes a module and
>>include many different types of declarations and
>>definitions. A module definition can
>>have at most one analog block."
>>
>>Does "shall be" mean required?  On the other hand,
>>figure
>>7.2 lists them as optional ("|" at the beginning of
>>the line):
>>
>>"module_item_declaration ::=
>>{attribute_instance} parameter_declaration
>>| {attribute_instance} local_parameter_declaration
>>| {attribute_instance} string_parameter_declaration
>>| {attribute_instance}
>>local_string_parameter_declaration
>>| aliasparam_declaration
>>| {attribute_instance} digital_input_declaration
>>| {attribute_instance} digital_output_declaration
>>| {attribute_instance} digital_inout_declaration..."
>>
>>Later, in section 7.4.2.2 the words "shall be"
>>appear again:
>>
>>"Each port listed in the list of ports for the
>>module definition shall be declared in the body
>>of the module as an input, output,or inout
>>(bidirectional). This is in addition to any
>>other declaration for a particular port-for example,
>>a net_discipline, reg, or wire. The
>>syntax for port declarations is shown in Syntax
>>7-8."
>>
>>But figure 7-8 doesn't show them as optional any
>>more.  
>>
>>"input_declaration ::=
>>input [ range ] list_of_port_identifiers ;
>>output_declaration ::=
>>output [ range ] list_of_port_identifiers ;
>>inout_declaration ::=
>>inout [ range ] list_of_port_identifiers ;"
>>
>>What is the rule?  Are these required, or optional?
>>
>>Thanks,
>>
>>Arpad
>>
>>    
>>
>================================================================
>  
>
>>    
>>
>
>  
>
Received on Thu May 4 01:45:38 2006

This archive was generated by hypermail 2.1.8 : Thu May 04 2006 - 01:45:48 PDT