Potential pitfall for an assert_equal(std_ulogic) using std_match

[cmarqu]

I am likely to forget about this soon unless I write it down somewhere, so...

In my assert_equal()-like procedure for std_ulogic(_vector), I recently made a change to use std_match() instead of comparing via the "=" operator so that I can have don't care ('-') which was pretty useful so far. The pitfall with std_match() however is that comparing 'X' with 'X' yields false - quite unexpected for a user of an assert_equal :)

I will implement my own match_table soon. The original is e.g. in http://www.eda.org/rassp/vhdl/models/standards/numeric_std.vhd

[martinjthompson]

I see that 'L' and '0' also match (and '1' and 'H')... I'm not sure
whether I like that or not!

Cheers,
Martin

On 5 August 2011 21:22, cmarqu
[email protected]
wrote:

I am likely to forget about this soon unless I write it down somewhere, so...

In my assert_equal()-like procedure for std_ulogic(_vector), I recently made a change to use std_match() instead of comparing via the "=" operator so that I can have don't care ('-') which was pretty useful so far. The pitfall with std_match() however is that comparing 'X' with 'X' yields false - quite unexpected for a user of an assert_equal :)

I will implement my own match_table soon. The original is e.g. in http://www.eda.org/rassp/vhdl/models/standards/numeric_std.vhd

Reply to this email directly or view it on GitHub:
#2

[email protected]
http://parallelpoints.com/

[cmarqu]

Ha, hadn't even noticed that...
I suppose most useful for testbenches is the regular comparison with "=" except when comparing with '-'.
The sloppy matching of std_match() can be achieved with e.g. to_X01 on the actual part of the procedure call. OTOH, assert_equals() would then report this converted value, not the actual value which might be misleading in log files...

[martinjthompson]

On 9 August 2011 20:43, cmarqu
[email protected]
wrote:

Ha, hadn't even noticed that...
I suppose most useful for testbenches is the regular comparison with "=" except when comparing with '-'.

I think you're right, yes.

The sloppy matching of std_match() can be achieved with e.g. to_X01 on the actual part of the procedure call. OTOH, assert_equals() would then report this converted value, not the actual value which might be misleading in log files...

Maybe we could have assert_nearly_equals() :)

Martin

[cmarqu]

assert_nearly_equals() - weeeeell... for reals and physical types, I have an "err" parameter that defines the allowed plusminus error margin (and for completeness's sake, should have err_min and err_max (or better named err_neg/err_pos?)).

[martinjthompson]

On 9 August 2011 21:46, cmarqu
[email protected]
wrote:

assert_nearly_equals() - weeeeell... for reals and physical types, I have an "err" parameter that defines the allowed plusminus error margin (and for completeness's sake, should have err_min and err_max (or better named err_neg/err_pos?)).

That thought had also crossed my mind when I write it :)

Hmmm. I don't suppose you can do this can you?:

function compare(a,b:real; err_neg:real := 0.1; err_pos : real := err_neg)

to get a default "even-sided" comparison?

You have to have two functions?

[email protected]
http://parallelpoints.com/

[cmarqu]

I don't know offhand, but even if it was possible, it would feel awkward from a user's point of view - if you saw a function call like compare(act => 1.1, exp => 1.0, err_neg => 0.2);, you would expect the positive error to be 0.0, not 0.2, right?

Oh, and actually, would you say "err_neg => -0.2, err_pos => 0.2" or "err_neg => 0.2, err_pos => 0.2" if you wanted to allow an error of 0.2 on either side? Makes sense to get the naming just right - assuming that is even possible. :)

[martinjthompson]

On 9 August 2011 22:40, cmarqu
[email protected]
wrote:

I don't know offhand, but even if it was possible, it would feel awkward from a user's point of view - if you saw a function call like compare(act => 1.1, exp => 1.0, err_neg => 0.2);, you would expect the positive error to be 0.0, not 0.2, right?

Yes, I wasn't thinking of using named parameters (when there's only 3
I tend not to) - that's another point in favour of doing it the only
way you can anyway :)

Oh, and actually, would you say "err_neg => -0.2, err_pos => 0.2" or "err_neg => 0.2, err_pos => 0.2" if you wanted to allow an error of 0.2 on either side? Makes sense to get the naming just right - assuming that is even possible. :)

And you (well, I :) also (sometimes) want errors specified in
percentages, or even lsbs :) Could end up with a lot of variants!

[cmarqu]

Percentages and LSBs, good point - I hope we will have all these procedures/functions (maybe even stuff like function wrappers around procedures where useful) at some point in the future. This will lead to such a proliferation that it makes sense to split out the common parts like the error reporting to have it consistent in all cases (but even the reporting needs to know the type of the value it reports... tricky).