Re: Clarification question on port direction

Let me know if we plan to make any changes, I have a
few ideas. 

--- Kevin Cameron <dkc@grfx.com> wrote:

> Jonathan David wrote:
> > I agree, but unless there is a convention that
> > undeclared direction should be considered inout, I
> > would think that (even if advisory for
> conservative
> > disciplines) it would confuse many tools if NOT
> > declared, 
> > and after all doesn't the port direction
> > declaration help to decide which connect rule to
> use?
> I vaguely remember that - it was a really bad idea.
> The connection rules should only use the types of
> drivers
> and contributions that connect to the net, port
> types
> and directions shouldn't be used. I don't think the
> guilty
> parties participate in this committee anymore so
> maybe
> we can fix that now :-) 
> 
> Kev.
> 
> > I don't recall there being a default described
> > anywhere, and without that I see significant
> issues,
> > except in the domain of device modeling where the
> > inout assumption would work well.  
> >
> > Jonathan
> >
> > --- Kevin Cameron <dkc@grfx.com> wrote:
> >
> >   
> >> 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:
> 
=== message truncated ===