Re: [sv-dc] Port directions

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.