FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 04-25-2006, 06:41 AM
king
Guest
 
Posts: n/a
Default How to avoid lossing channel bonding when using Rocket IO?


Hi

I'm using RocketIO with 4 channels, but they would loss banding when
the data flow
becomes fast.
What would result in lossing channel banding?
And how to avoid this problem?

Many thanks!

king

Reply With Quote
  #2 (permalink)  
Old 04-25-2006, 09:59 AM
Symon
Guest
 
Posts: n/a
Default Re: How to avoid lossing channel bonding when using Rocket IO?

Your Majesty,
Google this:-
"channel bonding" site:xilinx.com

Answer 15050? Some of the many other answers?

Or maybe rogue clowns* have desoldered the FPGA? Seriously, a little more
information is required! :-)

Your humble subject, Syms.

*http://www.megat.co.uk/wrong/ :-)

"king" <[email protected]> wrote in message
news:[email protected] ups.com...
>
> Hi
>
> I'm using RocketIO with 4 channels, but they would loss banding when
> the data flow
> becomes fast.
> What would result in lossing channel banding?
> And how to avoid this problem?
>
> Many thanks!
>
> king
>



Reply With Quote
  #3 (permalink)  
Old 04-25-2006, 01:18 PM
colin
Guest
 
Posts: n/a
Default Re: How to avoid lossing channel bonding when using Rocket IO?

I have no idea why you think this would happen.
If you have four channels and you clocked them identically at the
source they will arrive at the destination at different times due and
data on different channels would not be synchronised with each other.
Channel bonding simply transmits a marker on all four channels on the
same clock so that when they arrive at the destination the very small
elastic buffer adjusts itself so that data out from the four channels
comes out on the same clock correctly.
In theory you only ever need to do it once but noise could confuse it.
It doen't matter how much data you then send, the system knows that
data a,b,c&d was all sent on clock x and the receiver presents a,b,c&d
out on the same clock

Colin


king wrote:
> Hi
>
> I'm using RocketIO with 4 channels, but they would loss banding when
> the data flow
> becomes fast.
> What would result in lossing channel banding?
> And how to avoid this problem?
>
> Many thanks!
>
> king


Reply With Quote
  #4 (permalink)  
Old 04-26-2006, 02:56 AM
king
Guest
 
Posts: n/a
Default Re: How to avoid lossing channel bonding when using Rocket IO?

to colin:

but it really happend :-(
the frequency is 155MHz, and I made channel banding once a time
when the data flow is slow, there is nothing wrong
but as soon as the data flow becomes fast (also working at 155MHz),
the 4 channels can not receive a special mark at the same time
so I think they are lossing channel banding

I wonder what happend when the speed of data flow changes, and why this
can
result in the loss of channel banding.

Thanks a lot!!

king

Reply With Quote
  #5 (permalink)  
Old 04-26-2006, 05:29 PM
Ed McGettigan
Guest
 
Posts: n/a
Default Re: How to avoid lossing channel bonding when using Rocket IO?

king wrote:
> to colin:
>
> but it really happend :-(
> the frequency is 155MHz, and I made channel banding once a time
> when the data flow is slow, there is nothing wrong
> but as soon as the data flow becomes fast (also working at 155MHz),
> the 4 channels can not receive a special mark at the same time
> so I think they are lossing channel banding
>
> I wonder what happend when the speed of data flow changes, and why this
> can
> result in the loss of channel banding.
>
> Thanks a lot!!
>
> king
>



You need to rephrase your problem in a way that makes sense so
that someone can help you. The numbers of bits that are being
transmitted and received will always be the same so you can't
simply say "as the data flow becomes fast" you need to elaborate
on this so that others can understand what is happening.

You also haven't mentioned which device you are using or the
protocol that you are using, so it is next to impossible to help
out.

Ed
--
Xilinx Inc.
Reply With Quote
  #6 (permalink)  
Old 04-28-2006, 02:12 AM
king
Guest
 
Posts: n/a
Default Re: How to avoid lossing channel bonding when using Rocket IO?

to McGettigan:

thank you for your remind.

I use the VII Pro xc2vp20 device.
There are 8 GTs, and I used 4 of them.
The protocol is Custom.
The clk is 155MHz, the data width is 2 bytes,
So these 4 bonded channels could process 10Gb/s data flow in theory.

Unfortunately, however, it could only work at 1.5Gb/s in field.
At this(1.5Gb/s) time, all the things looks right:
The FSM on both TX and RX sides transformed well,no invalid state, no
invalid transmition.
And the Rocket IO works well: no rxlossofsync, no rxnotintable...
RX can receive the 4 SOPs at the same time(channel bonding ok).

As soon as the flow rate increase to 2Gb/s and upper,
The RX side could not receive the 4 SOPs simultaneously,
which is one of the transmition conditions of my RX FSM,
so the FSM will stop.
And I know that it lossed channel bonding.
In order to overcome this error, I send CBS once again as soon as
sending 65535 data packets at TX side.
CBS would let the RX FSM continue to move, but it looks wierd.
There are some invalid transmition happend,
And some error signals of Rocket IO appears, such as rxlossofsync,
rxnotintable.

That is my problem.

Many thanks!

king

Reply With Quote
  #7 (permalink)  
Old 04-28-2006, 06:43 PM
Ed McGettigan
Guest
 
Posts: n/a
Default Re: How to avoid lossing channel bonding when using Rocket IO?

king wrote:
> to McGettigan:
>
> thank you for your remind.
>
> I use the VII Pro xc2vp20 device.
> There are 8 GTs, and I used 4 of them.
> The protocol is Custom.
> The clk is 155MHz, the data width is 2 bytes,
> So these 4 bonded channels could process 10Gb/s data flow in theory.
>
> Unfortunately, however, it could only work at 1.5Gb/s in field.
> At this(1.5Gb/s) time, all the things looks right:
> The FSM on both TX and RX sides transformed well,no invalid state, no
> invalid transmition.
> And the Rocket IO works well: no rxlossofsync, no rxnotintable...
> RX can receive the 4 SOPs at the same time(channel bonding ok).
>
> As soon as the flow rate increase to 2Gb/s and upper,
> The RX side could not receive the 4 SOPs simultaneously,
> which is one of the transmition conditions of my RX FSM,
> so the FSM will stop.
> And I know that it lossed channel bonding.
> In order to overcome this error, I send CBS once again as soon as
> sending 65535 data packets at TX side.
> CBS would let the RX FSM continue to move, but it looks wierd.
> There are some invalid transmition happend,
> And some error signals of Rocket IO appears, such as rxlossofsync,
> rxnotintable.
>
> That is my problem.
>
> Many thanks!
>
> king
>


Ok, this has more information on your problem, but I still need to
make some assumptions such as these:

1) You are communicating between 2 seperate boards
2) Each board has its own clock source and thus some frequency PPM difference
3) Your custom protocol transmits 8b10b characters
4) Your custom protocol transmits a clock correction (CC) sequence when in IDLE

My initial thought is that your custom protocol has not been designed to
properly handle the necessary amount of clock tolerance.

When each link is transmitting 1.5Gbps with IDLE/clock correction characters
between bursts the receivers are able to insert or delete enough of the IDLE/CC
characters to handle the frequency difference between your receiver and
transmitter. When you increase the burst size and the time between the
IDLE/CC transmissions you exceed the size of the elastic FIFO in the receiver
and get an underflow/overflow condition and your link goes bad (loss of channel
bonding, invalid characters, etc..).

You mentioned transmitting 65535 data packets followed by a CBS (Channel
Bonding Sequence). Even if a data packet was only 2 bytes, this would
definitely be creating problems as most protocols would generate a CC
every 4-8K bytes.

Instead of creating your own custom protocol I would suggest using the
Aurora protocol that we developed and deliver as part of CoreGen. This
will handle everything that you want to do including channel bonding in
a nice simple package.

Ed
--
Xilinx Inc.
Reply With Quote
  #8 (permalink)  
Old 05-08-2006, 03:06 AM
king
Guest
 
Posts: n/a
Default Re: How to avoid lossing channel bonding when using Rocket IO?

to Ed McGettigan,

Thank you very much and sorry for late reply.
I am during vocation from 5.1 to 5.7

All you assumptions are correct!

As for CC, I send one after transmitting 5 data packet,
each packet has a constant length: 256 bytes.

And now I found some new phenomenons:
The data flow is TX_fifo -> (TX_logic -> RIO -> RX_logic) -> RX_fifo,
when there is no operation to the rx_fifo( rx_fifo_wr is ' 0' ),
the RIO would seem to be OK, the RX FSM is all right.
As soon as I use the rx_fifo, the whole data flow would be bad, just as
metioned.

I am very surprised at this phenomenon.
Because there is no feedback from the rx_fifo to the RIO,
why the operation to the fifo would influence the RIO?

Do you think this is caused by PAR?

Thank you!

king

Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
How to avoid negative slack? himassk Verilog 0 11-02-2006 05:16 PM
How to avoid negative slack himassk Verilog 2 10-23-2006 12:28 AM
How to avoid this waring in ISE 8.1? Devlin FPGA 5 04-25-2006 06:33 AM
How to avoid pulse swallowing? Jan Stuyt Verilog 2 09-22-2005 01:15 AM
How to add DCM as customized IP using FSL channel Aroul FPGA 0 05-05-2005 02:42 AM


All times are GMT +1. The time now is 09:44 AM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved