IP2IP_Addr in IPIF

Hi, group

I generated a IPIC interface by the Create and Import Peripheral Wizard

to access PLB_DDR blockon the PLB bus.

I chose the DMA, user logic Master Support mode. And then try to develop my own logic based on the generated files. Here, I have one problem:

To write to an address on PLB bus, I need to provide two addresses: IP2IP_Addr which stores the source data and IP2Bus_Addr to which writes the data. Do I need to instantiate a BRAM in the FPGA to provide the source address?

What I am not clear is whether the BRAM is compatible the IPIC logic. Or do I have to instantiate another PLB_Bram and then hook it up to the PLB? Are there any other simple method?

Thank you for the help. Roger

Reply to
agou
Loading thread data ...

Hello,

Please refer to this thread:

formatting link

(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:

Reply to
Nju Njoroge

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:

formatting link

Reply to
agou

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

formatting link

Reply to
Nju Njoroge

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

formatting link
it say that when you read you will get a Bus2IP_WrReq is this correct, because you want to read and not write. Is this correct?

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

Reply to
Mich

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:

Reply to
Nju Njoroge

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.