I’m assuming that your code is running out of SPI Flash, not the Scratchpad RAM. Here are a few ideas:
-
If your routine is fairly small, you could allocate space for it in the SRAM and make sure it is copied there on startup (either manually or by declaring it as initialized data). Then even if it is evicted from the cache, you are dealing with a few cycles cache refill latency, rather than reading-the-SPI-flash latency.
-
Make sure the memory-mapped SPI flash parameters are set reasonably. If you are using the Freedom E SDK on the HiFive1, we conservatively reduce the SPI Flash read speed when we boost the clock speed. You can turn this back up significantly. Look for “SCK_DIV” in the SDK code to see what I mean.
-
To answer your actual question, you can’t explicitly trap on i-cache misses. You can try using the FE310’s breakpoint registers to give you a breakpoint exception if you execute at certain addresses or ranges. You could create a match condition that corresponds to your routine getting evicted, but not sure how you would make it NOT match on the routine you actually care about. FE310-G000 has two of these registers. It doesn’t have any i-cache miss counters or trace logic.
To see more info on the breakpoint registers, see https://dev.sifive.com/documentation/risc-v-external-debug-support-0-11/, Chapter 9, “Trigger Module”.
As for “priming” the instructions without executing them, it’s not really possible (see this thread for why: http://forums.sifive.com/t/connecting-a-camera/294/13?u=mwachs5