I am designing an application similar to PCIe to SPI bridge. I used PCIe HIP and SPI ( 3 wire) peripheral. My design used only bar0 and bar4, and I connect bar4 avmm to spi core avms, PCIe bar4 avmm running at 250Mhz and the same clock to spicore avms. But it was not able to read from host computer via pcie, then I tried to put cross clocking bridge to reduce spicore avms to 125Mhz. It was not successul to control spi core regmap.
In design I also included PIO to control 2 LEDs via PCIe, it was fine, but still not able to control spi core regmap. I have double check spi core regmap base address.
Do you have any hint? What is max clk I can provide to spi core?
There is no specify the MAX clock, but you probably can try to simplify the design by connecting with JTAG MASTER (using system console) or NIOS processor instead of PCIe to debug it. It allows you to easily run with different clock rates. After the simple one is working, then you can change it back to use PCIe and then understand the difference. You might also need to capture signaltap to confirm if all the registers are written correctly.
It worked with nios, but now we would like to hook SPI core to PCIe memory map for direct command from host pc.
I figured out that the problem was with avmm addressing. I am trying to understand, since SPI core using 16 bits bus width, but AVMM from PCIe using 32 bits bus width ( or could be 256 bits bus width).
This caused the issue, I am trying to fix it.
Thanks for your answer!
I'm facing similar issues. I have an SPI core (3wire) connected to bar0 of a PCIe hard core in an Stratix IV FPGA. It looks as if data is hold back somewhere before being written through the avalon bus to the SPI controller. For example if I write a sequence of values to the CS register and read it back I always read the previous value ... then reading again I get the value written. I tried other components like memory blocks and one of our custom blocks on bar0 of the PCI bus and they work fine.
I noticed like you that the data bus of the core is 16 bit wide. Addressing it is only possible using the 32 bit addressing scheme meaning every register is on multiples of 4bytes (instead of 2 bytes) It looks - as you suggested - to be an integration issue of platform designers avalon component generation with this core.
Could you share your solution with us ?