Alert ERROR in Default

[Joseph]

Hi, I’m working with a test bench that I made in OSVVM. I have a transaction with a proprietary protocol we use at my company. I’m trying to check data when a control signal goes high, but this Default keeps throwing away transactions even though the waveforms look correct. In my testcase, everything passes. It’s in Default, which I’m not entirely sure what that is. This is the error I’m getting: # %% Alert ERROR in Default, ToTransaction/FromTransaction, threw away a 1 at 3330 ns.
When I investigate the time stamps on them, it’s pointing to when I change the address and ExpectedData, which is just the DataToModel. For each transaction, there are two errors corresponding with address and ExpectedData changes. I’m using the Address type record. I can clearly see the waveforms are doing what they are supposed to be doing. Everything should be passing. I’m not sure what those errors are pointing to or what I should do about them. It looks like I have so many errors when everything in the waveforms appears correct. Any insight into those types of errors?

[Jim Lewis]

Hi Joseph,
This is coming from the call to SafeResize that is inside of OSVVM verification components. What it is telling you is that the testbench put a value with more one’s on the left hand side of it in the call to a transaction, such as Write, Read, or Send, than is used by the verification component.

The error will happen when you call Send(StreamRec, X”1FF”) and the VC only uses 8 bits of data internally. Hence, the ‘1’ value on the left hand side of the test case supplied value is thrown away. Instead call Send(StreamRec, X”FF”) and everything is fine. Even calling Send(StreamRec, X”00FF”) is ok as it would be throwing away ‘0’ and the value is not modified.

For a test that has this sort of ERROR, the test case that uses a value of X”1FF”, but expects it to be interpreted as X”FF” is at a minimum obfuscating the intent of the test – as a result OSVVM counts this as an ERROR. VHDL+OSVVM is intended to be able to be used in safety critical environments where this sort of thing is important.

Best Regards,
Jim

[Joseph]

Thanks for the info Jim! I was dealing with some unusual sizes for logic vectors. So, I just resized them in my VC to have a bigger width to capture all of the data since I actually wanted to capture all of the data bits, not just some of them. I now don’t get this error anymore.

[Jim Lewis]

For the next release of OSVVM, I have added an AlertLogID input to SafeResize and all of the OSVVM VC specify the ID on the call to SafeResize. I also updated the error message to be of the following form:

Alert ERROR in AxiManager_1, SafeResize: value changed on resize. Original value: 01AF, Resized value: AF

Hopefully this will clear up the source of the issue in the future.

[Author]

Posts