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!

Hi Motty,

motty wrote:

> 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.

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

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.

On 13 Feb 2007 20:30:40 -0800, "motty"
<m...@yahoo.com> wrote:

>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.
>

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