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: >>>> >>>> "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 22:41:55 2006
This archive was generated by hypermail 2.1.8 : Thu May 04 2006 - 22:42:01 PDT