1. Home
  2. Field-Programmable Gate Arrays
  3. 33+ Regs in PLB IPIF

33+ Regs in PLB IPIF

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

Reply to
Matthew Hicks
Loading thread data ...

[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
Reply to
Joseph Samson

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

---Matthew Hicks

Reply to
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

Reply to
Jason Agron

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

Reply to
Matthew Hicks

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.