PLB Master

You just overwrite your "Data" pointer. Unless XPAR_IPIF_MASTER_0_BASEADDR is 0, you won't be accessing your peripheral.

Didn't you mean

Data=(Xuint32*)(XPAR_IPIF_MASTER_0_BASEADDR+0x00);

...and so on?

-Ben-

No change,

There is something i don't really understand: if I want to send data from an IP to my SOPC (in a BRAM), I need to make a MASTER IPIF which transfer the data to the BRAM. In the MASTER (PLB) IPIF, it takes the data and the address from my IP TEST with the ports Bus2IP and sends it to the BRAM with the ports IP2Bus.

What is the aim of the IP2IP port ? When I want to send data to my BRAM, I send the address of the MASTER IPIF or of the BRAM ???

Thanks

No change,

when I want to store data from an IP to a BRAM, I send the data with an address to my Master PLB IPIF, but what is this address ? An address of the BRAM ???

The data and the address come from an IP TEST block. The IP TEST block is an IPIF ??

Tk very much

I'm not sure I understood any of that...

If you want to design a piece of IP that attaches to the rest of your system via a Coreconnect bus like PLB or OPB, then you have some options - it can be a bus slave, a bus master, or both. In fact, it might even have a master interface on one bus and a slave interface on another.

The IPIF is supposed to make it easier for you to interface your IP to the Coreconnect bus, but you do not have to use it if you don't want to.

If your IP is a bus master only, then it will be able to initiate its own transactions, but it will be inaccessible from the rest of the system. If it is a bus slave only, then it will be readable and writable from somewhere else (like your processor), but unable to initiate transactions. If it's both a master and a slave, then it has all these capabilities.

The piece of code you posted seemed to be targetting a piece of IP with both a master and a slave interface. My understanding of it was that the processor would write some command registers to this IP, telling it what data to write and where to write it. Then when the IP is told to "go", it will perform its transaction on the PLB. In that case, you need to know where the IP's slave interface is mapped in memory, so that the processor can talk to it. It looks like XPAR_IPIF_MASTER_0_BASEADDR should be that address, but perhaps it is not. Sometimes when using the IPIF you need to access the peripherals "address range 0" base address instead - check to see what definitions are present in your xparameters.h file.

Of course, a piece of IP like this is of no immediate practical use, because it would be just as easy for the processor to perform the transaction itself instead of going through this proxy. However, it's a useful exercise for getting to grips with the Coreconnect system and debugging your IP.

You might also find it useful to attach a chipscope analyser to the PLB signals and watch what happens when your software runs.

Good luck,

-Ben-

thank you for your fast answer and your kindness, what i "just" want to do is access to a BRAM plugged to the PLB with an "external" IP, that why i want to build a MASTER PLB IPIF. i beging to understand how that system works thanks to the Xilinx sample but i have a problem with the address.

I had to implement a PLB master the other year for a project. To be honest, it is actually easier if you just get the core connect spec and write it your self.

In my case, I was only doing 64-bit transfers. The logic was actually pretty simple. I spent a week with the IPIF and it never really worked right. I told a co-worker that I did not think they ever tested the IPIF master operation.

My own implementation only took a day or 2. Believe it or not the state machine to do is pretty small.

LilacSk> Hi,

Eli, Just curious, did you debug it with HDL simulation or chipscope?

Hum, you had to write a plb arbiter ? Can you share your HDL code ?

thanks a lot !

To build my PLB master, I only need that ports ???

PLB Master n Interface

PLB-to-Master N

PLB_MnWrDAck PLB_MnRdAck PLB_MnAddrAck PLB_MnRearbitrate PLB_MnTimeout

Master n-to-PLB

Mn_request Mn_priority(0:1) Mn_RNW Mn_size(0:3) Mn_rdBurst Mn_abort Mn_wrBurst Mn_ABus(0:31) Mn_UABus(0:31)

PLB Slave n Interfaces

PLB-to-slave n

PLB_RNW PLB_abort PLB_wrBurst PLB_rdBurst PLB_masterID(0:2) PLB_PAValid PLB_SAValid PLB_ABus(0:31) PLB_UABus(0:31)

Slave n-to-PLB PLB

Sln_wait Sln_AddrAck Sln_rearbitrate Sln_rdComp Sln_rdDAck Sln_wrComp Sln_wrDAck

Where are the ports in the IBM datasheet ?

PLB_pendpri PLB_penreq PLB_reqpri PLB_size PLB_type PLB_rdPrim PLB_abort PLB_buslocked PLB_masterID PLB_MSize PLB_compress PLB_guarded PLB_lockerrr PLB_MErr, PLB_MBusy.......

I had about the same experience with an OPB master peripheral - the IPIF implementation did not work properly so I build my own. The PLB SG/DMA IPIF implementation probably works, but you do not access it properly. Read SG/DMA datasheet for register definitions. At first you need a reliable read/writes to registers; I sugesst you use XIo_In32 and XIo_Out32 functions to manipulate with memory mapped peripherals to avoid any errors. You also consider disabling PPC cache to avoid reading cached data instead of RAM contents. If you consider building a PLB DMA peripheral you first need a slave pripheral (i prefer the simplest DCR bus) for register access. Then you add a PLB bus connection to incorporate your PLB DMA engine. If you want to succeed you better read througly the PLB specification:

Cheers,

Guru

more than 2 days..... more than 2 years perhaps

I am not permitted to share my code BUT here is what I did:

My master operation was driven by a couple of IPIF slave registers. I had the tool generate a generic IPIF slave interface (one with just a few registers).

I use Verilog ---> I then added these signals to the port declaration list in userlogic.v (don't forget to hook these up in main VHDL file!):

PLB_Clk, PLB_Rst, M_abort, M_ABus, M_BE, M_busLock, M_compress, M_guarded, M_lockErr, M_ordered, M_priority, M_request, M_RNW, M_size, M_type, M_wrBurst, M_wrDBus, PLB_MErr, PLB_MWrDAck, PLB_MAddrAck,

Note that Xilinx uses the same net names as in the PLB core connect spec

input PLB_Clk; input PLB_Rst; output M_abort; output [0:C_PLB_AWIDTH-1] M_ABus; output [0:C_PLB_DWIDTH/8-1] M_BE; output M_busLock; output M_compress; output M_guarded; output M_lockErr; output M_ordered; output [0:1] M_priority; output M_request; output M_RNW; output [0:3] M_size; output [0:2] M_type; output M_wrBurst; output [0:C_PLB_DWIDTH-1] M_wrDBus;

input PLB_MErr; input PLB_MWrDAck; input PLB_MAddrAck;

For my application, my PLB master always wrote to memory, Most of the PLB signals could be fixed. I was always doing PLB writes (64-bit) so:

assign M_priority = 2'b11; // Keep this transaction priority high assign M_busLock = 0; assign M_abort = 0; assign M_RNW = 0; assign M_BE = 8'b11111111; //We are send all 64-bits assign M_size = 4'b0; assign M_type = 3'b000; //memory transfer assign M_compress = 0; assign M_guarded = 0; assign M_ordered = 0;

I drove the Address and write data buses with my own logic.....

assign M_ABus = EffectiveTransferAddress; assign M_wrDBus[0:31] = TransferCount; assign M_wrDBus[32:63] = ~TransferCount;

Now, when you have a PLB bus in a EDK project, a PLB arbiter is added for you. This is something that is needed whether you use IPIF or not.

Now, the only thig you have to do is have a state machine to operate these PLB signals:

PLB_MErr M_request PLB_MAddrAck PLB_MWrDAck

These are used to talk to the arbiter and request access. These signals are for writing only! If you are doing reading you need some addition PLB signals.

Look in the spec to implement you state machine.

Hope this helps! It is also important that you make your first example very simple. My first implementation was logic that will fill up some RAM on the PLB bus with a number sequence. I could then look in RAM to make sure the master was working.....

This may seem like a really difficult piece of logic but its not as bad as you would think. Just read the PLB spec and you'll be fine.

Good Luck!

LilacSk> To build my PLB master, I only need that ports ???