Reply To: OSVVM TestBench needs Access to EXTERNAL FSM_STATE Enum Type

[Jim Lewis]

Hi Dave,

You either have to access the type or a representation of the type.   As you pointed out, since there is no external name reference for a type, so you cannot do that and to get direct type access, you would need to move the type to a package – which for some would be unacceptable.

Hence, you need to pursue access to a representation of the type.   As you noted to_string is a candidate and to_string is implicitly defined for all scalar types, so you could indeed use it in the RTL design.  However, then you would need also need to call justify to make sure the lengths of the strings matched.  Then for coverage modeling you need to a unique integer value for each state which means you need to convert the string to a unique integer value – so I would not pursue this direction.

The approach I would pursue is to use type integer.   The state type can be converted to an integer value by using type_name’pos(state_signal_name).   Unfortunately this means the following would need to be added to the RTL code.   For teams where the testbench team is not allowed to touch the RTL code, the testbench team would need to request that the RTL team ado the addition:

signal State_int : integer ;
. . .
State_int <= FSM_STATE'pos(State) ;

For some synthesis tools the assignment may need to be surrounded by — synthesis translate_off and — synthesis translate_on.   However, since the integer value is not used for anything, it does not imply any hardware creation. 

Best Regards,
Jim