Added cmake support & assertive comparison tester

[ACascarino]

Earlier work fell behind develop, so existing work has been reworked to match
the emerging style and direction of the repository.

In _build(...), specifying cmake now changes behaviour; a
key assumption is that CMakeLists.txt exists
in a superdirectory of the xe_path, and that directory also holds /bin/.

do_run_pyxsim now supports plugins of class XsiPlugin.

pyxsim.py is now guarded against XCC_EXEC_PREFIXes that do not end in /

AssertiveComparisonTester has been added;
this is used in essentially the same way as ComparisonTester, but
uses asserts rather than writing errors to stdout.
Should be more useful for pytest-based frameworks.
Personal opinion is that it's also more readable but that's by the by.

QUESTIONS:

• If we use run_on_simulator as the main point of entry, when it runs _build there are a couple of options it doesn't pass through (clean_only, build_options, and the new cmake, binary_child, silent). Should these be passed through by popping kwargs, similarly to how build_env and do_clean are?)

[xross]

This needs removing. Accidental commit.

[xross]

I'd just be using plugins via sim args, do we need to support plugin args?

[ACascarino]

So XsiPlugin is a class that's defined, see e.g. pyxsim.py, line 454, where an XsiLoopbackPlugin is defined that seems to replicate the Loopback plugin in xsim. This was the last piece needed to actually use it, although whether it needs to exist at all is a good question.
In /theory/ you could define Pyxsim plugins that are clocked alongside simthreads, although in practice why you would choose to make an XsiPlugin rather than a SimThread escapes me (see e.g. the Clock class in lib_i2s/i2s_master_checker.py) - they seem like they're doing the same thing, but plugins are always clocked rather than simthreads which are waited upon.

[xross]

Ah yes, only just noticed this. I must say not sure I understand the utility of this given this whole framework is essentially for creating plugin functionality..

[xross]

Approved. But I think we should remove that erroneous asset and comment.

[xross]

Answer, to the question - yes probably. I recently reinstalled run_on_simulator as main point of entry and probably didn't do a full job. Making people call build did not seem okay (the fact its a "" for one..)

[xross]

Using the ComparisonChecking returning a bool just means the assert happens "further up" the code. You only want to calculate coverage etc on passing tests and checking a bool rather an catching an assert feels nicer but personal preference really (but arguably less "pythonic")

[ACascarino]

Using the ComparisonChecking returning a bool just means the assert happens "further up" the code. You only want to calculate coverage etc on passing tests and checking a bool rather an catching an assert feels nicer but personal preference really (but arguably less "pythonic")

agreed, although do we only want to calculate coverage on passing tests? I always understood coverage to mean "how much of your codebase is exercised", not necessarily "how much of your codebase meets requirements"

Answer, to the question - yes probably. I recently reinstalled run_on_simulator as main point of entry and probably didn't do a full job. Making people call build did not seem okay (the fact its a "" for one..)

also agreed - will add that in this PR then