IP to OPB FIFO

I have an IP core than needs to eventually transfer data such that MicroBlaze (and maybe eventually PowerPC) has access to it. The data will be pushed out of the IP in bytes. It is possible that only 2 bytes are output for a given 'frame' of data. It is important that these 2 bytes get processed. More data may not come in until much later in time...relatively. Other cases will push more bytes per frame.

One option would be to place an asynchronous FIFO in the data path. The bytes would get stored in that FIFO using the IP's clock. The read port would be connected to an OPB IPIF FIFO. The OPB FIFO would store the data from the asynchronous FIFO using some yet to be determined logic. Then the OPB could request data through the IPIF interface.

We've thought about using the FSL but that option is not available (as far as I know) on the PowerPC. The problem with using the IPIF FIFO directly is that it is synchronous to the OPB clock. The IP is on a different clock.

Any suggestions as to a better way to do this?

Thanks!

Reply to
motty
Loading thread data ...

In V4FX (and presumably V5FX?) the PPC has an APU (Aux processing unit) interface, which can bridge across to something called FCB (fabric coprocessor bus) via the fcb_v1_00_a.

Thence you can bridge to FSL with the fcb2fsl_bridge core. I've seen a marketing slide showing this arrangement, but alas no XAPP that I can find.

These cores all live in the usual spot in an EDK installation ($EDK/hw/XilinxProcessorLib/pcores/...)

Quite an endorsement of FSL by Xilinx, if you think about it.

Regards,

John

Reply to
John Williams

Very interesting. Thanks John! We haven't done much research into the PowerPC. If only there were more hours in a day....

I have connected up the FSL to test some things. The only problem I see is that the FSL_Has_Data signal is not behaving as expected. I am routing that signal from the fsl core to my custom IP core so that I can output that as an interrupt. It basically just passes through the core and is assigned interrupt specific info in the mpd. This is connected to the intc IP from Xilinx. The signal goes high as expected and interrupts the MicroBlaze. I am just experimenting so the ISR just does 2 non-blocking reads (I've tried blocking and the same behavior occurs).

Basically, the FSL FIFO is 8-bits wide and I put 2 bytes into it via the custom IP. I am also using ChipScope to monitor all the signals of interest. It triggers right before data is written into the custom core. So I can see the Has_Data signal go high, but it takes around

60 OPB clock cycles for it to go low. It seems that this would happen much sooner. The signal should interrupt MicroBlaze in a few clock cycles and then the 2 reads are essentially 6 assembly instructions so I can't see where the 60 clocks come from. I don't think the latency of the interrupt is that long. But I have to do some more detailed experimentation to find out. I need that Has_Data signal to go low in time for more data to come in to eventually set Has_Data high again. With this latency, the signal never goes low in time.
Reply to
motty

Use the write control signal as an EDGE triggereed interrupt, in such a way the interrupt signal will last as long as you write data, but it will be alive until you acknowledge it.

Regards,

Zara

Reply to
Zara

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.