Assignment of records

Discussion in 'VHDL' started by hssig, Mar 11, 2011.

  1. hssig

    hssig Guest

    Hi,

    I have the following record assignments which do not behave correctly
    in simulation (getting undefined record elements):


    type tr is record
    a: std_logic;
    b: std_logic;
    c: std_logic;
    end record;

    signal rec : tr;
    signal sig_a, sig_b, sig_c : std_logic;

    BR: block
    begin
    rec.a <= sig_a;
    rec.b <= sig_b;
    rec.c <= sig_c;
    end block;



    The solution seems to be the usage of a process:

    pBR: process(sig_a, sig_b, sig_c)
    begin
    rec.a <= sig_a;
    rec.b <= sig_b;
    rec.c <= sig_c;
    end process;


    Why is the first approach erroneous for simulation ? Does VHDL-2008
    allow the correct use of record assignments in blocks ?
    When using big records the handling of the process sensitivity list
    becomes
    unclear.


    Cheers,
    hssig
     
    hssig, Mar 11, 2011
    #1
    1. Advertising

  2. hssig

    Bart Fox Guest

    Am 11.03.11 08:59, schrieb hssig:
    > rec.a<= sig_a;
    > rec.b<= sig_b;
    > rec.c<= sig_c;

    ....
    >
    > Why is the first approach erroneous for simulation ?

    Put the tree assignments in a single assignment:

    rec <= (a => sig_a, b => sig_b, c => sig_c);

    I use records only in synchronous processes, so there is only the clock
    in the sensitivity list.

    Bart
     
    Bart Fox, Mar 11, 2011
    #2
    1. Advertising

  3. hssig

    KJ Guest

    On Mar 11, 2:59 am, hssig <> wrote:
    > Hi,
    >
    > I have the following record assignments which do not behave correctly
    > in simulation (getting undefined record elements):
    >


    "getting undefined record elements" is not terribly descriptive of
    whatever problem you think there might be.

    > type tr is record
    >     a: std_logic;
    >     b: std_logic;
    >     c: std_logic;
    > end record;
    >
    > signal rec : tr;
    > signal sig_a, sig_b, sig_c : std_logic;
    >
    > BR: block
    > begin
    >       rec.a <= sig_a;
    >       rec.b <= sig_b;
    >       rec.c <= sig_c;
    > end block;
    >
    > The solution seems to be the usage of a process:
    >
    > pBR: process(sig_a, sig_b, sig_c)
    > begin
    >      rec.a <= sig_a;
    >      rec.b <= sig_b;
    >      rec.c <= sig_c;
    > end process;
    >
    > Why is the first approach erroneous for simulation ?


    It's not erroneous for simulation. Either approach is correct.

    > Does VHDL-2008
    > allow the correct use of record assignments in blocks ?


    Yes...as does VHDL-2002, -93 and -87...it's always been there.

    > When using big records the handling of the process sensitivity list
    > becomes
    > unclear.
    >


    Why is it unclear? You still have to add any signal to the
    sensitivity list that is on the right hand side of an assignment, any
    signal that is used to determine some conditional assignment, no
    different than if you had a 'small' record.

    KJ
     
    KJ, Mar 12, 2011
    #3
  4. hssig

    hssig Guest

    KJ wrote:
    > "getting undefined record elements" is not terribly descriptive of
    > whatever problem you think there might be.


    After starting the simulation record element "a" does not show the
    contents of "sig_a" but 'U'. Exactly the same behavior on the other
    record elements when using a block for assignments.


    > rec <= (a => sig_a, b => sig_b, c => sig_c);


    So is there a difference when making the assignment like that

    BR1: block
    begin
    rec <= (a => sig_a, b => sig_b, c => sig_c);
    end block;


    or like that


    BR: block
    begin
    rec.a <= sig_a;
    rec.b <= sig_b;
    rec.c <= sig_c;
    end block;


    Cheers,
    hssig
     
    hssig, Mar 13, 2011
    #4
  5. hssig

    hssig Guest

    So is there a difference when making the assignment like in BR1 or
    like in BR ?
     
    hssig, Mar 13, 2011
    #5
  6. hssig

    KJ Guest

    On Mar 13, 3:41 pm, hssig <> wrote:
    > KJ wrote:
    > > "getting undefined record elements" is not terribly descriptive of
    > > whatever problem you think there might be.

    >
    > After starting the simulation record element "a" does not show the
    > contents of "sig_a" but 'U'. Exactly the same behavior on the other
    > record elements when using a block for assignments.
    >


    Since rec.a, rec.b and rec.c are all defined as std_logic type, and
    std_logic is an enumerated type whose leftmost element is 'U', that is
    exactly the correct behavior.

    > > rec <= (a => sig_a, b => sig_b, c => sig_c);

    >
    > So is there a difference when making the assignment like that
    >
    > BR1: block
    > begin
    >     rec <= (a => sig_a, b => sig_b, c => sig_c);
    > end block;
    >
    > or like that
    >
    > BR: block
    > begin
    >       rec.a <= sig_a;
    >       rec.b <= sig_b;
    >       rec.c <= sig_c;
    > end block;
    >


    No difference except for the extra typing. It also doesn't matter if
    the code was not in a block statement either.

    architecture foo of bar is
    begin

    rec <= (a => sig_a, b => sig_b, c => sig_c);
    -- rec.a <= sig_a;
    -- rec.b <= sig_b;
    -- rec.c <= sig_c;

    end foo;

    KJ
     
    KJ, Mar 14, 2011
    #6
  7. hssig

    Andy Guest

    On Mar 13, 2:43 pm, hssig <> wrote:
    > So is there a difference when making the assignment like in BR1 or
    > like in BR ?


    Three concurrent assignments create three implied processes. Each
    process creates a driver for the entire aggregate. Unspecified
    elements in each implied process create drivers with value 'U'. When
    the driven values are resolved, the 'U' values from the other two
    processes override the value from the process that explicitly drives a
    non-U value.

    When you group these into a single process, one driver gets created
    from that process for the entire aggregate. There are no unspecified
    elements, and no drivers created for them, so it works as you
    expected.

    IIRC, an aggregate has only one event, so anytime any element of the
    aggregate has an event, the entire aggregate gets it, which in turn
    means all the other elements get the event.

    Andy
     
    Andy, Mar 14, 2011
    #7
  8. hssig

    KJ Guest

    On Mar 14, 6:04 pm, Andy <> wrote:
    > On Mar 13, 2:43 pm, hssig <> wrote:
    >
    > > So is there a difference when making the assignment like in BR1 or
    > > like in BR ?

    >
    > Three concurrent assignments create three implied processes. Each
    > process creates a driver for the entire aggregate.


    Not in the OP's case. The three separate concurrent assignments drive
    only the specified element of the record.

    > Unspecified
    > elements in each implied process create drivers with value 'U'. When
    > the driven values are resolved, the 'U' values from the other two
    > processes override the value from the process that explicitly drives a
    > non-U value.
    >


    This is not true...at least not for the case presented in this thread
    which is individual assignments of record elements.

    > When you group these into a single process, one driver gets created
    > from that process for the entire aggregate. There are no unspecified
    > elements, and no drivers created for them, so it works as you
    > expected.
    >


    The OP's code does not create multiple drivers for the record type
    signal 'rec'. The concurrent assignment approach and the process
    approach are for all practical purposes equivalent.

    Kevin Jennings
     
    KJ, Mar 15, 2011
    #8
  9. hssig

    Andy Guest

    Oops, I believe you may be right. Is this because the sub-elements are
    statically identified?

    Andy
     
    Andy, Mar 15, 2011
    #9
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Luke Airig
    Replies:
    0
    Views:
    816
    Luke Airig
    Dec 31, 2003
  2. nagy
    Replies:
    36
    Views:
    1,041
    Terry Reedy
    Jul 20, 2006
  3. Chris
    Replies:
    34
    Views:
    1,567
  4. Dan

    Delete records or update records

    Dan, May 10, 2004, in forum: ASP General
    Replies:
    1
    Views:
    480
    Ray at
    May 10, 2004
  5. Replies:
    3
    Views:
    695
    Anthony Jones
    Nov 2, 2006
Loading...

Share This Page