33+ Regs in PLB IPIF

Nov 20, 2007 4 Replies

I have created a custom peripheral in EDK 9.1/ISE 9.1 that needs to have



100 registers and communicates with the PowerPC CPU via the PLB bus. The board I'm using is the XUP Virtex-IIPro dev. board. I used the wizard in EDK to create a template for my peripheral, but the wizard only offers up to 32 registers. Therefore, I selected 32 registers and tried to change the USER_NUM_CE constant in the top-level module in the created template to 128, as opposed to 32. I have read the PLB IPIF datasheet from Xilinx, which only says that USER_NUM_CE needs to be a power of two, which is why I used 128 versus 100. After implementation, access to any register above
32 leads to a returned value of zero, when it should be non-zero. Any suggestions of what else I need to change in the generated IPIF code to get this working? I really would like to avoid rolling my own.


---Matthew Hicks


[snip]

The wizard generates 2 files, the top file and the user logic file. Make sure that the constants are set up correctly in both files.

Joe

Yeah, I made extra sure this was happening. Somehow, I've now got it to read and write up to 64 registers.

---Matthew Hicks

Changing the values of the generics will only set up the proper address decoding for your IP core, however it will not automatically instantiate the required amount of registers.

If you look at the user_logic.vhd file you will see slv_regX declarations for every register where X goes from 0 to N. You will have to modify this code to include the proper amount of registers as well if you want everything to work properly.

Does your IP core need constant access to the values that will be stored in the registers, or could you just throw the values in a BRAM?

-Jas> Yeah, I made extra sure this was happening. Somehow, I've now got it to

I gutted the generated user logic portion of code and added my registers, so I have enough. It was the enable signals that weren?t working for the higher numbered registers. In the end, I found that it was easier to work around this issue by doing the address decoding in my own logic. I also found it easier to directly connect my interrupt signal to the output as opposed to passing it to the IPIF block, which never allowed the signal to pass through, even though it was set-up to do so. If I had more time, I would write my own as I found Xilinx's code to be an utterly disappointing and dysfunctional rat's nest.

---Matthew Hicks

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required