Closed gcc42 closed 8 years ago
One of the things we can do is use pytest.mark.xfail
, meaning that we know the test is failing and we will get to it in the future.
I commented before looking at the code, you used the xfail
, perfect.
In general this works for now, specific tests can still be setup to verify an exception is raised:
with pytest.raises(ValueError):
run_testbenchd(bench, args=args)
This will allow the test to produce the error conditions and validate the exception is being raised. This is very helpful in development, because developers are informed of these error early on.
Right now, the errors mainly occur on the nvacant
and ntenant
, I need to think about it more but the range of these counters can be extended so the errors don't occur here but can occur else where. The whole idea of ExceptionSignals will take a while to flush out.
Reverted the changes to fifo_fast
. I still think those 2 checks I inserted would be useful, but that is the topic of another discussion now. This PR now only contains the added tests. If the Travis passes(it will take a long time, though :) ), I think you can now merge it into master.
@forumulator thanks, yes I for the fifo_fast
we need to do some homework and make sure the fifo_fast
still infers the SRL type FIFO, since the SRL FIFO is limited resources I think the additional checks will break the inference. Two ways to check this: 1) look at the vendor synthesis guides; 2) (better) use rhea.build
to compile the fifo_fast
for various targets and verify before the changes and after the changes.
Three things:
Your thoughts?