Rocket IO as a high speed sampler

Hi everyone, (especially those Xilinx chaps) :-)

I've been having an interesting debate with a colleague here, regarding 
Virtex 4 Rocket IO (and Virtex II for that matter).  The challenge is to 
make a really high speed signal sampler in the fabric of one of these FPGAs 
by using the Rocket IO in a custom manner. I'm talking some GS/s

We figure using a local clock of 100M, should be mutiplied by 20 inside the 
rocket IO, giving 20 bits per 100M period that can be shuffled to get some 
indication of the input waveform. i.e. a 2G sampler.

Ok, ignoring the hugely important fact that FPGA has to be able to process 
this, and that the PCB has to be well designed, and that the input signal 
might have some new frequency and electrical constraints, are there any 
pitfalls we've missed?  btw: the idea comes from an expansion Figure-7 of:
http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF

Are there any potential flaws in these ideas anyone can see?

Thanks in advance,
Ben 

"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> 
schrieb im Newsbeitrag news:eaampt$pvr$1@sunnews.cern.ch...
> Hi everyone, (especially those Xilinx chaps) :-)
>
> I've been having an interesting debate with a colleague here, regarding 
> Virtex 4 Rocket IO (and Virtex II for that matter).  The challenge is to 
> make a really high speed signal sampler in the fabric of one of these 
> FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s
>
> We figure using a local clock of 100M, should be mutiplied by 20 inside 
> the rocket IO, giving 20 bits per 100M period that can be shuffled to get 
> some indication of the input waveform. i.e. a 2G sampler.
>
> Ok, ignoring the hugely important fact that FPGA has to be able to process 
> this, and that the PCB has to be well designed, and that the input signal 
> might have some new frequency and electrical constraints, are there any 
> pitfalls we've missed?  btw: the idea comes from an expansion Figure-7 of:
> http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF
>
> Are there any potential flaws in these ideas anyone can see?
>
> Thanks in advance,
> Ben
Hi Ben,

I think its almost 2 years now from when I posted some screenshots about the 
use or MGTs as 3GB/s sampler.
The demo displayed the USB HS test pattern captured with MGT

its nothing new.

Antti

Ben,

The problem with using the MGT receiver as a sampler, is that it wants
to "recover" the embedded clock signal in the data.

If you can gain access to the input sliced data, after it has been
clocked into the serial to parallel converter, the only question is:
"what was the clock to the serial to parallel shift register?"

Look at page 34 of
http://direct.xilinx.com/bvdocs/userguides/ug076.pdf

The receiver depends on recovery of an input clock to then
shift/transfer/unscramble/decode the received data.

The paths are all there to bypass the 8B10B, etc. but how to you solve
the chicken and egg problem of no clock -- no data?

Page 68 discusses the receiver clock options, and if the receiver can't
or won't lock to the sampled data based on the clock reference, then I
think the serial recovered clock is just a multiple of the refclk as you
describe.  But the receiver "knows" it has no lock, and how does this
affect the rest of the operation?

Austin


Benjamin Todd wrote:
> Hi everyone, (especially those Xilinx chaps) :-)
> 
> I've been having an interesting debate with a colleague here, regarding 
> Virtex 4 Rocket IO (and Virtex II for that matter).  The challenge is to 
> make a really high speed signal sampler in the fabric of one of these FPGAs 
> by using the Rocket IO in a custom manner. I'm talking some GS/s
> 
> We figure using a local clock of 100M, should be mutiplied by 20 inside the 
> rocket IO, giving 20 bits per 100M period that can be shuffled to get some 
> indication of the input waveform. i.e. a 2G sampler.
> 
> Ok, ignoring the hugely important fact that FPGA has to be able to process 
> this, and that the PCB has to be well designed, and that the input signal 
> might have some new frequency and electrical constraints, are there any 
> pitfalls we've missed?  btw: the idea comes from an expansion Figure-7 of:
> http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF
> 
> Are there any potential flaws in these ideas anyone can see?
> 
> Thanks in advance,
> Ben 
> 
> 

Antti,

Does not locking to the data affect its operation?  What if it tries to
lock to the data?  What if it can't lock to the data?

Austin

Antti Lukats wrote:
> "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> 
> schrieb im Newsbeitrag news:eaampt$pvr$1@sunnews.cern.ch...
>> Hi everyone, (especially those Xilinx chaps) :-)
>>
>> I've been having an interesting debate with a colleague here, regarding 
>> Virtex 4 Rocket IO (and Virtex II for that matter).  The challenge is to 
>> make a really high speed signal sampler in the fabric of one of these 
>> FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s
>>
>> We figure using a local clock of 100M, should be mutiplied by 20 inside 
>> the rocket IO, giving 20 bits per 100M period that can be shuffled to get 
>> some indication of the input waveform. i.e. a 2G sampler.
>>
>> Ok, ignoring the hugely important fact that FPGA has to be able to process 
>> this, and that the PCB has to be well designed, and that the input signal 
>> might have some new frequency and electrical constraints, are there any 
>> pitfalls we've missed?  btw: the idea comes from an expansion Figure-7 of:
>> http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF
>>
>> Are there any potential flaws in these ideas anyone can see?
>>
>> Thanks in advance,
>> Ben
> Hi Ben,
> 
> I think its almost 2 years now from when I posted some screenshots about the 
> use or MGTs as 3GB/s sampler.
> The demo displayed the USB HS test pattern captured with MGT
> 
> its nothing new.
> 
> Antti
> 
> 
> 

If you can live with "just" 2GSPS, that can be done in a virtex2 or
above with a little known, regular IOB function called the
ibufds_diff_out. With it, a single differential pair input can feed two
DDR input registers (one of them gets an inverted signal).  If you use
two 500 MHz clocks in quadrature (generated by the DCM), you get up to
2 GSPS sampling.  If you're in a v4 or above, the iserdes blocks can
demultiplex that down to a reasonable rate before it even hits the
fabric.

In a v5, you could get up to 2.2 GSPS.

That way you can use FPGAs that don't have rocket-io (and are thus
cheaper).

Andy


Antti Lukats wrote:
> "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch>
> schrieb im Newsbeitrag news:eaampt$pvr$1@sunnews.cern.ch...
> > Hi everyone, (especially those Xilinx chaps) :-)
> >
> > I've been having an interesting debate with a colleague here, regarding
> > Virtex 4 Rocket IO (and Virtex II for that matter).  The challenge is to
> > make a really high speed signal sampler in the fabric of one of these
> > FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s
> >
> > We figure using a local clock of 100M, should be mutiplied by 20 inside
> > the rocket IO, giving 20 bits per 100M period that can be shuffled to get
> > some indication of the input waveform. i.e. a 2G sampler.
> >
> > Ok, ignoring the hugely important fact that FPGA has to be able to process
> > this, and that the PCB has to be well designed, and that the input signal
> > might have some new frequency and electrical constraints, are there any
> > pitfalls we've missed?  btw: the idea comes from an expansion Figure-7 of:
> > http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF
> >
> > Are there any potential flaws in these ideas anyone can see?
> >
> > Thanks in advance,
> > Ben
> Hi Ben,
>
> I think its almost 2 years now from when I posted some screenshots about the
> use or MGTs as 3GB/s sampler.
> The demo displayed the USB HS test pattern captured with MGT
> 
> its nothing new.
> 
> Antti

"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
news:eaaru5$gks2@xco-news.xilinx.com...
> Antti,
>
> Does not locking to the data affect its operation?  What if it tries to
> lock to the data?  What if it can't lock to the data?
>
> Austin

Hi Austin,

the MGTs can actually be used as simple 20 bit serial to parallel shift 
register :)

I did no tricks, and I did not see any misbehavior related to CDR locking 
attempts

so the all thing was mgt in bypass mode connected to 20 chipscope ILA
controlled by custom application that collected the data and dsiplayed it in 
correctly

the rocketio input was just parallel attach to USB HS link as passive 
monitor

the MGT sampling clock was not any direct multiply of the USB data rate

as of my results I can say that an USB HS receive only PHY can be made with 
rokectio
that would make a real nice usb analyzer with 3GS/s time granularity. sure 
the phy would
be somewhat tricky to make, but possible.

Antti 

"Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
news:eaar1q$gks1@xco-news.xilinx.com...
> Ben,
>
> The problem with using the MGT receiver as a sampler, is that it wants
> to "recover" the embedded clock signal in the data.
>
> If you can gain access to the input sliced data, after it has been
> clocked into the serial to parallel converter, the only question is:
> "what was the clock to the serial to parallel shift register?"
>
> Look at page 34 of
> http://direct.xilinx.com/bvdocs/userguides/ug076.pdf
>
> The receiver depends on recovery of an input clock to then
> shift/transfer/unscramble/decode the received data.
>
> The paths are all there to bypass the 8B10B, etc. but how to you solve
> the chicken and egg problem of no clock -- no data?

hm,

look here..

http://www.xilant.com/downloads/csp.pdf

page 9 :)

rocketIO useage as high speed sampler (USB HS 480MBit/s data rate input)

Antti 

Antti,

I am impressed it was that simple.  I would have thought that the CDR
trying to lock would add too much jitter, but then, who cares?  You are
just sampling, and sampling is always +/- one bit anyway.

Austin

Antti Lukats wrote:
> "Austin Lesea" <austin@xilinx.com> schrieb im Newsbeitrag 
> news:eaar1q$gks1@xco-news.xilinx.com...
>> Ben,
>>
>> The problem with using the MGT receiver as a sampler, is that it wants
>> to "recover" the embedded clock signal in the data.
>>
>> If you can gain access to the input sliced data, after it has been
>> clocked into the serial to parallel converter, the only question is:
>> "what was the clock to the serial to parallel shift register?"
>>
>> Look at page 34 of
>> http://direct.xilinx.com/bvdocs/userguides/ug076.pdf
>>
>> The receiver depends on recovery of an input clock to then
>> shift/transfer/unscramble/decode the received data.
>>
>> The paths are all there to bypass the 8B10B, etc. but how to you solve
>> the chicken and egg problem of no clock -- no data?
> 
> hm,
> 
> look here..
> 
> http://www.xilant.com/downloads/csp.pdf
> 
> page 9 :)
> 
> rocketIO useage as high speed sampler (USB HS 480MBit/s data rate input)
> 
> Antti 
> 
> 

Do you want a 2GS/s sampler of 2GB/s data or do you just want high 
resolution of a lower speed signal?  I'm getting a minimum of 9 GS/s in a 
Spartan3E for a 600 MB/s signal (the sample rate isn't set as much as 
detected).  Depending on requirements, there are alternatives to RocketIO. 
See also XAPP671

  http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf


"Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> 
wrote in message news:eaampt$pvr$1@sunnews.cern.ch...
> Hi everyone, (especially those Xilinx chaps) :-)
>
> I've been having an interesting debate with a colleague here, regarding 
> Virtex 4 Rocket IO (and Virtex II for that matter).  The challenge is to 
> make a really high speed signal sampler in the fabric of one of these 
> FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s
>
> We figure using a local clock of 100M, should be mutiplied by 20 inside 
> the rocket IO, giving 20 bits per 100M period that can be shuffled to get 
> some indication of the input waveform. i.e. a 2G sampler.
>
> Ok, ignoring the hugely important fact that FPGA has to be able to process 
> this, and that the PCB has to be well designed, and that the input signal 
> might have some new frequency and electrical constraints, are there any 
> pitfalls we've missed?  btw: the idea comes from an expansion Figure-7 of:
> http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF
>
> Are there any potential flaws in these ideas anyone can see?
>
> Thanks in advance,
> Ben
> 

Ah, these are excellent points - Thanks everyone =)

The original purpose was to measure the length of a pulse to some hundreds 
of picoseconds.  2GS was chosen as a starting point, but ultimately faster 
is better... So, perhaps naively I was hoping that the actual phase of 
sample versus source clock was unimportant, but now that you mention it I 
have to have a rethink....

Interesting.

Cheers guys.
Ben






"John_H" <johnhandwork@mail.com> wrote in message 
news:_39yg.6528$Oh1.4695@news01.roc.ny...
> Do you want a 2GS/s sampler of 2GB/s data or do you just want high 
> resolution of a lower speed signal?  I'm getting a minimum of 9 GS/s in a 
> Spartan3E for a 600 MB/s signal (the sample rate isn't set as much as 
> detected).  Depending on requirements, there are alternatives to RocketIO. 
> See also XAPP671
>
>  http://www.xilinx.com/bvdocs/appnotes/xapp671.pdf
>
>
> "Benjamin Todd" <benjamin.toddREMOVEALLCAPITALS@cernREMOVEALLCAPITALS.ch> 
> wrote in message news:eaampt$pvr$1@sunnews.cern.ch...
>> Hi everyone, (especially those Xilinx chaps) :-)
>>
>> I've been having an interesting debate with a colleague here, regarding 
>> Virtex 4 Rocket IO (and Virtex II for that matter).  The challenge is to 
>> make a really high speed signal sampler in the fabric of one of these 
>> FPGAs by using the Rocket IO in a custom manner. I'm talking some GS/s
>>
>> We figure using a local clock of 100M, should be mutiplied by 20 inside 
>> the rocket IO, giving 20 bits per 100M period that can be shuffled to get 
>> some indication of the input waveform. i.e. a 2G sampler.
>>
>> Ok, ignoring the hugely important fact that FPGA has to be able to 
>> process this, and that the PCB has to be well designed, and that the 
>> input signal might have some new frequency and electrical constraints, 
>> are there any pitfalls we've missed?  btw: the idea comes from an 
>> expansion Figure-7 of:
>> http://www.eetkorea.com/ARTICLES/2004JUN/2004JUN22_PLD_RFD_AN05.PDF
>>
>> Are there any potential flaws in these ideas anyone can see?
>>
>> Thanks in advance,
>> Ben
>>
>
>