cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
flitch@mbda
Contributor
Contributor
3,798 Views
Registered: ‎06-22-2009

PLB address out of range

Jump to solution

Hi,

 

I have an interesting problem that I would like some help tracking down.

 

My user IP that has 19 registers. This uses a PLB slave register type interface created by the wizard.

 

Remember that the minimum address space for user IP is 64K when instantiated in EDK (according to my course notes anyway!)

 

The IP is build inside a V5 FX130T.

 

SW testing is being done via XMD commands.

 

Now the IP works perfectly when you use the 19 register addresses.

 

However, when you use the next address (i.e. where the 20th register would be, if it existed, but still inside the 64K address space) the SW locks up and can only be restarted by a power cycle.

 

Is this behaviour expected?

 

I cannot see how you could prevent it, as the wizard only creates the correct number of CE, WRACK, RDACK for the registers in the IP.

 

This behaviour does not seem to occur for Xilinx generated IP such as UART or I2C.

 

Any help appreciated.

 

Thanks and best wishes

Peter

0 Kudos
1 Solution

Accepted Solutions
bassman59
Historian
Historian
4,638 Views
Registered: ‎02-25-2008

Hi -- First, regarding minimum address space for user IP being 64k -- dunno where you got that from, but that's not true. I have spaces that are much smaller.

 

As for the lockup accessing the 20th register location. In that case, assuming you do things the way Xilinx wants you to do them, you will never see a register chip-enable asserted so your IP core will never return an acknowledge.

 

I don't know whether you have PLB time-outs enabled, or even if such a thing is possible, but it's apparent that the bus is waiting for an acknowledge it will never get. (Try using ChipScope to see what's going on. It should be obvious.)

 

You might wish to consider the following: rather than depend on Xilinx' slave PLB interface to do address decoding, do it yourself. Rather than determining in advance that you need 19 registers (what happens when you need to add a 20th?), simply make your IP core look like one memory space of appropriate size. Do NOT use their register scheme at all. Now all your core needs to do is monitor Bus2IP_CS(0) to determine if your core's space was addressed. If it is, simple gate it with the appropriate polarity of Bus2IP_RNW to return the acknowledges. Basically, you acknowledge when the entire SPACE is addressed; addressing unused memory locations within that space are ignored by the core but acknowledged so the bus doesn't hang.

 

The other clever thing about this scheme is that you can put all of your various interesting stuff in this one IP core so your design doesn't have multiple copies of the slave PLB interface. For example, I have a design done this way, and it has an 8k-byte address space -- large enough to hold two BRAMs for two PicoBlaze instruction memories, a batch of registers and a handful of SPI masters (which I wrote myself, not the Xilinx crud).The core looks for Bus2IP_CS(0). Address bit 19 (the most-significant bit in the space) is used as a memory/register select; if bit 19 is high then we are accessing the registers and the SPI ports, and if low we are accessing one of the two BRAMs. For register access bits (20 to 29) are decoded.

 

Try it -- you'll like it.

 

NB that I don't use the crazy Xilinx "drivers" scheme. My "drivers" are simply peeks and pokes to the registers as needed.

----------------------------Yes, I do this for a living.

View solution in original post

0 Kudos
3 Replies
bassman59
Historian
Historian
4,639 Views
Registered: ‎02-25-2008

Hi -- First, regarding minimum address space for user IP being 64k -- dunno where you got that from, but that's not true. I have spaces that are much smaller.

 

As for the lockup accessing the 20th register location. In that case, assuming you do things the way Xilinx wants you to do them, you will never see a register chip-enable asserted so your IP core will never return an acknowledge.

 

I don't know whether you have PLB time-outs enabled, or even if such a thing is possible, but it's apparent that the bus is waiting for an acknowledge it will never get. (Try using ChipScope to see what's going on. It should be obvious.)

 

You might wish to consider the following: rather than depend on Xilinx' slave PLB interface to do address decoding, do it yourself. Rather than determining in advance that you need 19 registers (what happens when you need to add a 20th?), simply make your IP core look like one memory space of appropriate size. Do NOT use their register scheme at all. Now all your core needs to do is monitor Bus2IP_CS(0) to determine if your core's space was addressed. If it is, simple gate it with the appropriate polarity of Bus2IP_RNW to return the acknowledges. Basically, you acknowledge when the entire SPACE is addressed; addressing unused memory locations within that space are ignored by the core but acknowledged so the bus doesn't hang.

 

The other clever thing about this scheme is that you can put all of your various interesting stuff in this one IP core so your design doesn't have multiple copies of the slave PLB interface. For example, I have a design done this way, and it has an 8k-byte address space -- large enough to hold two BRAMs for two PicoBlaze instruction memories, a batch of registers and a handful of SPI masters (which I wrote myself, not the Xilinx crud).The core looks for Bus2IP_CS(0). Address bit 19 (the most-significant bit in the space) is used as a memory/register select; if bit 19 is high then we are accessing the registers and the SPI ports, and if low we are accessing one of the two BRAMs. For register access bits (20 to 29) are decoded.

 

Try it -- you'll like it.

 

NB that I don't use the crazy Xilinx "drivers" scheme. My "drivers" are simply peeks and pokes to the registers as needed.

----------------------------Yes, I do this for a living.

View solution in original post

0 Kudos
flitch@mbda
Contributor
Contributor
3,769 Views
Registered: ‎06-22-2009

Hi Bassman59,

 

Thanks for the answer, spot on as always.

 

I think that you have suggested your scheme before. It's probably a bit too radical for me at the moment. I am working in a multi-person project with lots of people contributing IP so would be a bit difficult to implement.

 

However, based on your answer we are now planning a phase to do some of this and consolidate common IP into a smaller number of PLB slaves. This will save the approx 300 slices for each PLB slave, plus who knows how much for all the other stuff (additional PLB busses and PLB-PLB bridges).

 

I have already generated a PLB slave using the memory interface rather than the register interface, so know how to do this.

 

With reference to the original question. I have another PLB slave that has only 1 register. This does not exhibit the fault condition, but returns the expected value for all addresses in the range. I therefore suspect that the "problem" is with the address decoding in the Xilinx generated IP. I would guess that it happens when the number of registers does not correspond with an exact (power of 2) binary representation.

 

Many thanks.

 

Best wishes

Peter

 

 

Message Edited by flitch@mbda on 10-02-2009 06:12 AM
0 Kudos
bassman59
Historian
Historian
3,765 Views
Registered: ‎02-25-2008

flitch@mbda wrote:

 

With reference to the original question. I have another PLB slave that has only 1 register. This does not exhibit the fault condition, but returns the expected value for all addresses in the range. I therefore suspect that the "problem" is with the address decoding in the Xilinx generated IP. I would guess that it happens when the number of registers does not correspond with an exact (power of 2) binary representation.


The power-of-two thing, if true, wouldn't surprise me at all. I can't say I ever attempted to access undefined registers (like address 20 when 19 are defined) because I wrote my "driver" using functions that accessed only registers that existed.
----------------------------Yes, I do this for a living.
0 Kudos