This is a major problem for testing NAC3 here in practice, as we similarly rely on ndscan to centrally provide the experiment execution logic in a generic fashion (variable numbers and types of…
My remark was about the changes to numba llvmlite, that change cause experiments requiring DMA to fail (firmware assert failed). IDK what exactly is causing this issue.
Ah, I understand –…
What are you worried about regarding DMA? Accesses to memory-mapped locations of course need to be marked as volatile, but that isn't really related to the autovectorizer or DMA.
Oh, the autovectorizer definitely does something for a few tests, like for instance some of the (IIRC integer) math throughput tests from the paper. It's just that interestingly, it leaves e.g. the…
What's the impetus here? Being able to cross-check with ARTIQ booted from FSBL in case of any issues?
Though I'm not insisting on that idea; we can instead specify that all ARTIQ firmware protocols always use the endianness of the core device, and have the core device announce its endianness when…
Isn't there the same problem with numpy_full, numpy_full_matrix and numpy_nan?
Yes, there is/was.
Shall we remove this specific test case?
Yes; in fact, I did that on that passes branch just now. (There are also a few similarly broken test cases, which I also removed – RPC of arrays is…
The test_embedding one is actually invalid code, and compiles only because of https://github.com/m-labs/artiq/issues/1497 (the memory just hapens to be uncorrupted with less aggresive…
The test_wait_for_rtio_counter one is interesting; nowrite (which is translated to "trivial" TBAA metadata) causes the wait loop to be optimized out.
Opened #122, #123, #124, #125 for the remaining features. (These are not on the contract, but potentially quite useful, at least for writing tests.)