VHDL 2008 : How to set a generic default to be the initial v

T

Tricky

Guest
So Im messing arround with VHDL - Ive created a package that contains a linked list with a generic type.

There is one issue I cant seem to work out in my head - is it possible create a generic that defaults to the initial value of the generic type? At the moment, when the there are no values in the list, the "get_item" function will return the default value of the generic type - so I want to give the package a "null_value" generic, so it is easy to detect a null return (ie an empty list).


package ll_test_pkg is
generic (
type data_t;

null_value : data_t := <what goes here?>;
);

type link_list_t is protected

procedure add_item( i : data_t );

impure function get_item return data_t;

end protected link_list_t;

end package ll_test_pkg;



I could just force the user to explicitly specify the null_value when instantiating the package, but it would be nicer (for me) if it defaulted to the initial value of data_t.

I could also make the get_item a procedure that outputs a data_t and an empty_list boolean, but I wondered if the above was possible?
 
On Monday, November 17, 2014 9:37:31 AM UTC-5, Tricky wrote:
I could just force the user to explicitly specify the null_value when instantiating the package, but it would be nicer (for me) if it defaulted to the initial value of data_t.

I'm not sure what you mean by the 'initial value of data_t', but inside your function, if you declare a variable that is eventually the one to be returned, that variable will get initialized to the leftmost value of the type.

Example:

function get_item return std_logic is
variable RetVal: std_logic; -- RetVal will initialize to 'U' because it is the leftmost value in the definition of std_logic
begin
return(RetVal);
end function get_item;

Kevin Jennings
 
On Monday, 17 November 2014 15:10:28 UTC, KJ wrote:
On Monday, November 17, 2014 9:37:31 AM UTC-5, Tricky wrote:
I could just force the user to explicitly specify the null_value when instantiating the package, but it would be nicer (for me) if it defaulted to the initial value of data_t.


I'm not sure what you mean by the 'initial value of data_t', but inside your function, if you declare a variable that is eventually the one to be returned, that variable will get initialized to the leftmost value of the type.

Example:

function get_item return std_logic is
variable RetVal: std_logic; -- RetVal will initialize to 'U' because it is the leftmost value in the definition of std_logic
begin
return(RetVal);
end function get_item;

Kevin Jennings

Well yes, that is what I already have. But I want the possibility of the user specifying the null_value, which needs to be done on the generics. I can leave it without a default value, but that forces the user to explicitly specify the null_return, even if it is the initial value, for every package instantiation.
 
if data_t is always scalar, then use data_t'left as the initializer for null_value:

null_value : data_t := data_t'left;

If data_t can be scalar, array or record type, you may be outa luck...

Andy
 
On Tuesday, 18 November 2014 04:46:00 UTC, Andy wrote:
if data_t is always scalar, then use data_t'left as the initializer for null_value:

null_value : data_t := data_t'left;

If data_t can be scalar, array or record type, you may be outa luck...

Andy

Yup, I suspect outta luck - as the whole point is it could be any data type. You cant even use 'left as you dont know at that point what type of type it is.
 
You could provide a procedure to set the null value. Until/unless the user calls the procedure, use the default value of data_t. You could also implement a lockout to prevent using the set_null_value() procedure after add_item() has been called.

Andy
 
On Thursday, 20 November 2014 04:50:28 UTC, Andy wrote:
You could provide a procedure to set the null value. Until/unless the user calls the procedure, use the default value of data_t. You could also implement a lockout to prevent using the set_null_value() procedure after add_item() has been called.

Andy

This is all a bit proof of concept anyway at the moment - but these are good ideas.

Linked lists have often featured in my testbenches, so having a linked list in a package would mean I wouldnt have to essentially do a copy/paste into every new testbench that uses different storage types. Looking forward to it :)
 
One thing that is going to infuriate me though is the protected type limitations:

Cannot have arrays of protected types.
Cannot have function/procedure arguments that are access types (or records that contain access types) in protected type member functions.

So I may have to move away from protected types to define the linked list in the package, and just store the linked list in the package itself, as you can now define variables in a package if the package is local to a process/function/procedure.
 
In my generic linked list/scoreboard, pop when the list is empty is an assert failure.

OTOH, if you are looking to return type'left, why not just declare a local variable:
impure function pop return data_t is
variable result : data_t ; -- defaults to left most value of type
begin
if not empty then
result := top.value ; -- get
-- remove top cell from list
return result ;
else
report "FIFO_PKG: POP called when list empty" severity failure ;
return result ; -- type'left by default
end if ;
end function pop ;


I have the following already on the VHDL-201X list. Do you have any more?
Cannot have arrays of protected types.
Cannot have function/procedure arguments that are access types
(or records that contain access types) in protected type member functions.

Drop me a line as I have a package that you may like.
 

Welcome to EDABoard.com

Sponsor

Back
Top