1. Home
  2. Field-Programmable Gate Arrays
  3. PLB master with burst mode

PLB master with burst mode

Hi,

I build a PLB Master in single byte transfer mode and it works well. Now, I try to use the burst mode and I don't understand something.

For a burst transaction, at each rising edge of the clk, a new data and a new address is presented to a peripheral.

I use the plb ipic and what I don't understand is in the state machine :

Normaly, at each rising edge of the clk, the state machine had to increase my ip2ip and ip2bus address to make a burst transaction.

But in fact, in the Last_Burst state, the state machine wait the Bus2IP_MstLastAck=1 to increase it. The problem is that the Bus2IP_MstLastAck is not still active. Why ?

If is not still active, how can I build a burst transaction ????

Thanks !

Reply to
LilacSkin
Loading thread data ...

Not true. The first address is presented in the initial "address" phase of the transaction. The slave is responsible for calculating all subsequent addresses after that.

I guess you mean the IPIF... I don't know anything about that so I can't help you there. But it's often just as easy (if not easier) just to drive the PLB signals yourself, directly. There have been quite a few threads on this subject here recently.

Cheers,

-Ben-

Reply to
Ben Jones

Sorry I don't have time to drive directly the PLB signals. I just want to build a burst transaction.

You say that "The slave is responsible for calculating all subsequent addresses after that." I agree with you, but I need to present a data to the slave component. So I had to count my ip2ip adress in order to present the data from my slaves registers of my slave/master component to the slave component.

Are you agree ?

Reply to
LilacSkin

What I'm saying is, you might find it quicker and easier to drive the PLB signals directly. It's not very complicated. There are just a handful of signals that are involved in a burst transaction, plus a few more "static" ones that tell the data width and transaction type.

Sad to say, but the PLB protocol is (in my experience) better documented than the IPIF, mostly because the CoreConnect standard is widely used whereas the IPIF wrapper layer is Xilinx proprietary.

That depends entirely on what you're doing. If you have a random-access buffer in your component and you want to read out its contents in linear order and write them to the slave device, then yes, you would have to count the burst cycles yourself. But if your data are coming from a FIFO (which counts internally for itself), then in that case you would not need your own counter.

I'm afraid I don't think I'm getting very close to answering your original question, though, for which I apologize... questions...

(1) Are you debugging this in hardware or in simulation? (2) What is the slave device you are accessing?

-Ben-

Reply to
Ben Jones

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.