Jaco Hofmann
Jaco Hofmann
Sure, I'm up for it... the runtime is about 90% ready, only waiting for the release of the current milestone.
Sure, would still be nice to have more such tools to better catch regressions.
The new runtime already supports arbitrary memories. Each memory can have one allocator and a number of DMA engines that can be used to access the memory from the host....
Could you run the driver in debug mode and post the corresponding `dmesg` output?
It might be enough to add a new DMAControl implementation in https://github.com/esa-tu-darmstadt/tapasco/blob/master/runtime/libtapasco/src/dma.rs that simply does nothing and use that by at https://github.com/esa-tu-darmstadt/tapasco/blob/8f77c7ccb99214d6f1c1b3560eeb16bbe199e53c/runtime/libtapasco/src/device.rs#L356 and https://github.com/esa-tu-darmstadt/tapasco/blob/8f77c7ccb99214d6f1c1b3560eeb16bbe199e53c/runtime/libtapasco/src/device.rs#L389 and https://github.com/esa-tu-darmstadt/tapasco/blob/8f77c7ccb99214d6f1c1b3560eeb16bbe199e53c/runtime/libtapasco/src/device.rs#L400 Lastly, the correct DMA...
I fear this is a similar problem. When the PEs are created, the runtime will also allocate and register eventfd for interrupt handling. This step needs to be postponed until...
Move to Algun dia as this issue requires a better memory testing infrastructure.
This will be part of the new runtime. I am currently moving the DMA related things from the driver to the runtime which should make changes like this much simpler....
In theory it is not difficult to add additional frequencies to the design. Right now the clock generation for most (all?) platforms is as follows: Memory Clock -> MMCM ->...