IP2IP_Addr in IPIF

Hello,

Please refer to this thread:

(Google "PLB Master" in Googe Groups and this will be your first hit).

Properly using the IP2IP_Addr in the IPIF is what allowed my master to work properly.

Good luck,

NN

agou wrote:

Hi, Nju

Thank you for the reply. I don't know whether your code in last thread derived from the user_logic.v generated by the Create and Import Peripheral Wizard. And I am currently reading this code.

In this code, there is a port named IP2IP_Addr, and in your last thread, you first connected with the IP2Bus_Addr and then you revised it to your local target memory. What I am not clear is that how to instantiate the "local target memory" which is compatible to the IPIF? Should I instantiate a PLB_BRAM block?

Besides the above, in the user_logic.v, there is a 16 bytes flattened registers(mst_reg(0:15) in the sample code) which are used for the control from the software side. Meanwhile, in the sample code, each of this address is assigned a specific address, e.g. IP2IP register is located at C_BASEADDR+0x104. And I saw another reference design in which software could read these register directly by the address. So I just wonder whether I could allocate some other registers in my hardware and specify the address myself. If it could be done, then for writing, I could just store my data in these registers first and then assign these registers' addresses to the IP2IP_Addr. But I don't find anything on how to specify the registers' addresses in the sample code.

So now, could you tell me how did you do to use a "local target memory"? And do you know whether the second method would work or not?

Thank you Roger

Nju Njoroge wrote:

Hi Roger,

The docs do not explain too well what they mean by "local target memory". If you notice, the Master PLB IPIF comes with a slave attachment. Thus, the master IPIF is not a pure master. Contrast this with the PPC Master interfaces (Instr-PLB and Data-PLB) which are pure masters. Because of the slave attachment, the master-slave IPIF has an address range like any PLB slave: you set this address range in the MHS file instantiation. The key insight (which the docs do not explain) is that the IP2IPBus_Addr should always be set to some address within the addressable range of the slave attachment. Thus, if your user_logic has internal memory, the idea is that you use the IP2IPBus_Addr address range for this "local target memory". If your master pcore does not need to have any internal memory, you can hard code IP2IPBus_Addr to a static address within the slave attachment address range. This was the case for me (I was designing a PLB to PLB bridge, so my data came from one side of the bridge and I pushed it out to the other side).

Another th> Hi, Nju

Hi

I 'm also trying to use a master ip on the PLB bus and I also use the IPIF interface from the "Create Peripheral" wizard in EDK's XPS. Like you I have some troubels with writhing and reading (I want to write and read to/from a BRAM on the PLB-Bus) You say that the slave attachment is also used for the master trasaction. When I look at the timing diagram on pg 116 of the plb_ipif.pdf

I have made a small FSM to test a single read and write (at the bottom of the message is my VHDL-code)

I have a state (PrepareWr_State and PrepareRd_State) to make sure all the addresses are correct I have a state (ReqWr_State and ReqRd_State) for the request =>

IP2Bus_MstWrReq and IP2Bus_MstRdReq I have a state (AckWr_State and AckRd_State) for the ack that the IPIF can read/write from/to my ip => IP2Bus_WrAck and IP2Bus_RdAck I have a state (OkWr_State and OkRd_State) so I know everything went well

But there must be something wrong because it doesn't work, when I want to write something, my FSM stays in the ReqWr_State, and when I want to read something it also doesn't do what it should do (or atleast what I think it should do)

Can you help me please?

Mich

-- TRANSITION_STATE_LOGIC

STATE_TRANSITION_LOGIC: process (ACTUAL_STATE, pushR, pushL, pushU, pushD, Bus2IP_MstLastAck, Bus2IP_WrReq, Bus2IP_RdReq) variable counter_Rd : integer range 0 to 15; variable counter_Wr : integer range 0 to 15; begin

case ACTUAL_STATE is when idle =>

if (pushR = '0') then -- pushR is active low NEXT_STATE

Hello Mich,

The master IPIF has a slave IPIF attachment, which interacts with master IPIF accesses. It is important to understand how it operates because the master won't function. For instance, for a:

Master Read -- Assert IP2Bus_MstReq. You'll see that the read data returns through the slave attachment, appearing like a write-request to your "local target memory" (some register or BRAM inside your pcore) with Bus2IP_WrReq going high and Bus2IP_WrCE[x] as well (if you chose to use CEs). For proper functionality, you have to acknowledge this slave-attachment write with a IP2Bus_WrAck. Then, you will receive Bus2IP_MstRdAck some cycles later to confirm that your master read has been completed by the master IPIF. At this point, you can de-assert IP2Bus_MstRdReq.

Master Write -- Raise IP2Bus_MstWrReq. The slave attachment will respond saying that it is ready to "read" your write data by asserting Bus2IP_RdReq (and Bus2IP_RdCE[x] if you have enabled CE's in IPIF). Once you have your write data ready, you issue IP2Bus_RdAck, which tells the slave attachment to read the data and push it to the master IPIF. Once the master IPIF is done writing the data, you'll receive Bus2IP_MstWrAck, at which point you can de-assert IP2Bus_MstWrReq.

Pretty confusing if you ask me...but that's what is provided....

Good luck!

NN Mich wrote: