Re: [sv-dc] Port directions

We are trying to extend the language here, so some things will have to change. The requirement (IMO) is

a) The simulator should accurately represent whatever it is trying to model
b) Extensions should be backward compatible: old SV should exhibit the same behavior

i.e. there is no point in maintaining stuff that doesn't work properly, and you can rewrite the semantics any way you like if it doesn't change the observed behavior - you should not have one set of semantics for "old" code and another for "new".

If possible things should be pushed into user space so that the LRM does not bloat endlessly, e.g. if we generalize the type system then it should be possible to move the existing types into "standard" header files, rather than having them described in detail in the LRM.

Kev.

On 02/15/2011 02:27 PM, Gordon Vreugdenhil wrote:
>
> Kevin,
>
> The point that I was trying to make was that anything that we
> do must be in the context of existing SV digital -- that is the limit
> of our mandate. So we must take care in dealing with various
> situations to not impact digital behavior and coupling port and
> resolution behavior with types can easily do that for "var" cases
> if we're not careful. So being aware of the "var" rules is, I believe,
> very important to keep in mind.
>
> BTW, the "single writer" is in 1800-2009 10.3.2:
> Variables can only be driven by one continuous assignment or by
> one primitive output or module output.
> That couples with text in 6.5:
> ... Alternatively, variables can be written by one continuous
> assignment or one port.
> and the port rules in 23.3.3.2:
> A continuous assignment shall be implied when a variable is connected
> to an input port declaration.
>
> So the term "single writer" isn't used explicitly, but the LRM is clear
> on intent and requirements.
>
> Interesting that you saw a warning. 23.3.3.1 says:
> A port that is declared as input (output) but used as an output (input)
> or inout may be coerced to inout. If not coerced to inout, a warning
> shall be issued.
>
> So I guess the simulator in question must have not treated the net as
> an inout which would certainly cause compatibility issues (not collapsing
> the net in these situations would be very surprising). Of course the
> simulator may have decided to give additional lint-like warnings, but
> there is no LRM requirement to do so.
>
> Gord.
>
>
> On 2/15/2011 2:04 PM, Kevin Cameron wrote:
>> I don't think the "var" stuff is relevant to this discussion since we are mostly interested in wire behavior.
>>
>> Your language about "single writer" doesn't appear in my copy of the LRM, what it says is:
>>
>> An input port can be connected to any expression of a compatible data type.
>> A continuous assignment shall be implied when a variable is connected to an input port declaration.
>> Assignments to variables declared as input ports shall be illegal.
>> If left unconnected, the port shall have the default initial value corresponding to the data type.
>>
>> Anyway, it doesn't really matter what the rules are, just that they probably only apply under certain conditions for certain types. I think you are making the argument for my latter suggestion that it would be better to push this into user space by making the check a method of the user-defined type, since the first case you give seems to violate the rules.
>>
>> BTW: my Verilog simulator gives a warning for the "assign w = 1".
>>
>> This also wanders into the territory of what does a continuous assignment mean in the context of user-defined types. The LRM language implies it creates a driver and has directionality, but the usage is often just to connect a few wires together and you may not want the directionality. I added the "alias" statement to SV (way back) so that there was an explicit short-circuit in the language to avoid the directionality problem for handling analog nets (since other short-circuit syntax had disappeared).
>>
>> Maybe "assign" should also be a method of the user-defined type so you can choose. It might have to work like a connect module if you want to instantiate an alias.
>>
>> Kev.
>>
>> On 02/15/2011 11:19 AM, Gordon Vreugdenhil wrote:
>>> Kevin,
>>>
>>> "logic" doesn't dictate the authority of the direction -- "var" or "wire"
>>> does. So a "wire logic" and "var logic" behave differently in terms
>>> of the port direction rules and whether "collapsing" rules are applied.
>>>
>>> So the following is perfectly legal:
>>>
>>> module child(input wire logic w);
>>> assign w = 1;
>>> endmodule
>>>
>>> module top;
>>> wire r;
>>> child c(r);
>>> endmodule
>>>
>>> While the following variation is not (since it violates the "single writer"
>>> rule which is related to the direction authority question):
>>>
>>> module child(input var logic w);
>>> assign w = 1;
>>> endmodule
>>>
>>> module top;
>>> wire r;
>>> child c(r);
>>> endmodule
>>>
>>> This version becomes legal if "input" is changed to "output" (again,
>>> due to the "single writer" rule and the assumptions regarding
>>> drivers above/below for a variable port.
>>>
>>> I don't think that I'm prepared to take a position on your suggestion
>>> for coupling the type and direction for analog, but that is not what
>>> SV digital does right now.
>>>
>>> Gord.
>>>
>>>
>>>
>>> On 2/15/2011 10:35 AM, Kevin Cameron wrote:
>>>> Just a note on port directions:
>>>>
>>>> The markers for port direction (input/output/inout) can only apply for certain driver/receiver types, i.e. they make sense for "logic" drivers and receivers, but not for analog types. Since users like to add direction to ports regardless of how the driver/receiver mechanisms actually work, it is probably best if the enforcement of port direction is part of the type definition. Since the existing behavior for "logic" is strict enforcement, the default behavior should be that, with a type attribute being added to say the direction is not enforced, e.g.:
>>>>
>>>> class Thev_t....
>>>>
>>>> function bool enforce_directions;
>>>> enforce_directions=false;
>>>> endfunction;
>>>>
>>>> I use a member function so that it gets inherited.
>>>>
>>>> If you do cross type resolution as I previously described by converting drivers before resolving, the direction rules would be checked at the level of the resolution, i.e. if logic drivers were converted to Thev_t drivers the direction rules would be ignored.
>>>>
>>>> Extensions of the methodology could include adding user-defined check routines for the different i/o cases, e.g.:
>>>>
>>>>
>>>> function bool enforce_directions(port_direction io);
>>>> case (io)
>>>> output: // check for driver below
>>>> ...;
>>>> input: // check no drivers below
>>>> ...;
>>>> endcase
>>>> enforce_directions=false; //OK
>>>> endfunction;
>>>>
>>>> - you could add more i/o keywords and checks if you wanted, e.g. testing for a pull-up in wired-or.
>>>>
>>>> Kev.
>>>>
>>>>
>>>>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.