Re: EXTERNAL: Re: [vhdl-200x] Directional records proposal

Hi Jim,
Yes, Ryan mentioned this too. If there's a simple way to resolve elements
of records, I would like to use it.
Then, the declarations could be something like

signal cpu_bus_add: resolveRecordAdd t_cpu_bus.add;
signal cpu_bus_dat: resolveRecordDat t_cpu_bus.dat;
...

As an alternative, I was thinking of doing that iteratively within the
resolution function, but resolve only those elements we need.
So, in this case, the resolution function can return an incomplete record,
or a record slice, having only those elements we want resolved. Or perhaps
even returning the whole record, but leave some elements as don't cares.
Not so sure if that's even possible.

I was thinking in the lines of (in this case, I return a whole record, but
with some elements as don't cares):
function resolveRecords(signal someRecordArray: t_cpuBusVector) return
t_cpu_bus is
    variable resolvedRecord: t_cpu_bus;
begin
    ...
    resolvedRecord := (adr | dat => (others=>'-'), we | en => '-',
others=>'-'); -- defaults to don't cares.
    resolvedRecord.adr := resolves_adr_bus_from_multiple_drivers;
    resolvedRecord.dat := resolves_dat_bus_from_multiple_drivers;

    -- the other elements are not resolved, and defaults to don't cares...
will this work?

    return someRecordArray;
end function resolveRecords;

I may have overlooked something, just let me know.

regards, daniel

On 18 July 2012 01:01, Jim Lewis <Jim@synthworks.com> wrote:

> Hi Daniel,
> For resolution of the record, I think we want resolved elements
> and not resolved records themselves. By having a resolution
> function on the element, the record elements can be driven
> from separate processes. I think when you resolve the entire
> record, every process that drives an element puts a driver on
> the entire record.
>
> Having resolved elements also allows the problem to be approached
> piecewise. For bit values, you can use std_logic or any resolved
> array of std_ulogic (std_logic_vector, signed, unsigned, ...).
> For my testbenches I also use integers, real, and time in the record,
> so I have resolution functions for these.
>
> Best,
> Jim
>
>
>
> I think checking for the literal '-' doesn't work too well with matching
>> case statements, so we'll have to remove the first "when" condition. Then
>> our matching case statement becomes:
>> case? (someRecordArray(0).i)(j) & (someRecordArray(1).i)(j) is
>> when "UX" | "XU" => (resolvedRecord.i)(j) <= 'X';
>> when "U-" => (resolvedRecord.i)(j) <=
>> (someRecordArray(1).i)(j);
>> when "-U" => (resolvedRecord.i)(j) <=
>> (someRecordArray(0).i)(j);
>>
>> when "X-" | "-X" => (resolvedRecord.i)(j) <= 'X';
>> when "W-" | "-W" => (resolvedRecord.i)(j) <= 'W';
>> when "ZZ" => (resolvedRecord.i)(j) <= 'Z';
>> when "Z-" => (resolvedRecord.i)(j) <=
>> (someRecordArray(1).i)(j);
>> when "-Z" => (resolvedRecord.i)(j) <=
>> (someRecordArray(0).i)(j);
>>
>> when "10" | "01" => (resolvedRecord.i)(j) <= 'X';
>> when "HH" => (resolvedRecord.i)(j) <= 'H';
>> when "11" | "1H" | "H1" => (resolvedRecord.i)(j) <= '1';
>> when "00" | "0L" | "L0" => (resolvedRecord.i)(j) <= '0';
>> when others => (resolvedRecord.i)(j) <= 'X';
>> end case?;
>>
>> A question that arises is how do we check for the literal '-' in a
>> matching case statement? I wan't to check for the literal '-' and not treat
>> the literal as a don't care. But for the rest of the
>> "when" conditions, I would like the matching case statement to treat '-'
>> as don't cares instead of literals.
>>
>> My intention:
>> when "--" => (resolvedRecord.i)(j) <= '-';
>> checks for the string literal "--", and not treat them as don't cares.
>>
>> But the '-' within this "when" clause
>> when "Z-" => (resolvedRecord.i)(j) <=
>> (someRecordArray(1).i)(j);
>> should be treated as a don't care.
>>
>> regards, daniel
>>
>> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~
> Jim Lewis
> Director of Training mailto:Jim@SynthWorks.com
> SynthWorks Design Inc. http://www.SynthWorks.com
> 1-503-590-4787
>
> Jumpstart your VHDL Verification with our OSVVM Bootcamp training
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~**~
>
>
Received on Tue Jul 17 10:41:00 2012