Is it valid to have an array of enumerated properties?

If generating a device worker with an enumerated property, then it seems only partially supported in the HDL code generation - specifically it’s not possible to generate an array of enumerated properties.

An xml property of:

is valid and uses a long type and generates VHDL code for the enumeration and code to convert from a value to the type.

If arraylength=‘4’ is added, then the enumerate type and enumerated array type are generated, but the default value definition fails with invalid VHDL code generated, either:

if not specifying a default:-
constant my_default_led_state_value : work.sdrboard_i2c_control_constants.led_state_array_t := (others => <invalid enum 0x0>_e);

if specifying a single default (default=‘led_on’):-
constant my_default_led_state_value : work.sdrboard_i2c_control_constants.led_state_array_t := (led_on,led_off,led_off,led_off_e);

if specifying multiple defaults (default=‘led_on,led_on,led_on,led_on’):-
constant my_default_led_state_value : work.sdrboard_i2c_control_constants.led_state_array_t := (led_on,led_on,led_on,led_on_e);

Now obviously my work-around is to not use an array, but I was expecting this to work. Is this something I’m doing wrong or is it my expectation incorrect?

Just from what you’ve said here, this certain seems like a bug to me.

To clarify does this code literally generate as the string <invalid enum 0x0>_e?

constant my_default_led_state_value : work.sdrboard_i2c_control_constants.led_state_array_t := (others => <invalid enum 0x0>_e);

Given that the single default case somewhat correctly use led_off, it’s surprising that the no default doesn’t do anything reasonable.

W.R.T. workaround, I’d personally prefer to keep the array and not use the enum instead. Then define an enum in the VHDL, or a series of parameter properties for the valid values. That way if this is fixed it’d be easier to update to use the enum array again.

Thanks Dom

Looks like I’d failed to put an escape character infront of the xml so it didn’t show in the post

With this xml:

<property name=‘led_state’ type=‘enum’ arraylength=‘4’ enums=‘led_off,led_on,led_flash’ writable=‘true’ />

The code generates the invalid VHDL in the target directory -impl.vhd file:

– internal signals between property registers and the readback mux
– for those that are writable, readable, and not volatile
– or enumerations or string arrays/sequences
signal my_led_state_value : ulong_t;
– Constant default value of array/sequence property
constant my_default_led_state_value : work.sdrboard_i2c_control_constants.led_state_array_t := (others => <invalid enum 0x0>_e);

The type and array type are correctly generated in the gen directory -defs.vhd file:

type led_state_t is (led_off_e, led_on_e, led_flash_e); type led_state_array_t is array (0 to 3) of led_state_t;

Then adding defaults causes a slightly different error, so changing the xml to:

<property name=‘led_state’ type=‘enum’ arraylength=‘4’ enums=‘led_off,led_on,led_flash’ writable=‘true’ default=‘led_off,led_off,led_on,led_flash’/>

Give the generated -impl.vhd to become:

constant my_default_led_state_value : work.sdrboard_i2c_control_constants.led_state_array_t := (led_off,led_off,led_on,led_flash_e);

Where all but the last initialiser value are missing the _e. It kind of suggests from this and the above that the “_e” is added once at the end instead of after each value when converting from the xml enum to the corresponding VHDL enum value.

This is on 2.4.7