02-09-2009 09:00 AM
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
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)
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!
02-09-2009 10:33 AM
02-09-2009 09:12 PM
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).
02-10-2009 06:56 AM
06-02-2009 06:49 AM
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!