VHDL record synthesis

[Flo]

Hi folks,
I'd like to know how a record (containing only std_logic_vector) will
be synthetized.
I explain myself:
1/ I have a memory with 48 bits (for performance purpose).
2/ I want to write on its data bus 3 differents data (one of 12 bit:
D12, one of 9 bits: D9 and one of 11 bits: D11) using a dedicated
position on the bus : D12&D9&D11

I planned to create a record in order to get rid of contant defining
the different ranges but I find nowhere the way the record will be
synthetized : will it be D12&D9&D11 or D11&D9&D12 or something
else ....

maybe it is synthetizer dependant?

thanks for your help.

Florent

[Mark McDougall]

Flo wrote:

> I planned to create a record in order to get rid of contant defining
> the different ranges but I find nowhere the way the record will be
> synthetized : will it be D12&D9&D11 or D11&D9&D12 or something
> else ....

Why does it matter? At some point you're going to have to map each record
element explicitly to a sub-range of the data bus of the memory - right!?!

mem_i.d12 <= mem_d_i(43 downto 32);
mem_i.d9 <= mem_d_i(24 downto 16);
mem_i.d11 <= mem_d_i(10 downto 0);

Depending on what you're trying to achieve, it may be better to use 'alias'?!?

signal mem_d_i : std_logic_vector(47 downto 0);
alias d12_i : std_logic_vector(11 downto 0) is mem_d_i(43 downto 32);
alias d9_i : std_logic_vector(8 downto 0) is mem_d_i(24 downto 16);
alias d11_i : std_logic_vector(10 downto 0) is mem_d_i(10 downto 0);

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, <http://www.vl.com.au>
21-25 King St, Rockdale, 2216
Ph: +612-9599-3255 Fax: +612-9599-3266

[Flo]

thanks a lot.
you are completly true.
It was a false problem.

I will definivelly map my record on std_logic_vector before going to
the memory bus.

thanks a lot.

florent

[Thomas Stanka]

On 5 Aug., 08:20, Mark McDougall <ma...@vl.com.au> wrote:
> > the different ranges but I find nowhere the way the record will be
> > synthetized : will it be D12&D9&D11 or D11&D9&D12 or something
> > else ....
>
> Why does it matter? At some point you're going to have to map each record
> element explicitly to a sub-range of the data bus of the memory - right!?!
>
>   mem_i.d12 <= mem_d_i(43 downto 32);
>   mem_i.d9 <= mem_d_i(24 downto 16);
>   mem_i.d11 <= mem_d_i(10 downto 0);

It is an important matter for more complex records, when debugging the
netlist or performing equivalence checking.
A record containing a memory interface with clock, reset, request,
adress, data is very likely to get flatten out to an array during
synthesis and it is a hard task to ensure, that every bit of the
record is properly connected.

bye Thomas

[KJ]

On Aug 5, 2:04 am, Flo <margabi...@gmail.com> wrote:
> Hi folks,
> I'd like to know how a record (containing only std_logic_vector) will
> be synthetized.
> I explain myself:
> 1/ I have a memory with 48 bits  (for performance purpose).
> 2/ I want to write on its data bus 3 differents data (one of 12 bit:
> D12, one of 9 bits: D9 and one of 11 bits: D11) using a dedicated
> position on the bus : D12&D9&D11
>
> I planned to create a record in order to get rid of contant defining
> the different ranges but I find nowhere the way the record will be
> synthetized

The place to look for this mapping will be in the code that you write.

: will it be D12&D9&D11 or D11&D9&D12 or something
> else ....
>

Your code will define how it is mapped

> maybe it is synthetizer dependant?
>

Nope, designer dependent.

Personally, I like to define 'to_std_logic_vector' and
'from_std_logic_vector' functions that convert between
std_logic_vectors and records. These functions can be defined right
along with the record definition so that you can easily keep the
functions and record definitions in sync. Users that need to convert
to/from the record will simply use these functions and not have to
change anything just because the record defintion changes.

Kevin Jennings

[Andy]

You could also define the ranges on the sub-vectors to match their
positions in the bit range of the larger vector.

signal d12 : std_logic_vector(43 downto 32);
...
d12 <= mem_d(d12'range);

Andy

[Mark McDougall]

Andy wrote:

That's something I commonly do with both signals and aliases - though I
believe in this case it's actually the opposite of what the OP is trying
to achieve via the use of records!?!

[KJ]

On Aug 11, 1:14 am, Mark McDougall <ma...@vl.com.au> wrote:
> Andy wrote:
> > You could also define the ranges on the sub-vectors to match their
> > positions in the bit range of the larger vector.
>
> > signal d12 : std_logic_vector(43 downto 32);
> > ...
> > d12 <= mem_d(d12'range);
>
> That's something I commonly do with both signals and aliases - though I
> believe in this case it's actually the opposite of what the OP is trying
> to achieve via the use of records!?!
>

Not really. As I mentioned in my earlier post, what I do with records
is create to/from std_logic_vector functions that perform the
conversion. I also define the bit mapping in the records so that if
bit mappings need to change, the record definition is the only thing
that needs updating (as Andy's example has also pointed out).

Then when you need to convert your record to a std_logic_vector for
output to memory (OP's case) it is simply

Mem_Data_Out <= to_std_logic_vector(my_record);

Similarly, re-interpreting memory data input as a record is

my_record_readback <= from_std_logic_vector(Mem_Data_In);

No matter how you approach the problem, it still boils down to a
simple type conversion between the record type and the
std_logic_vector. However, the mental block for many is getting to
that realization. If that realization does sink in, the creation of
functions to convert between the two types is an obvious approach
which then allows one to use the functions just as one would use
'to_unsigned' or 'to_integer' from the numeric_std package.

Besides the OP's particular query, this approach also works very well
for handling control/status ports that link the hardware ports to the
definitions that the software folks need for controlling the
device...not to mention testbenches for design verification.

Kevin Jennings

Example:
type t_OP_RECORD is
Reserved: std_logic_vector(47 downto 32);
D12: std_logic_vector(33 downto 20);
D9: std_logic_vector(19 downto 11);
D11: std_logic_vector(10 downto 0);
end record t_OP_RECORD;

function to_std_logic_vector(L: t_OP_RECORD) return std_logic_vector
is
variable RetVal: std_logic_vector(47 downto 0);
begin
RetVal(L.Reserved'range) := L.Reserved;
RetVal(L.D12'range) := L.D12;
RetVal(L.D9'range) := L.D9;
RetVal(L.D11'range) := L.D11;
return(RetVal);
end function to_std_logic_vector;

function from_std_logic_vector(V: std_logic_vector) return t_OP_RECORD
is
...Left as an exercise to the reader...it's very similar though to the
'to' function although one would also want to first copy the input
vector 'V' into an internal variable that has the proper range (i.e.
V_int: std_logic_vector(V'length-1 downto 0)) so that the function
properly handles cases where a vector is input but doesn't happen to
be in the 47..0 range.

[Andy]

This one of those applications where I wish you could do something
like:

for a in t_op_record'range loop -- maybe something other than 'range
here?
l.a <= my_vector(l.a'range);
end loop;

In other words, if we think of the names of the record element as
items in an enumerated type, then we should be able to define a
variable of that enumerated type, and use that variable as a suffix to
access the corresponding element of the record.

IIRC, the latest standard allows unique ranges on arrays within
arrays, so maybe another way around this is to have the outer array be
indexed by an enumerated type, which could then be indexed in a loop,
etc. Then you could use such an enumerated-indexed array of arrays
instead of a record? Of course it is not quite as flexible as a
record, where any element can be any type, not just the same base type
with different ranges.

Just thinking out loud...

Andy