OnChip Memory - Addressing problem

Hi Matteo,

Can you clarify one point: Are both of your CPUs and peripherals in the same SOPC Builder system? That is, are you trying to put all that into SOPC Builder at once, or two you create two separate designs in SOPC Builder?

The reason I ask: per SOPC Builder system, you have an entire Avalon address space; no two peripherals can share that address space; so it is illegal to have two memories go from 0x1000-0x2000 (for example) even if they are mastered by two CPUs. On the other hand, if you create two separate systems (each with its own unique top-level system-name in SOPC Builder), this would be legal as you have two separate address spaces.

The Nios II IDE should allow this as well, since it looks at the Avalon address space corresponding to the PTF file (SOPC Builder system) that you provide during project creation... if this is not working please feel free to contact Altera support or send me a private message with your two PTF files and I'll investigate.

Some additional notes: If you are putting everything into a single SOPC Builder design and try to setup the addressnig as you are, you should be getting some error messages in SOPC Builder at the bottom of screen describing the addressing problem; this would normally prevent you from generating the HW for the design.

Second note: If you're creating two SOPC Builder designs in the same quartus design folder, I'd strongly reccomend naming all peripherals differently. Example: system1_cpu, system1_rom, system1_uart, system2_cpu, and so on... I think there is a known limitation regarding this because otherwise you'll get HW files generated on top of each other (with the same name).

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

Are both of your CPUs and peripherals in the same SOPC Builder system?[/b]

--- Quote End ---

Yes, they are

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

...per SOPC Builder system, you have an entire Avalon address space; no two peripherals can share that address space...[/b]

--- Quote End ---

Is it true even if each Cpu is the ONLY master of the onchip_memory?

         CPU1                                              CPU2
           |                                                      |
------------------                                 ------------------    
  |                   |                                 |                    |
JTAG1    MEMORY1                          JTAG2      MEMORY2
ONCHIP_MEMORY1: Base Address 0x00000000        Reset Adrress: 0x00000000        Exception Address: 0x00000020
ONCHIP_MEMORY2: Base Address 0x00000000        Reset Adrress: 0x00000000        Exception Address: 0x00000020
=> "cpu_1 and cpu_2: illegal reset address or exception address. All CPU reset or exception addresses must be unique"

This case should not be a problem.... http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/huh.gif there aren&#39;t shared peripherals....each CPU targets a unique memory!?!? http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/dry.gif

In addition, in "AN 184: Simultaneous Multi-Mastering with the Avalon Bus" (page 3) I&#39;ve read:

...becasuse master and slave peripherals are connected with dedicated paths, multiple masters can be active at the same time and can simultaneously transfer data to theis slaves. this simoultaneous multi-master architecture offers great throughput performance advantages compared to a traditional, shared bus architecture. master peripherals do not have to wait to access a target slave peripheral, as long as another master does not access the same slave at the same time....

Please, help me...

Bye, Matteo

Hi Matteo,

I am mistaken! I just talked with some of our Avalon/SOPC Builder team and this is legal; this indicates a bug. I want to let you know that I just tried to generate in SOPC Builder + Build software for a similar system (two CPUs, each with a memory at the same address that is not shared), and this was successful; I am using the next release of Quartus/SOPC Builder/Nios II which is due to be completed in the coming weeks.

As a workaround, could you just define each peripheral with a separate address space and proceed from there?

...Just a note about your comment from AN 184 (I wrote that app note http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif This statement is absolutely true regardless of what the addresses for the slaves are. Envision the address you assign in SOPC Builder as just defining what does into an address decoder to generate a chip select for each of the slave peripherals; if you have one master asking for address x and another for address y, the arbitration logic (muxing) creates a path between each master to each slave simultaneously.... just to prove it, if you ever take a look at the Avalon logic that SOPC Builder generates you can see this by tracing data from slaves up to masters (although this can be a tedious process)... so following the workaround above, you do not lose any performance in your system, you just have a different pointer in your C code...

I had a similar but different problem. I wanted to boot both NiosII cores out of the same onchip RAM, but got the same error msg.

Reading through germs and bootloaer.s I don&#39;t see why this "Unique Address" requirement is necessary. The code should execute in both cpus independently just fine. Can you enlighten? http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif

Thanks,

Ken

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

As a workaround, could you just define each peripheral with a separate address space and proceed from there?[/b]

--- Quote End ---

Ok, in the meantime I&#39;ll try this solution; I hope the new Quartus/SOPC/Nios version will arrive soon.

Thank you very much for your attention, Jesse http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif

PS: Some posts before you&#39;ve written:

<div class='quotetop'>QUOTE </div>

--- Quote Start ---

On the other hand, if you create two separate systems (each with its own unique top-level system-name in SOPC Builder), this would be legal as you have two separate address spaces.

The Nios II IDE should allow this as well, since it looks at the Avalon address space corresponding to the PTF file (SOPC Builder system) that you provide during project creation... if this is not working please feel free to contact Altera support or send me a private message with your two PTF files and I&#39;ll investigate.[/b]

--- Quote End ---

Can you help me with some step-by-step instructions on how to implement this solution, please? I&#39;ve tried to do this in many way but I can&#39;t complete the compilation because of the following error: http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/dry.gif

"Error: Debug node with entity name cpu1_jtag_debug_module and instance name the_cpu1_jtag_debug_module1 has duplicate ID 17843712 -- node ID is used by another node"

Bye

Ok, I solved the problem: this was a bug of the first NiosII release.

We found it in the "Nios II Development Kit Version 1.01 Release Notes":

JTAG Identification Conflicts (SPR 157902)
A mechanism was added to ensure unique Joint Test Action Group (JTAG) identifications for each system module in Quartus II projects with multiple SOPC Builder system modules.

Bye! http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/tongue.gif