Write of 64 from PowerPC to my IP conected to the PLB?

Hello, I have designed a IP Slave connected to the PLB bus. My IP Slave to the PLB is a Bus bridge which connect the PLB to another Bus and a Coprocessor connected to this other Bus. My second bus allow transfer of 64 bits and there is a DMA conected to this bus. I want to write to data of 64 bits to the addres 0x2000 and 0x2001, the addres of the DMA. If I write this data the DMA start to work and copy from a memory to a Bram conected to the plb in the memory addres FF000000

I need to transfer these data: addr= 0x00002000 data=0x00000000FF000000 // source (bram) in the second bus and Destination (bram in the plb) addr= 0x00002001 data=0x0000000100000005 //start data and Frame relay ( a burst of 5 double words stored previously in the bram of the second bus)

I want to do it from the PowerPC, that means I have to create a C program to do it. The drivers created for Xilinxs Platform Studio make transaction of 32 bits. They make also transaction of a Struct of 64 bits, with lower and Upper part. This transaction takes place in two operations. First copy to addr 0x00002000 the data 0x00000000 00000000 and with a BE byte enable to choose only the first 32 bits and write to the address 0x2004 of the data 0x FF000000 FF000000. with byte enable. But this is not the operation that I need to run the DMA.

Have someone any idea?

I saw this information in this forum, that was written in 2006, I would like to know if one year later have someone a solution. Thank you

Question: I have a piece of IP that acts as a slave on the PLB. I would like writes to this IP to be 64bits, while reads from it are OK at 32bits. The sample driver that was generated by the IP wizard gives functions for reads/writes or 32 bits as expected (by mapping them to XIo_In/Out32). Do I need to do writes in two transfers? If not, how do I write 64bits? I've looked over the PPC 405 Block Reference Guide and it seems that it should be possible to read/write 64 bits all at once just by virtue of having that wide of a bus coming in and out of the block. The cacheline transfers are discussed in that document as possibly being doublewords. I am a bit confused by all of this (if that wasn't clear already). I would probably be able to find my answer after a good deal of time/pain, but hopefully someone out there can clarify things a little for me. Just knowing if it was possible or not for a user program to do the 64bit write would help me move forward. I'd appreciate any clarification and/or pointers to relevant documentation. I can provide more info about my design or my confusion if it is useful. Answer: The fundamental limitation here is that the PowerPC-405 is a 32-bit core. So there are no instructions to load/store 64 bits of data at a time as an atomic unit. So from the processor core's perspective, you have to do two

32-bit stores. (The XIo_In and XIo_Out functions are basically just a wrapper around load/store instructions, but with an added "eieio" to make sure the operations don't get re-ordered by the hardware.) As you say, the PLB is in fact capable of doing multi-word transfers, and is wide enough to do 64-bit transfers in a single data beat. However, aside from enabling this functionality in the first place, the prWocessor has no control over whether this actually occurs. Without having done any experiments, my gut feeling is that using two calls to XIo_Out() back to back will not result in a 64-bit transfer, because of these "eieio"s. Your best bet is probably to try something like: typedef unsigned long long bits64; volatile bits64 *my_reg = (volatile bits64 *)(REG_ADDRESS); *my_reg = some_value; ...and then watch the bus and see what happens. Hope that helps, or least makes sense... :)

typedef unsigned long long My_Xuint64 ; I tried with this, but the result is the same. volatile My_Xuint64 *my_reg = (volatile My_Xuint64 *) (XPAR_P2O_0_BASEADDR); *my_reg = 0x0000000100000002;

I get a warning which says that the value is too big for a "long" type, but I defined it like a long long. I do not. I am also confused like the other guy.

Reply to
ferorcue
Loading thread data ...

As the answer you provided in your post says, you can't generate a 64 bit access from the 32 bit powerpc core.

The data cache or the instruction cache can but you can't.

You could write to the data cache and then flush it, but this is probably not what you want, nor is it recommended.

You probably need to control your dma controller using multiple 32 bit accesses. And if that is not allowed, you need to re-design your dma controller.

Alan Nishioka

Reply to
Alan Nishioka

64 bits would be addresses 0x2000 through 0x2007.
Reply to
Eric Smith

Alan is right: 64 bit transactions are out of the question. Remodify your DMA to integrate 32/64 MUX. Your idea might work in MPMC2 architecture on 64bit NPI port.

Guru

Reply to
Guru

Yep. Even the "lmw" and "stmw" instructions use seperate 32-bit accesses.

Kolja Sulimma

Reply to
comp.arch.fpga

Thank you very much for your answer, you are totally right. This is what xilinx told me yesterday:

The Embedded PPC405 is a 32bit processor architecture with 32bit register set and as such does not support 64-bit Write or Read transactions in a single cycle. Any 64-bit data read or write will be performed as two 32-bit PLB transfers.

As you already know, cache transfer is 2 words (64-bit) betwen the Cache Unit and the Processor Fetch Unit. However, this is a hardware operation internal within PPC and not under control of the user except to enable/disable the cache. Additionally, a true 64bit read or write on PLB could be realised between a 64 bit Master and Slave Peripherals. Once PPC is involved, the data will always been managed as seperate 32-bit transactions.

Reply to
ferorcue

Not entirely true. There are assembler instructions to allocate, fetch, and flush cache lines. This will generate bursts of 64-bit accesses.

Kolja Sulimma

Reply to
comp.arch.fpga

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.