Xilinx Aurora link splitter

Hi,

I'm a software guy and now that I have a hardware problem,
I hope to find some good advice here.

There are two devices A and B connected using Aurora link
(single lane, full duplex) over SFP + optical LC cables.
Data transfer is mostly A->B.

Now I want to tap into this link transparently, so that device
C gets a copy of (at least) everything that A sends.
C is fast enough to receive, so it doesn't need to do
flow control with A.

I read that Aurora cores are configured for individual use.
If there's no solution on a lower level, I have access to
the actual Aurora core source used in devices A and B.

Is there a device available which can split an Aurora link
resp. duplicate it to a mirror port? Is there some dev board
which can be made into what I need without too much work?
I only need one such device.


Kind regards,


Hendrik vdH

Hendrik van der Heijden wrote:
> Hi,
> 
> I'm a software guy and now that I have a hardware problem,
> I hope to find some good advice here.
> 
> There are two devices A and B connected using Aurora link
> (single lane, full duplex) over SFP + optical LC cables.
> Data transfer is mostly A->B.
> 
> Now I want to tap into this link transparently, so that device
> C gets a copy of (at least) everything that A sends.
> C is fast enough to receive, so it doesn't need to do
> flow control with A.
> 
> I read that Aurora cores are configured for individual use.
> If there's no solution on a lower level, I have access to
> the actual Aurora core source used in devices A and B.
> 
> Is there a device available which can split an Aurora link
> resp. duplicate it to a mirror port? Is there some dev board
> which can be made into what I need without too much work?
> I only need one such device.
> 
> 
> Kind regards,
> 
> 
> Hendrik vdH

I'm not sure I understand everything, but it sounds like you
could use any board that has 3 SFP ports and an FPGA capable
of supporting 3 Aurora ports.  That would be the case if
device C has an Aurora receiver.  If device C doesn't, or
if this is just a conceptual thing for debug, you could
get away with 2 SFP ports and whatever interface you need to
get the data out some other way, possibly even PCIe if the
interposing board plugs into a "debug" PC to listen in to
the link.

You say that C doesn't need flow control, but if B uses flow
control, you need to make sure that the latency added by
the interface doesn't create problems with that flow control,
or else you would need logic in the interface to handle the
flow control, possibly with some extra buffering.

You also didn't mention the bit rate.  If it's not too high
there might also be the possibility of redriving the signal
without having SERDES in between.  That would add very little
latency to the link.

An intermediate latency solution would be to use a SERDES-based
re-driver using a recovered clock.  Or you could use an FPGA
without Aurora cores to retransmit with fairly low latency if
you have access to the reference clock from boards A and B.

-- 
Gabor

Am 23.04.2015 um 14:42 schrieb GaborSzakacs:
>> I'm a software guy and now that I have a hardware problem,
>> I hope to find some good advice here.
>>
>> There are two devices A and B connected using Aurora link
>> (single lane, full duplex) over SFP + optical LC cables.
>> Data transfer is mostly A->B.
>>
>> Now I want to tap into this link transparently, so that device
>> C gets a copy of (at least) everything that A sends.
> 
> I'm not sure I understand everything, but it sounds like you
> could use any board that has 3 SFP ports and an FPGA capable
> of supporting 3 Aurora ports.

Right, can you recommend some specific suitable board?

> That would be the case if device C has an Aurora receiver.
> If device C doesn't, or if this is just a conceptual thing
> for debug, you could
> get away with 2 SFP ports and whatever interface you need to
> get the data out some other way, possibly even PCIe if the
> interposing board plugs into a "debug" PC to listen in to
> the link.

Currently, my device C is a PCIe card with a single SFP.
Its FPGA contains an Aurora core plus some logic to make received
data available to the PC.

Like you, I see two options:

1)
Assuming I can get the FPGA source code for my PCIe card and get
a version with two SFPs, how much effort would it be to have the
Aurora link pass-through between both SFPs bidirectionally?

Can I just connect Aurora port A's RX lanes to port B's TX lanes
and vice versa (in FPGA logic) or is there more to it?

SFP A RX -------> in  AuroraCoreA RX -->--+ --> Decoder to PC RAM
SFP A TX <------- out             TX <--  |
                                       |  |
SPF B RX -------> in  AuroraCoreB RX -->  |
SFP B TX <------- out             TX <----+


> If it's not too high there might also be the possibility of
> redriving the signal without having SERDES in between.
> That would add very little latency to the link.
> An intermediate latency solution would be to use a SERDES-based
> re-driver using a recovered clock.

I have too little knowledge here to tell whether these ideas would work.
Can I directly connect the two SFP's RX and TX? On the "raw" pins or
behind the SERDES ("MGT"?)?
Would the AuroraCore output received data or stay in link down
state because no one reacts to its output?

SFP A RX -----+--> in  AuroraCore RX --> Decoder to PC RAM
SFP A TX <-+  |    out            TX <-- (unused)
           |  |
           |  |
SPF B RX --+  |
SFP B TX <----+



2)
Get a 3xSFP FPGA board, put Aurora cores in there and hook them up:
  Port A RX -> Port B TX + Port C TX
  Port B TX <- Port B RX

I was hoping I could buy something like this directly, instead of
having to develop it myself (or paying someone to do so). If if can't
buy it directly, the first option seems to be the better one.

> You say that C doesn't need flow control, but if B uses flow
> control, you need to make sure that the latency added [..]

Latency shouldn't be an issue. A and B should work fine
with up to 1ms added latency.

> You also didn't mention the bit rate. 

The Aurora link is 2GBit/s, payload data rate is maybe half that.

> Or you could use an FPGA
> without Aurora cores to retransmit with fairly low latency if
> you have access to the reference clock from boards A and B.

I cannot interface boards A and B directly, only the Aurora link
in-between.

Thanks for your ideas so far,


Hendrik vdH