03-13-2009 01:02 AM
I'm currently facing the following scenario:
- transmission between two boards using Virtex5 GTPs (8 GTPs on each board), same clock source
- line rates: 3.2 Gbps, 16 bit TX/RX interface -> USRCLK2 runs @ 160 MHz
- at every USRCLK2 the TX interfaces are provided with samples -> constant payload of 2.56 Gbps equals to the remaining transmission bandwidth using 8B/10B (3.2 *0.8=2.56 Gbps)
- the 8*16 bits need to be transmitted synchronously -> channel bonding is required
The very question is: would the transmission be reliable/stable if a startup phase (wait for comma alignment and channel bonding to be done) is followed by a constant data stream, where no commas and channel bonding sequences can be sent anymore (protocol overhead converges to 0 % as time advances)?
I would be very grateful for any idea/hint/remark!
03-14-2009 03:17 AM
You may wish to try writing a BERT (bit error rate test) core to run at your desired frequency. I suspect you will find that the bit error rate is small, but non-zero; and if there is any difference at all between the clocks on either end, then you would be in trouble.
Further, the protocol overhead can't be zero, since minimally you need to escape commas going over the wire! I'd advise that you look up some existing protocols that use the GTPs (SATA, PCIe, ...), and see what they do, and get an understanding of why they do it.
03-15-2009 04:22 PM
I disagree with joshua_'s statement that protocol overhead can't be zero. I'm not sure what "[escaping] commas going over the wire" means, but I don't see how it can be true when there are no commas being transmitted. Further, there will literally be no difference between the clocks, which makes clock compensation (and hence commas) not strictly needed.
To the OP: Yes, what you suggest is possible, but I would suggest looking at alternate implementation mechanisms before pursuing what you suggest. Using the GTPs with clock compensation is much easier than using them without. Further, debugging them with clock compensation is going to keep you sane, whereas debugging without will not. Note that that at least GTXes can multiply a reference clock by 30 as well as by 10 and 20, so you could consider that for a bit of extra channel capacity.
03-18-2009 01:12 AM
Joshua_ and bialken: thanks for the replies!
@Joshua_: after the initialization of the transmission there will be no commas sent in the data stream: I will not have the opportunity (or luxury) of sending them, as the continuous data stream utilizes the whole bandwidth. This is not exactly the way the GTPs are intended to use, but I have no other choice. Writing a BERTis obviously needed for verification.
@bialken: after going through the proper user guides I did not find any statement that would prove/disprove my original assumption so your answer was indeed helpful. Using GTXes is currently out of question, I need to verify the concept with GTPs (re-use of existing hardware).
03-18-2009 08:12 AM
I did not intend to imply that GTPs can't multiply the reference clock by 30. I'm not sure about the GTP, since I've never used one. You'd have to check if you can do a multiply by 30 in the GTP.
03-19-2009 12:03 AM