??? 03/15/11 20:10 Read: times |
#181595 - Using FPGA Resources Responding to: ???'s previous message |
I agree that using the FPGA resources for the MCU is probably a good idea if the program size is small.
If larger then I would build a hardware boot loader to squirt SPI Flash contents into RAM for execution. If RAM in the FPGA was more a expensive resource than I/O pins you could hang some RAM off the side of the FPGA. I like the SPI becasue it is so simple to get an in-system programmability for it in place that works without having to involve the MCU core at all. Wait states for MCU cores can be a problem for designs that do not support them. :-) If they were available the design of a direct execute interface to SPI flash can be simple but byte by byte fetch would suck big time when it comes to performance considerations. To make direct execute "reasonable" it is really necessary to design the SPI interface to support a small cache of say 256 bytes that are all read from the SPI flash via one read command. Fetchs from nearby addresses can then come right out of the cache. More sophisiticated designs for this may make use of additional cache space to support more pages of SPI flash content so that code flow can proceded out of one cache buffer whilst other data references may get cached in other buffers. Michael Karas |
Topic | Author | Date |
8051 core in Actel ProASIC3L FPGA | 01/01/70 00:00 | |
NOR Flash | 01/01/70 00:00 | |
re: NOR | 01/01/70 00:00 | |
PITA | 01/01/70 00:00 | |
SPI vs parallel | 01/01/70 00:00 | |
Using FPGA Resources | 01/01/70 00:00 | |
Better with multiple, smaller, pages than one large. | 01/01/70 00:00 | |
FPGA rom | 01/01/70 00:00 | |
What Triscend did | 01/01/70 00:00 |