Re: $sv-ec Aliases


Subject: Re: $sv-ec Aliases
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Oct 31 2002 - 10:12:18 PST


Updated version.
---------------------------------------------------------------------------------

     BNF ~:

        <alias_statement> ::== alias <net_lvalue> = <net_lvalue>{ = <net_lvalue>}

The LRM text would be:

    X.Y Signal Aliasing

    The SystemVerilog assign statement is a unidirectional assignment and may incorporate a delay and
    strength change. To model a bidirectional short-circuit connection it is necessary to use the alias
    statement. The members of an alias list are signals whose bits share the same physical wires.
    The example below implements a byte order swapping between bus A and bus B.

        module byte_swap (inout A, inout B);
            wire [31:0] A,B;
            alias {A[7:0],A[15:8],A[23:16],A[31:24]} = B;
        endmodule

    This example strips out the least and most significant bytes from a four byte bus:

         module byte_rip (inout W, inout LSB, inout MSB);
            wire [31:0] W;
            wire [7:0] MSB,LSB;
            alias W[7:0] = LSB;
            alias W[31:24] = MSB;
        endmodule

   The bit overlay rules are the same as those for a packed union with the same member types: each
   member should be the same size and connectivity is independent of the simulation host.
   Any net data types can be used in an alias list as long as the resulting connections do not violate
   the rules for net connection that would apply if the nets were being joined at a port.
   Variables and hierarchical references cannot be used in alias statements. Any violation of these
   rules is considered a fatal error.

   The same nets can appear in multiple alias statements, the effects are cumulative. The following
   two examples are equivalent, in either case low12[11:4] and high12[7:0] will share the same wires:

        module overlap(inout bus16, inout low12, inout high12);
            wire [15:0] bus16;
            wire [11:0] low12,high12;
            alias bus16[11:0] = low12;
            alias bus16[15:4] = high12;
        endmodule

        module overlap(inout bus16, inout low12, inout high12);
            wire [15:0] bus16;
            wire [11:0] low12,high12;
            alias bus16 = {high12,low12[3:0]};
            alias high12[7:0] = low12[11:4];
        endmodule

   To avoid errors in specification it is not allowed to specify an alias from an individual signal to
   itself or to specify a given alias more than once, so the following version of the code above
   would be illegal since the top four and bottom four bits are the same in both statements:

            alias bus16 = {high12[11:8],low12};
            alias bus16 = {high12,low12[3:0]};

   This alternative is also illegal because the bits of bus16 are being aliassed to itself:

            alias bus16 = {high12,bus16[3:0]}
                        = {bus16[15:12],low12};

   Alias statements can appear anywhere a module instance would appear, and any undeclared nets
   in the alias statement are assumed to be scalar as they would with a module instance. The
   following example uses alias along with the automatic name binding to connect pins on cells
   from different libraries to create a standard macro:

       module lib1_dff(Reset,Clk,Data,Q,Q_Bar);
            ...
       endmodule

       module lib2_dff(reset,clock,data,a,qbar);
            ...
       endmodule

       module lib3_dff(RST,CLK,D,Q,Q_);
            ...
       endmodule

       macromodule my_dff(rst,clk,d,q,q_bar); // wrapper cell
          input rst,clk,d;
          output q,q_bar;
          alias rst = Reset = reset = RST;
          alias clk = Clk = clock = CLK;
          alias d = data = D;
          alias q = Q;
          alias Q_ = q_bar = Q_Bar = qbar;

          `LIB_DFF(.*); // Any of lib1_dff,lib2_dff or lib3_dff

        endmodule

   Using a net in an alias statement does not modify it's syntactic behavior in other statements.
   Aliasing is performed at elaboration time and cannot be undone.

---------------------------------------------------------------------------------------------------

I think there were some conflicting requests so the above is my best effort at comprimise - let
me know if you still have issues with it.

Regards,
Kev.

--
National Semiconductor, Tel: (408) 721 3251
2900 Semiconductor Drive, Mail Stop D3-500, Santa Clara, CA 95052-8090



This archive was generated by hypermail 2b28 : Thu Oct 31 2002 - 10:13:24 PST