- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
Virtex5 RocketIO GTP near-end PMA Loopback test
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-01-2011 06:07 AM
trying to setup an GTP near-end PMA Loopback test but failed so far. The Rx and Tx path is working independently fine on our card. Now I wonder if I have misunderstood how to enable the loopback test. What I have done is to drive "010" on the LOOPBACK0 and LOOPBACK1 ports of the GTP_dual block.
Q: Is this all what needs to be done?
I'm looking at this for a while now. Any suggestions how to approach the debug?
Re: Virtex5 RocketIO GTP near-end PMA Loopback test
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-01-2011 06:26 AM
hello
there is a limitation during this test: the RX P and N pins should not be driven. is this true in your case?
regards,
Giovanni
Re: Virtex5 RocketIO GTP near-end PMA Loopback test
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-01-2011 07:02 AM
thanks Giovanni for fast reply.
on our board the RX P and N pins are connected to the PHY and I assume they are always driven.
Q1: Does this mean the loopback test can not be executed when a PHY is on the board?
While reading the "Virtex-5 FPGA RocketIO GTP Transceiver" ug196.pdf (v2.1) document on page 215 "Near-End PMA Loopback" it states:
When the device is on a board, the remote transmitter should be 3-stated. If this is not possible, then the following alternatives are available:
• Turn the RX linear equalizer on by driving the RXENEQB(0/1) signal Low.
• Set RXEQMIX(0/1)[1:0] to 11.
• Change PMA_COM_CFG[44:37] from the default value 00000000 to 10101010.
This setting for PMA_COM_CFG[44:37] must only be used for loopback. With normal
data, performance is affected.
The PMA_COM_CFG[44:37] attribute can be changed either statically by specifying the
value in the UCF file or dynamically by changing the content of DRP address 26[6:3] from
0000 to 1111. When switching from loopback mode to normal operation, the default
value 00000000 must be restored.
Q2: Is this part still valid? Are the alternatives OR or AND? Meaning is one of the above sufficient or need all three things be done?
I'm reasonable sure that I have done all the above. But still no luck.
Then reading on page 327 about the DRP address 26[6:3], it doesn't line up with anything related.
Q3: why is the register map not matching the text?
Q4: How do I set the PMA_COM_CFG[44:37] in the .ucf file?
Q5: Would this build then be permanently in loopback?
Many Thanks,
Thomas
Re: Virtex5 RocketIO GTP near-end PMA Loopback test
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
12-01-2011 11:28 AM
hello,
please, do you have the opportunity to temporarily remove the series decoupling capacitors before the receiver and see if this is really the issue?
Otherwise,
- all conditions must be met at the same time.
- in the wrapper example design there is a ucf file (gtp_attributes.ucf) you could use as example to drive this and other parameters. Yes this set this attribute forever.
- if you want to change dynamically please use the DRP interface.
thanks
GG











