Subject: Re: $sv-ec alias proposal comments
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Mon Nov 11 2002 - 15:09:44 PST
> From: "Francoise Martinolle" <fm@cadence.com>
>
> Kevin,
>
> I finally got around reading your alias proposal. I have found a couple of
> potential issues that we have to clarify.
>
> First I would like to say that creating aliases is already possible in
> Verilog by creating a module called alias which short cicuit its ports.
>
> Example:
> module alias (a, a)
> inout [WIDTH:0] a;
> endmodule
>
> Then instantiate it in module top to alias b and {c,d} together:
> module top
> wire [15:7] b;
> wire [7:4] c;
> wire [3:0] d;
>
> alias #7 u1( b, {c, d});
> end module
Yes, but that methodology is less usable with the newer (ANSI style) port
syntax, and it means you don't see the short-circuit in the module where
it applies until elaboration time.
> I agree that your proposal may be more convenient as it formally allows to declare aliases but I
> wanted to point out that currently users can do the same with the current Verilog language.
>
> The only thing I would like to specify in your proposal is what the resolved net type when
> the net aliased together have diffent net types.
> For example, you could have a tri0 wire aliased to a wand wire. What is the resulting inout
> net type?
The proposal says that aliasing nets is much the same as if they had been joined through
ports - i.e. the same rules apply and the resulting net type would be the same.
> The net type resolution table in the Verilog 1364 LRM (section 12.3.10 in the 1364 -2001 standard
> only deals with resolution of net types across ports and resolves it to either the external net type or
> the internal net type and in some situations issue a warning. The resolution as stated in the LRM is
> not a symmetrical relationship between external and internal: for example between tri0 and wand,
> tri0 not always wins. The external type wins.
For the sake of argument you can consider the alias statement as being eqivalent to a module instantiation
(of the kind above) that has jumpered ports, the semantics should be the same.
> The problem in the ec proposal is that the net type resolution is not specified. Also we cannot
> use the table 45 in the Verilog 1364 LRM because in the current alias proposal, nets can be aliased
> at the same level of hierarchy.
The resolution is supposed to be the same.
> I also feels that the rules for addressing specification errors when declaring aliases are superfluous.
> The proposal states 2 rules: not allowed to alias a net to a sub-element of itself, not allowed to specify a
> given alias more than once. Why these rules? I feel that we should be able to short circuit whatever. Is
> there any reason for these rules?
The rules are currently strict with a view to relaxing them later, the intention is to help users
avoid unintentional short-circuits that might be tricky to find.
I would still like to add a "no connection" syntax to make it easier to specify multiple overlapping
aliases, but we can add that later if there is a general demand.
> Francoise
> '
Alias is also meant to replace undelayed continuous assigns:
assign a = b;
becomes:
alias a = b;
The latter version requires less work by the simulator and doesn't cause problems
for Verilog-AMS (which would view the assign as a seperate digtal process if the
wires a & b are analog, and would insert A->D and D->A conversions).
Kev.
This archive was generated by hypermail 2b28 : Mon Nov 11 2002 - 15:10:49 PST