tlm_fifo::try_get

[leitneth]

Hi!

I'm using the method tlm_fifo::try_get in my source as follows:


data = new();
forever begin
@(posedge clk);
data_fifo.try_get(data);
some_var = data.m_value;
end

I supposed that the old data is used, in case that a new item is not available.

The OVM reference clearly states that "the output argument is not modified". However, in my case data is set to null, and I get a seg fault when accessing the member m_value. :eek:

Currently I'm using can_get() as a workaround.

Any comments on this?

Regards,
Thomas

[pmarriott]

I think your problem is that try_get() is a function that returns a status bit. If it fails to get an item, it will return 0. Your code casts it to void and so you don't check that status. But you're correct in that if it fails to get an item, it shouldn't modify the output argument (at least per the reference manual).

I seem to remember in the AVM version, this wasn't the case and it was always the user's responsibility to see if the get succeeded or not before trying to use the returned item which, if it is a class object, will possibly give you null and hence your sigsegv problem.

Paul.

[divyeshg]

Hi Thomas,

As per my understanding your requirement is that whenever you have new packet in fifo you should extract it & assign value to some variable otherwise it should be the previous value only.

problem is that try_get functions gives you status that packet is available or not.

Refer modified code mention below.

code:
bit success;

data = new();
forever begin
@(posedge clk);
success = data_fifo.try_get(data);
if( success)
begin
some_var = data.m_value;
end
end


I hope above code satisfies your requirement.

[leitneth]

Thanks for you replies. I do not check the return value of try_get since I don't need to know wheter there is a new data item available or not. I just want to have a valid one, no matter if it's old or new. And I supposed try_get to do this.

However, since there is a discrepancy with the reference manual (as Paul confirmed) I will have to stick to a workaround, that checks if the get was successful.

Nevertheless I think that the reference manual should be aligned to the implementation to avoid confusion. ;)

Thomas