Assignment of records

[hssig]

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

 

[Bart Fox]

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

 

[KJ]

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

 

[hssig]

"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]

So is there a difference when making the assignment like in BR1 or
like in BR ?

 

[KJ]

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.

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

 

[Andy]

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

 

[KJ]

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

 

[Andy]

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

Andy