Re: [sv-dc] Port directions

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.
>
>
>

-- 
--------------------------------------------------------------------
Gordon Vreugdenhil                                503-685-0808
Model Technology (Mentor Graphics)                gordonv@model.com
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.