A Transparent Wishbone-to-SPI Bridge Supporting Execute-in-Place (XIP)
1–5 of 5 posts
Re: A Transparent Wishbone-to-SPI Bridge Supporting Execute-in-Place (XIP)
#2Nice missing piece of the RISC-V ecosystem puzzle.
Re: A Transparent Wishbone-to-SPI Bridge Supporting Execute-in-Place (XIP)
#3What is the performance impact of execute-in-place? Does a CPU executing instructions out of external RAM offer enough performance to be worthwhile?
Re: A Transparent Wishbone-to-SPI Bridge Supporting Execute-in-Place (XIP)
#4What is the performance impact of execute-in-place? Does a CPU executing instructions out of external RAM offer enough performance to be worthwhile?
This allows you the possibility of booting directly out of the SPI, where you put a first-stage bootloader that copies the rest of the system into RAM.
Lots of systems do this already by means of mask ROM bootloaders; some people might not want a fixed payload provided by someone else to be the first thing that executes. On the other hand, executing out of SPI is very interceptable.
Re: A Transparent Wishbone-to-SPI Bridge Supporting Execute-in-Place (XIP)
#5What is the performance impact of execute-in-place? Does a CPU executing instructions out of external RAM offer enough performance to be worthwhile?
This allows you the possibility of booting directly out of the SPI, where you put a first-stage bootloader that copies the rest of the system into RAM. Lots of systems do this already by means of mask ROM bootloaders; some people might not want a fixed payload provided by someone else to be the first thing that executes. On the other hand, executing out of SPI is very interceptable.
Thank you for the explanation.