Re: 2-state 4-state behaviour

From: Clifford E. Cummings (cliffc@sunburst-design.com)
Date: Mon Apr 05 2004 - 17:52:01 PDT

  • Next message: Kurt Baty: "Re: 2-state 4-state behaviour"

    Hi, all -

    Let me clarify and correct my last email. I have attached a simple wand
    test that helped, but it does not fully answer the questions.

    See below.

    At 05:08 PM 4/5/2004, Clifford E. Cummings wrote:
    >Hi, Dave -
    >
    >A couple of clarification questions below.
    >
    >At 04:23 PM 4/5/2004, Dave Rich wrote:
    >>Hi,
    >>
    >>I while back I had a discussion with Kurt about the packed 2/4 state
    >>issue and orthogonality with wires. He suggested I post it to this group.
    >>BTW, I am now on the btf-dtype reflector
    >>
    >>If its not too late...
    >>
    >>A reason to have packed structs behave as a 4-state vectors when used as
    >>a whole is that a packed struct is basically an implied union, and the
    >>behavior should match that of an explicit union. This is a better reason,
    >>and adds to the "good for the implementation" reason I gave at the
    >>btf-dtype meeting.
    >>
    >>For example, suppose I have the following explicit packed union:
    >>
    >>typedef struct packed {
    >> bit [7:0] byteA;
    >> reg [7:0] byteB;
    >>} AB_t;
    >>
    >>union packed {
    >> AB_t AB;
    >> reg [15:0] V;
    >>} U;
    >>
    >>initial begin
    >> U.AB.byteA = 8'h55;
    >> U.AB.byteB = 8'hzz;
    >> V = V << 4;
    >> $displayh(V); // expect to see 5zz0
    >> $displayh({U.AB.byteA,U.AB.byteB}); // expect to see 50z0
    >
    >Is this supposed to be 55zz?

    The first display of shifted V makes sense (5zz0)
    The second display still seems like it should be 55zz. I don't understand
    where the 50z0 comes from.

    >> end
    >>
    >>Now lets take the implicit union version. AB as a whole is a 4-state bit
    >>vector that is in an implied union with the packed structure.
    >>
    >>
    >>AB_t AB;
    >>initial begin
    >> AB.byteA = 8'h55;
    >> AB.byteB = 8'hzz;
    >> AB = AB << 4;
    >> $displayh(AB); //expect to see 5zz0
    >> $displayh({AB.byteA,AB,byteB}); //expect to see 50z0
    >
    >Again, is this supposed to be 55zz?

    Same as above.

    >>A similar approach with can be used when overlaying data types with wires.
    >>
    >>In Verilog-2001, the strength system is used for driving wires and
    >>passing through MOS primitives. However, when reading wires, they are
    >>converted to a 4-state values. Using SystemVerilog terminology, we would
    >>say that "they are cast to a 4-state value when used in an integral expression"
    >>
    >>A wire declared with a user defined data type should behave as an
    >>implicit union between the wire net type and variable data type. You
    >>always uses the net type for driving, and the data type for reading. (you
    >>never write to a wire, except via the PLI)
    >
    >For orthogonallity reasons, I have proposed the following:
    >
    >Part of SystemVerilog now: variables allow either:
    > one or more procedural assignments -OR-
    > one and only one driver assignment (such as a continuous assignment)
    > NOT BOTH (error)
    >
    >Proposed: nets would allow either:
    > one or more driver assignments (such as resolved continuous
    > assignments - part of Verilog today)
    > -OR-
    > (NEW) - procedural assignments from one and only one procedural
    > block (this type of net would be treated exactly like a Verilog variable today)
    > NOT BOTH (error)
    >
    >This orthogonallity makes life much easier for Verilog designers.
    >
    >>What this means is that you can have multiple drivers with different
    >>strengths on an wire with a user defined type, and the wire will be
    >>resolved using the standard rules for that net type. It is only when that
    >>wire needs to be cast to an integral expression that the data type is used.
    >
    >Same thing for the orthogonal net proposal.
    >
    >>For example, lets say I have a wired and declared with the type AB_t above.
    >
    >For clarity:
    >>typedef struct packed {
    >> bit [7:0] byteA;
    >> reg [7:0] byteB;
    >>} AB_t;
    >
    >>wand <AB_t> ABw;
    >>pullup pA[7:1] (ABw.byteA[7:1]); // pullup all but bit 0
    >>pullup pB[7:1] (ABw.byteB[7:1]); // pullup all but bit 0
    >>buf (ABw.byteA[7],0); // will be 0 because strong0 overrides pull1
    >>buf (ABw.byteB[7],0); // will be 0 because strong0 overrides pull1
    >
    >These bits are 0 because of wand, not strength resolution??

    I'm still not sure about this. It may be a combination of strong0 anded
    with pull1.

    >>buf (ABw.byteA[6],1'bx); // will be 0 because strongX overrides pull1,
    >>and X cast to 0
    >
    >Agreed. Bit-type cast from 4-state to 2-state
    >
    >>buf (ABw.byteB[6],1'bx); // will be X because strongX overrides pull1
    >
    >Agreed. 4-state retains X value.
    >
    >>buf (weak0,weak1) (ABw.byteA[5],0); // will be 1 because pull1 overrides
    >>weak0
    >>buf (weak0,weak1) (ABw.byteB[5],0); // will be 1 because pull1 overrides
    >>weak0
    >
    >These bits are 0 because of wand, not strength resolution??

    This was a pull1 from the attached sample. I thought "anding" would win
    over "strength"

    >>buf (pull0,pull1) (ABw.byteA[4],0); // will be 0 because wire-and of 1 and 0
    >>buf (pull0,pull1) (ABw.byteB[4],0); // will be 0 because wire-and of 1 and 0
    >>buf (pull0,pull1) (ABw.byteA[3],1); // will be 1 because wire-and of 1 and 1
    >>buf (pull0,pull1) (ABw.byteB[3],1); // will be 1 because wire-and of 1 and 1
    >
    >Agreed.
    >
    >>buf (pull0,pull1) (ABw.byteA[3],1'bx); // will be 0 because wire-and of 1
    >>and x, cast to 0
    >
    >Agreed. Bit-type cast from 4-state to 2-state
    >
    >>buf (pull0,pull1) (ABw.byteB[3],1'bx); // will be x because wire-and of 1
    >>and x
    >
    >Agreed. 4-state retains X value.
    >
    >>initial #1 #1 for (i=7;i>=0;i=i-1) $display("%b %v %b %v ",
    >> ABw.byteA[i], ABw.byteA[i], ABw.byteB[i], ABw.byteB[i],,i);
    >>endmodule
    >>
    >>Will display
    >>0 St0 0 St0 7
    >>0 StX x StX 6
    >>1 Pu1 1 Pu1 5
    >
    >Shouldn't these bits be: 0 We0 0 We0 5??

    Per the attached sample, these were indeed Pu1. I was surprised.

    >>0 Pu0 0 Pu0 4
    >>0 PuX x PuX 3
    >>1 Pu1 1 Pu1 2
    >>1 Pu1 1 Pu1 1
    >>0 HiZ z HiZ 0
    >>
    >>Note that the only difference in the table above is the x and z is
    >>converted to 0 for binary representation of byteA.
    >>
    >>With this proposal, "logic" becomes the default type for wires and
    >>behaves exactly as a wire would in Verilog.
    >
    >"logic" previously prohibited multiple continuous assignments to the same
    >variable. When applied as a type for nets, multiple resolved values are
    >now permitted?
    >
    >>wire <logic> foo; // is equivalent to
    >>wire foo;
    >>
    >>By making "logic" the default type for both reg and wire, I believe we
    >>merge all the different proposals together and still be backwards
    >>compatible with existing SV. (still need to work out the best syntax)
    >>
    >>Dave
    >
    >Sorry for the questions. I am just not quite sure I fully understand.
    >
    >Regards - Cliff
    >
    >>--
    >>--
    >>David.Rich@Synopsys.com
    >>Technical Marketing Consultant and/or
    >>Principal Product Engineer
    >
    >Cute title: "and/or" (is this a join_any or join_none title? ;-)
    >
    >>http://www.SystemVerilog.org
    >>tele: 650-584-4026
    >>cell: 510-589-2625
    >
    >----------------------------------------------------
    >Cliff Cummings - Sunburst Design, Inc.
    >14314 SW Allen Blvd., PMB 501, Beaverton, OR 97005
    >Phone: 503-641-8446 / FAX: 503-641-8486
    >cliffc@sunburst-design.com / www.sunburst-design.com
    >Expert Verilog, SystemVerilog, Synthesis and Verification Training


    This archive was generated by hypermail 2.1.4 : Mon Apr 05 2004 - 17:35:29 PDT and
    sponsored by Boyd Technology, Inc.