Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
8 years ago

multi-core NIOS boot

Hi guys,

I'm going to design an FPGA system with two NIOS processors implemented an a Cyclone V device (not the SoC on, the one without ARM core).

Each NIOS should be connected to a dedicated SDRAM memory where the application code should run to.

SDRAM access should be NIOS-exclusive: NIOS A cannot access to SDRAM B and NIOS B cannot access to SDRAM A.

The only allowed boot device is an EPCS memory.

My concern is about NIOS boot-up phase.

I've read Altera ug-20001 generic nios ii booting methods user guide and, in case of single NIOS, I can set NIOS reset vector pointing to EPCS controller base address. In this case a bootloader is automatically included in EPCS controller during build flow and at system reset it shall copy NIOS code from EPCS to SDRAM and launch application.

Is this possibile also in case of two NIOS processor? Is enough to set both NIOS reset vector pointing to EPCS controller base address??

I've also looked at the threads below but they describe a slightly different situation.

The first one has two EPCS controller while the second one is not applicable since NIOS application has a very difference sizes.

http://www.alteraforum.com/forum/showthread.php?t=21504

http://www.alteraforum.com/forum/showthread.php?t=50536

(http://www.alteraforum.com/forum/showthread.php?t=50536)

Here is a system block diagram

http://www.alteraforum.com/forum/attachment.php?attachmentid=13313&stc=1

3 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    You can't get both Nios cores to boot from the EPCS simultaneously. They will both try to access the EPCS at the same time and will probably get corrupted data back. You need to hold one CPU B in reset and boot CPU A. When CPU A is ready it can deassert the reset signal on CPU B so that it can boot. Will you run the exact same software on both CPUs? If you need a different software on CPU B, then you will need a custom bootloader for it so that it picks it up from the correct place in the EPCS. You can put this custom bootloader in an on-chip ROM and have the CPU B's reset vector set to that memory.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    Hi Daixiwen,

    thanks for your answer.

    The two NIOS shall run *different* softwares.

    From my understanding the boot process that you are suggesting is the following one

    [1] - FPGA configures itself by reading *.sof from EPCS. From now on both NIOS start working.

    [2] - NIOS_A keeps NIOS_B to reset state and executes boot-copier located in EPCS controller boot-rom

    [3] - Once NIOS_A boot has completed, NIOS_A application is launched and it releases NIOS_B from reset

    [4] - NIOS_B executes the bootloader located into on-chip memory boot-rom

    [5] - Once NIOS_B bootloader has finished the system is up and running =)

    I guess that keeping NIOS_B in reset state while at step [2] can be achieved by modifying the default boot-loader of NIOS_A.

    I've got a doubt about this point: soon after step [1] completes both NIOS start to execute rommed bootloaders that in turn both try to access EPCS device.

    At this point NIOS_A bootloader should be able to keep NIOS_B in reset and, in doing so, it grants exclusive access to EPCS device.

    This works fine if NIOS_A start a bit before NIOS_B. But, from my understanding, there is no guarantee that the latter condition is met.

    Theoretically both NIOS start soon after step [1] completes and both try to access EPCS device potentially compromising both NIOS boot process.

    Is this condition possibile? NIOS_B should be kept in reset in another way?

    Last question : someone know how is possible to place a custom bootloader to boot-rom?

    Thanks again
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    8 years ago

    I can think of two ways of doing it[list][*]write your own component to generate the reset signal for CPU-B. It would start asserted, and CPU-A would write something to your component to deassert the reset signal. This can be done from CPU-A's application software when it starts, you don't need to modify the bootloader.

    [*]instead of keeping CPU-B in reset at startup, put a wait loop very early in its bootloader. It would then wait for a signal from CPU-A before executing the rest. You could use a mailbox component for this purpose, and it could also be used afterwards by your applications if you need some sort of communication between the two CPUs[/list]

    application note 458 (https://altera.com/content/dam/altera-www/global/en_us/pdfs/literature/an/an458.pdf) should give you the information you need about custom bootloaders.