fpga4fun.com

Good morning everybody,
I am new in this forum, so that I apologyze if this is not the exact place where to ask this question.

I am starting to design and develop a multi-core SoC architecture in a Xilinx Virtex-6 FPGA for my research interests. The target architecture is composed of two "regions": the one in which a single-core soft-processor resides, and on which the OS runs, and a second region in which a multi-core architecture resides (at least 9 cores there). This will act as a co-processor, thus executing only application code and no OS (something like the GP-GPU paradigm).

I have a couple of questions on that. Let's just focus on this now: where does the software code will reside? I mean, in a FPGA-based design, is the application software hard-coded in the design or does it reside on the off-chip memory?

Thanks in advance for your help
Kind regards

Simone

hi,

software can be placed in preinitialized RAM and ROM inside the FPGA (and inside the design binary). If you load it after programing and starting the FPGA with a debuging cable it can be placed in RAM inside and outside of the chip.

Dear Case23, thanks for your reply.

Great! So, as far as I understand, I would be able to download software code in particular on-chip RAM blocks, and treat them as a sort of program cache for one of the cores in my co-processor, isn't it? I also guess some support from the tools should be given, right? Do you know whether Xilinx tools support this?

Again, thanks for your help

Cheers
Simone

hi,


to preinitialize "cache" would be hard to do. but you can store your program code in normal RAM. I am not sure about xilinx tools, but there should be some support for helping on this. (altera has this)

I would preinitialize only the code for the main processor, make the RAM of the coprocessors accessable by the main processor, and connect the reset signal of the co processors not to the main reset but make it controlable by the main processor (dont know if xilinx supports this). This way you can load the code for the coprocessors at runtime.

Hi,

right, that was my feeling too. It seems more reasonable to let the host processor load at run-time the software directly in the RAM of the coprocessors. I will try that

if the reset of the coprocessors is always connected to the main reset signal, you can supply a shared ROM (no need for performance) with some small boot code which waits for code to be stored in the local ram of the coprocessor.