Hi Jonathan, Kevin, I dont think we should plan for this change. For LRM2.3 i want to make it clearly focussed on 1364 integration + SV conflicts and any other critical analog fixes that we have agreed upon. This is a big change (not sure yet that it needs to be changed at all) and needs to be understood and discussed before going through with it. As such we are behind schedule and would like to ensure that any syntax/semantic updates with the 2005 merger are done and released as 2.3 before taking up new things. I agree that postponing certain things compounds the issue later, but in this particular case, it might have to be deferred and discussed later. Impacts backwards compatibility, how connect rules are defined in the language and in turn affects how connect module insertion takes place. Regards, Sri Jonathan David wrote: > 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 === >Received on Fri May 5 16:37:05 2006
This archive was generated by hypermail 2.1.8 : Fri May 05 2006 - 16:37:07 PDT