If the I-Cache misses, will the CPU stall until the missed instruction is loaded into the cache? My specific interest is whether the long latency refill (13 uS?) from missed code in the SPI Flash will block an interrupt service routine from starting (even if the ISR code is in the I-Cache) until the Flash cache line is loaded to I-Cache.
Thanks,
Craig
Yes, in this design the I$ blocks until the refill completes, so the processor takes the interrupt, but the ISR can’t be fetched until the miss is satisfied.
Andrew, thanks for that information. I have a related question about non-instruction-fetch reads from the SPI Flash.
Does a data load instruction from the memory-mapped region of the SPI Flash stall the load unit and the CPU execution pipeline until the SPI Flash read is completed? Again, my interest is whether an interrupt could be recognized and ISR code could begin execution while a previously initiated read from SPI Flash is pending. Ideally the long-latency read would be quashed by the interrupt, to be retried after the ISR return, and the interrupt service routine would be able to start execution as soon as the ISR code could be fetched. What does the HiFive implementation actually do?
An alternative to using the memory-mapped SPI Flash for data loads is available by switching the interface mode to a control-register based mode for programmed reads of the SPI Flash contents. This programmed-read mechanism for reading the SPI Flash would presumably would avoid any long-latency read access interruptibility stall issues, but the mode turns off the memory-mapped instruction fetching from the SPI Flash. Is my understanding of this correct?
Thanks, Craig
Does a data load instruction from the memory-mapped region of the SPI Flash stall the load unit and the CPU execution pipeline until the SPI Flash read is completed?
Once the request has going out to the memory bus, the interrupt won’t be taken until the memory access completes. Since MMIO reads could have side effects, it’s not safe to execute them twice if interrupted in the middle.
An alternative to using the memory-mapped SPI Flash for data loads is available by switching the interface mode to a control-register based mode for programmed reads of the SPI Flash contents. This programmed-read mechanism for reading the SPI Flash would presumably would avoid any long-latency read access interruptibility stall issues, but the mode turns off the memory-mapped instruction fetching from the SPI Flash. Is my understanding of this correct?
Right, you can only use one mode or the other.