Showing results for 
Show  only  | Search instead for 
Did you mean: 
Registered: ‎02-09-2009

problem with ISOCM initialization in EDK 9.2

Hey everyone,


I'm using ML410 board (virtex-4 FX based) and EDK 9.2SP2. I designed a system with 64KB iocm + 64KB docm.

I want a code to reside in these two memories (boot, boot0 and text in isocm and other sections in the data ocm). 

Additionally PPC uses plb bus connected to its DPLB0 port.To this bus, DDR RAM (MPMC) as well as other peripherals are connected


Memory map looks like this (only memories are specified to make the whole "picture" clearer):



(0x88610000-0x8861ffff) ppc405_0_docm_cntlr    ppc405_0_docm
(0xc8000000-0xcbffffff) DDR_SDRAM    plb_v46_data_0
(0xffff0000-0xffffffff) ppc405_0_iocm_cntlr    ppc405_0_iocm


so ppc's reset vector 0xfffffffc is in the isocm.



Dunno why, but this simple design doesnt work.

At first I tried simple bitstream download (since BRAM is used FPGA bitstream download option should do its job I thought), then tried to upload the code (.elf) via xmd (isocmstartadr option specified when connecting to target), without a success. Somehow code is not written properly to this memory (verified mem contents @ reset vector address using memory read insruction in xmd).

Disassembled .elf dump placed @ 0xfffffffc doesnt match the one read in xmd.

Other strange thing is that after resetting cpu (either by rst, rst -processor instr in xmd or even cpu reset button on ML410) PC register doesnt point to reset vector :)

It rather points @ some location @ in Data OCM. :)


PowerPC405 Processor Configuration
User ID.............................0x00000000
No of PC Breakpoints................4
No of Read Addr/Data Watchpoints....1
No of Write Addr/Data Watchpoints...1
ISOCM...............................0xffff0000 - 0xffffffff
User Defined Address Map to access Special PowerPC Features using XMD:
        I-Cache (Data)........0x70000000 - 0x70003fff
        I-Cache (TAG).........0x70004000 - 0x70007fff
        D-Cache (Data)........0x78000000 - 0x78003fff
        D-Cache (TAG).........0x78004000 - 0x78007fff
        DCR...................0x78004000 - 0x78004fff
        TLB...................0x70004000 - 0x70007fff


(somehow cache range is specified - though atually it doesnt cover any range in memory map.

  I'm not using any cache enable/disable instruction in my program. What's more I-cache/D-cache option in the memory address range in EDK is not selected)


XMD% rrd

    r0: ffff101c      r8: 8861827c     r16: 8861827c     r24: 8861827c
    r1: 88610b40      r9: 8861827c     r17: 8861827c     r25: 8861827c
    r2: 8861827c     r10: 8861827c     r18: 8861827c     r26: 8861827c
    r3: 8861827c     r11: 8861827c     r19: 8861827c     r27: 8861827c
    r4: 8861827c     r12: 8861827c     r20: ffffffff     r28: 8861827c
    r5: 8861827c     r13: 8861827c     r21: 8861827c     r29: 8861827c
    r6: 8861827c     r14: 8861827c     r22: 8861827c     r30: 8861827c
    r7: 8861827c     r15: 8861827c     r23: 8861827c     r31: 8861827c
    pc: 88618278     msr: 8861827c



System has been generated by BSB (Base System Builder). After that i removed IPLB1 and DPLB1 connections with DDR RAM).

System synthesizes, PAR without problems. Also software (libs and application) generation phase goes smoothly.

I also tried to simulate the system and actually it behaves in the same way (even in case of functional simulation).

What's wrong with it? Am I doing sth wrong, I cannot think of now, or maybe there is some bug in the EDK. Maybe the only way is to move to version 10?


At the end I would like to mention that, there is no such a strange behavior (as mentioned above) after reset when not using OCM.


Thanks for any help in advance!



0 Kudos
4 Replies
Registered: ‎08-14-2007

Well first, you cannot directly access the ISOCM. It's only indirectly accessible via the DCR on the PPC. This is supposed to be handled by XMD via a special mapping. This is configured either in your xmd.ini or maybe from the MHS file.

Personally, I've never been able to read/write from ISOCM via XMD. I've always had to embed the application into the BRAM at build time.

Just like your experience, I've run into odd issues only w/ the OCM and XMD. I do have plenty of software that runs out of the OCM; I've just been unsuccessful in twiddling with the ISOCM. Generally, in my past experience, the ISOCM was always mapped into XMD at a different location than what the ISOCM was actually addressed at. In your case, it looks like XMD is has it mapped 1:1 with its physical address.

FTR, the PowerPC *always* has cache. It's part of the die. So you can't 'disable' it. Also, if the mapping for the cache isn't made, I've run into issues w/ XMD working at all with the processor. For the cache to operate, you still need to enable the bits in the CCRs. From power-on, the cache can be enabled if the proper bits are set in the config vectors for the PPC. Odds are you don't have that enabled.

-- Mike
0 Kudos
Registered: ‎02-09-2009

Hi Mike,


First of all thx for reply!


As for the DCR connection between PPC and IOCM, answer is yes I know it, and I have it (besides ISOCM and DSOCM have been built by BSB so I guess it should consider such a stuff - connection).

What do you mean by embedding app at the built time, do u mean in the initial FPGA bitstream? Well, I did it the first time but it was not working (on the other hand the same simple app is working in PLB BRAM setting). It's really strange that XMD doesnt handle it, since there are seperate switches for handling  isocm. What are they there for then?

As for the cache, yes, I know PPC405 has 16KB I-cache and 16KB D-cache on die, but still not always do u have to use it in your app right? This is what I meant by "disabling" it. Maybe I should have written "not using it", i.e. not using special instructions enabling it :) Sorry for that.



The thing is I don't need cache for my design. I have OCM after all. DDR is used by other peripherals so processor doesn't need to cache it.

Second thing is, as u said XMD doesnt' work if mapping for cache isnt made, but design doesn't work without using XMD either :)


Still question arises, why PC reg is not set to 0xfffffffc after reset, but rather to some address in DSOCM?

Maybe hardware is not built properly, but neither synthesis report nor the PAR indicates it (all the warnings are simply not relevant as they concern unconnected signals that actually are not used by the system).



0 Kudos
Registered: ‎08-14-2007

The 'wrong' address after reset sometimes occurs when

a) the PPC has been 'hosed': PLB read/write never finished, etc.

b) you downloaded an application. XMD will keep the start address of the application and when reset is called it will set the PC to the start address, not the reset vector. Or, at least that's been my experience.

With regards to the cache-mapping, I just wanted to be clear on this. Without the cache-mapping setup, I've personally run into issues when performing download's of applications even if the cache was disabled, and the application wasn't using it. It seems like way XMD was performing the operations to the processor that it would screw with other options in the processor and afterwards the processor would be 'hosed'.

Yes, by embedding I meant initializing the BRAM in the FPGA bitstream.

You said that you setup the ISOCM/DSOCM with BSB. Did you make any changes to them afterward BSB generated them? How are they mapped into the memory space of the PPC?
0 Kudos
Registered: ‎02-09-2009

I'm sorry for a very late post!


I had to do another important stuff and thus abandonned the OCM problem till now.


Let's have a look at ppc405_virtex4 wrapper's manual :


In "PLB Port Replication" section it is mentioned that:


"... Any ICU request that falls within this address range is directed to IPLB1;otherwise it goes to IPLB0.

A similar base/high address pair defines the response range for the DPLB1 interface,with all out-of-range DCU requests being steered to DPLB0.

Note that if the ISOCM or DSOCM interfaces are used, their address ranges take precedence; such requests do not appear on the processor’s PLB interface."


 The problem is that though OCM interfaces should take the precedence (when being used) disconnecting IPLB1 and DPLB1 interfaces(leaving IPLB0 and DPLB0 connected)

 leads PPC to hang. As u mentioned PPC becomes "hosed".


The question is why such an issue occur. Interfaces IPLB1 and DPLB1 are intended for P2P connections only. Wehn someone decides to use OCM why would he need to use them?


In such a case (DPLB1 and IPLB1 unused) someone may also want to connect PPC to a shared PLB i.e. use DPLB0.


Maybe it is some bug in version 2.00b of this PPCwrapper?


Still, thx for your great effort and time!

0 Kudos