OSVVM TestBench needs Access to EXTERNAL FSM_STATE Enum Type

Tagged: Enum_Type

This topic has 4 replies, 3 voices, and was last updated 7 years, 7 months ago by Eilert Backhus.

Viewing 5 posts - 1 through 5 (of 5 total)

Author

Posts
December 6, 2016 at 06:28 #1236

Dave Ansell
Member

To Jim Lewis
is there Any other way of doing it Without MODs to DUT?

Enumerated Type is Only Type that HASN’T GOT A NAME or RESERVED Word!!!!

———————————————————-
It would be VERY Useful if we could Use:-
ALIAS FSM_STATE_HANDLE is \<\<signal DUT.FSM_STATE : Enum\>\>;
or
ALIAS FSM_STATE_HANDLE is \<\<signal DUT.FSM_STATE : INCOMPLETE_Type_Name\>\>;
or
ALIAS FSM_STATE_TYPE_HANDLE is \<\<TYPE DUT.FSM_STATE_Type : NULL\>\>;
BUT WE CAN’T.
———————————————————-

When your OSVVM TestBench needs to be able to Read FSM_STATE Enumerated Type
You need to use an EXTERNAL Name.
EG:-
ALIAS FSM_STATE_HANDLE is \<\<signal DUT.FSM_STATE : FSM_STATE_Type\>\>;

BUT
FSM_STATE_Type is Declared in the VHDL Code for the FSM in the DUT.
SO
Declare FSM_STATE_Type in a Package & Use this Package in the FSM & the TestBench

This is MESSY because it means that you have got to create a package just for 1 type every time you want to do this & you may have to go back & alter an Existing Design.
AND
If you Change States in the FSM,
you have to make MATCHING Changes to FSM_STATE_Type in the Package.

THE PROBLEM is:-
There are 2 situations where putting FSM_STATE Enumerated Type in a Package is NOT Possible.
1.
You are NOT AUTHORISED to Change the VHDL Code in the DUT.
2.
The VHDL Code for the FSM is Generated Code.

**************
* WORKAROUND *
**************
— In the TestBench Declarations,
— An IDENTICAL DUPLICATE of FSM_STATE_Type WILL ALLOW FSM_STATE Ext Name to be used.
type FSM_STATE_Type is (State_1,State_2,State_3);
— This is UGLY
— it appears to work in ModelSim BUT may NOT in other Simulators.
—
— You could use Signal Spy BUT that is also NOT Portable

*********************************************************************

MORE EXPLANATION
—————-

SO
ALIAS FSM_STATE_HANDLE is \<\<signal DUT.FSM_STATE : FSM_STATE_Type\>\>;
WON’T WORK
Without FSM_STATE_Type.

It would be MUCH EASIER if you could use:-
ALIAS FSM_STATE_HANDLE is \<\<signal DUT.FSM_STATE : Enum\>\>;
OR
Use an EXTERNAL Name for a Type.

With other types eg: Std_Logic_Vector, INTEGER_VECTOR etc,
you don’t even have to Specify a constraint.
BUT
There is No Reserved Word for Enumerated Type (Eg: Enum see above.)
AND
You Can’t use an EXTERNAL Name to get a Type.
AND
You Can’t use an INCOMPLETE Type for FSM_STATE_Type

…………………………………..
Std_Logic is ALSO an Enumerated Type
But
it HAS got a NAME & so has INTEGER & Character etc.
…………………………………..

To_String works with ALL Enumerated Types
SO
The Function Declaration for To_String would interesting
Because
an Enumerated HASN’T GOT A NAME or RESERVED Word!!!!
BUT
It is a built in Function

You COULD NOT WRITE YOUR OWN To_String Function for ALL Enumerated Types
Because
There ISN’T a Reserved Word for Enumerated Type

Enumerated Type is the Only Type that HASN’T GOT A NAME!!!!

December 6, 2016 at 07:00 #1242

Dave Ansell
Member

The Double Greater than or Less than Chars used for External Names Really seem to mess up Forum Posts so I Put a \ in front of them.

December 6, 2016 at 08:24 #1243

Jim Lewis
Member

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

December 6, 2016 at 08:43 #1244

Dave Ansell
Member

Thanks for your reply.

So

as I thought, there is NO other way of doing it Without MODs to DUT

&

This Rules out generated Code.

So VHDL Needs Fixing

The most Flexible Fix would be:-

ALIAS FSM_STATE_TYPE_HANDLE is \<\<TYPE DUT.FSM_STATE_Type : NULL\>\>;

But

ALIAS FSM_STATE_HANDLE is \<\signal DUT.FSM_STATE : INCOMPLETE_Type_Name\>\>;

Would be OK

I won’t hold my breath for the next Version of VHDL.

In the Meantime I’ll use a Duplicate Type Declaration because ModelSim accepts it even though IT SHOULDN’T.

May 9, 2017 at 22:41 #1345

Eilert Backhus
Member

Hi Dave,

It might be a little late now, but since you mentioned Modelsim:

There’s a feature of Modelsim called SignalSpy.

With these functions you can access any signal of instances below your testbench, working similar to the way you proposed in the beginning.

Here’s how to use it:

https://www.pldworld.com/_hdl/2/_ref/se_html/manual_html/c_vhdl29.html

Have a nice simulation

   Eilert
Author

Posts

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.