PLB Master
LilacSkin
I build a IPIF master with Create/Import Peripheral.
I try the example write in the user_logic.vhd:
-- Here's an example procedure in your software application to
initiate a 4-byte
-- write operation (single data beat) of this master model:
-- 1. write 0x40 to the control register
-- 2. write the source data address (local) to the ip2ip register
-- 3. write the destination address (remote) to the ip2bus
register
-- - note: this address will be put on the target bus address
line
-- 4. write 0x0004 to the length register
-- 5. write valid byte lane value to the be register
-- - note: this value must be aligned with ip2bus address
-- 6. write 0x0a to the go register, this will start the write
operation
My C:
#include "xparameters.h"
#include "xutil.h"
int main (void) {
volatile Xuint32* Data;
Data=(Xuint32*) XPAR_IPIF_MASTER_0_BASEADDR;
// contrôl register
Data=(Xuint32*)(0x00+0x00);
*(Data)=0x40;
// source address
Data=(Xuint32*)(0x00+0x04);
*(Data)=XPAR_TEST_0_BASEADDR;
//destination address
Data=(Xuint32*)(0x00+0x04);
*(Data)=XPAR_PLB_BRAM_IF_CNTLR_1_BASEADDR;
// lengh register
Data=(Xuint32*)(0x00+0x04);
*(Data)=0x04;
// BE register
Data=(Xuint32*)(0x00+0x02);
*(Data)=0xFF;
// Go register
Data=(Xuint32*)(0x00+0x01);
*(Data)=0x0A;
return 0;
}
I put one data in my TEST block, but nothing happened.
I want to transfer the data from the TEST block to a BRAM with this
IPIF, but i don't understand
what address i need to put in my TEST block to access to my BRAM.
Can you help me ????
Thanks
Ben Jones
"LilacSkin" <lpau...@iseb.fr> wrote in message
news:1176715616.9...@b75g2000hsg.googlegroups.com...
> Hi,
> I build a IPIF master with Create/Import Peripheral.
> I try the example write in the user_logic.vhd:
> volatile Xuint32* Data;
> Data=(Xuint32*) XPAR_IPIF_MASTER_0_BASEADDR;
>
> // contrôl register
> Data=(Xuint32*)(0x00+0x00);
> *(Data)=0x40;
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-
LilacSkin
> "LilacSkin" <lpaul...@iseb.fr> wrote in message
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
Ben Jones
> 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 ???
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-
LilacSkin
> "LilacSkin" <lpaul...@iseb.fr> wrote in message
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.
Eli Hughes
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.
Jeff Cunningham
> 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.
Eli,
Just curious, did you debug it with HDL simulation or chipscope?
LilacSkin
Hum, you had to write a plb arbiter ?
Can you share your HDL code ?
thanks a lot !
LilacSkin
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.......
Guru
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:
http://www-306.ibm.com/chips/techlib/techlib.nsf/techdocs/3BBB27E5BCC165BA87256A2B0064FFB4
To implement what you want and to remove all the bugs I think it is
more than a 2 days job.
Cheers,
Guru
LilacSkin
Eli Hughes
worked when it was implemented in a V2P20
Eli Hughes
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!
Jeff Cunningham
> HDL simulation only. Just simulated the pieces of the interface and it
> worked when it was implemented in a V2P20
I was interested what type of models for the other bus components you
used, which you explained in another post. I hadn't thought of using the
IPIF slave as a model.
I recently developed my own PLB master using the IBM supplied bus
functional models and MXE for VHDL sim. It worked pretty well and the
models are quite powerful, issue "intelligent" warnings and such, but it
ran quite slow.
-Jeff