Scott Gravenhorst wrote:
.. As far as I have read about isolated cores, the kernel doesn't schedule anything to run on them (kernel 4.1.13), so I would expect that they don't handle interrupts either (though I'll have to research that to be sure). Cache hit/miss activity will certainly affect an isolated core's performance tho. ...
By making long memory strides of read and write with no overlapping address areas that would get cached at the first read of a block of addresses that correspond to a cache entry, you could try to find the minimum memory access speed as more or less the pure memory access speed, i.e. without any caching helping the speed. Normally, that raw memory speed should pretty much be a given for reading the code of your DSP routine, as well as for accessing the data for you computations in memory.
The other thing then to make an estimation for is how much contention you'll get for memory access from the other core(s), and also to the point: how long will it take for contention problems to resolve in the worst case. So if the Linux running core(s) on the processor do a high priority memory access or interrupt servicing or get DMA request acknowledgement, what's the time frame in which you know for certain your isolated core will get an amount of memory access for it's instruction (pre-) reader or for it's instructions with memory access, and how much bandwidth is that going to be?
I've though about connecting the Zynq and the RPI I have to let the Zynq do headless computations and use the FPGA for musical computations, and letting the RPI do for instance connections with USB keyboards and possibly (USB) DACs as well as slightly accelerated graphics and UI jobs like user USB sticks with data/samples, patch editors, etc. and maybe use the Parallella board with it's Giga bit ethernet for networked audio as well. However, that means there must be communication like you suggested for instance for Midi data over a (serial ?) connection that can work pretty fast and reliable, and for the way I'd prefer to program (with no lost data) it would have to so some seriou buffer control. A ethernet switch between the two boards would be ok, but I'd prefer some fast enough possibly serial connections with normal handshake and buffer empty/half full/full signals that between the FPGA and the RPI handler program communicate with a latency that's well under control, and normally without errors.
T. _______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
