xmos-jmccarthy
commented
2 years ago It was found that high priority is required for the qspi and spi to meet real world timing when the system is at 8 cores.
For now, the API has been updated to let the user know of this behavior in #36.
The qspi issue will go away when we switch to the next tools qspi library. We may need to revisit SPI in the future. One difference between the usage in these IO drivers is that the SR bits are only set during the actual transaction. This makes their impact on the overall application potentially less, depending on how frequently the interface is used.
The impact on RTOS applications should be nonexistent, as these will ideally only use 5 cores per tile.
Setting this bit guarantees performance of the current thread to f/5 minimum. However it also reduces the performance in other non-priority HW threads. Setting more than 4 can also be very strange. It is safer to do it dynamically than before a while(1) but you are just reducing the probability of MIPS robbing rather than preventing it. You could in some cases severely starve other threads resulting in unpredictable behaviour. Eg. 3 priority HW threads being active would reduce others to ~48MIPS temporarily.
The attached slide shows this. I recommend using an f/8 design philosophy is possible as this means all other HW threads will get a guaranteed minimum of f/8. This means no use of XS1_SR_QUEUE_MASK anywhere.
xs2-training.pdf.pdf