Constraining Array Subtypes Based on Already-Constrained Subtype of Element
Capability/request summary
It does not seem to be possible to constrain an array type based on an already-constrained subtype of its element (without having to resort to copy-pasting the constraints of said elements' subtypes); if done so, it is either confused with a resolution or type conversion. However, it might be in the interest of reducing redundancy to propose an alternative syntax to accomplish this.
Current Status
Currently, we are able to constrain an array subtype, including its elements' subtypes, in the following format:
-- For context, 'params_t' is an unconstrained record of 'weights' and 'biases';
-- 'weights' is defined to be a nested array of std_logic_vector arrays and 'biases'
-- is an array of std_logic_vector.
subtype constrained_params_t is params_t (
weights (0 to c_MAX_DIM.rows-1) (0 to c_MAX_DIM.cols-1),
biases (0 to c_MAX_DIM.rows-1)
);
-- For context, params_arr_t is an unconstrained array of the 'params_t' record.
subtype constrained_params_arr_t is params_arr_t (0 to c_NUM_LAYERS-1) (
weights (0 to c_MAX_DIM.rows-1) (0 to c_MAX_DIM.cols-1),
biases (0 to c_MAX_DIM.rows-1)
);
Notice how the record's constraints itself are repeated twice, once for the actual record subtype and once for what would be a derived array of it.
Use Models | Code Examples
Be aware that you might be tempted to define constrained_params_arr_t
as follows:
type constrained_params_arr_t is array (0 to c_NUM_LAYERS-1) of constrained_params_t;
However, that is wrong and, in the eyes of the typing system, constrained_params_arr_t
would no longer be "compatible" with the unconstrained type of params_arr_t
. In a practical use model, one could declare constrained_params_arr_t
to be a constrained subtype array (i.e., not an entirely different array type) of its further-constrained subtype.
Questions
In order to increase clarity or not introduce breaking syntactical changes, we could explore alternative syntaxes for the below-mentioned change, as needed.
Proposed changes
To avoid ambiguity with the pre-existing resolution/type-conversion functionality in constraints, I propose extending subtypes to support the usage of "of" to further constrain derivative types based on already-constrained subtypes:
subtype constrained_params_t is params_t (
weights (0 to c_MAX_DIM.rows-1) (0 to c_MAX_DIM.cols-1),
biases (0 to c_MAX_DIM.rows-1)
);
-- Reduced redundancy while ensuring that 'constrained_params_arr_t' is still "compatible"
-- with the unconstrained type of 'constrained_params_t'
subtype constrained_params_arr_t is params_arr_t (0 to c_NUM_LAYERS-1) of constrained_params_t;