09-12-2014 05:53 AM
I have an issue with ten_gig_eth_pcs_pma core (4.1 Rev.2).
Everything seem to be ok but status_vector(250) is almost always high even after trying to clear it in using configuration_vector(517).
According to PG068 April 2, 2014 :
Look at screenshot attachement showing behavior on Kintex-7 target.
PCS RX Fault is going high one time before being cleared by configuration_vector(517) and then is going high a second time but configuration_vector(517) doesn't succeed to clear it.
Despite this "error", I receive correct ethernet frames ...
And idea of what happens ?
Thanks in advance for your help
09-14-2014 11:14 PM
I doubt if the configuration_vector(517) pulse is being recognised by the core.
Did you try giving a pulse again or stretching the pulse,did it help in clearing the bit.
09-15-2014 01:25 AM
configuration_vector(517) is applied automatically by my "logic". Is there a minimal pulse width to respect in order to clear Fault Link Status bit ?
09-15-2014 03:55 AM
It should be one user clock cycle high.
09-15-2014 04:22 AM
It seems not to be the issue. I connected Configuration_vector(517) to status_vector(250) using a simple clock process.
As usual, it clears status_vector the first time but not the second one.
Is there a status_vector bit which can give more informations of what is wrong ?
09-15-2014 09:34 AM
Here are more informations concerning my issues (I have 2 issues now) :
Behavior is the same if I connect my "FPGA" to a standard NIC card or loopback to himself using an optical fibre.
All Status vector are 0's except :
All Configuration vector are 0's except :
2. TX Frames are correctly sent but not received by NIC cards
In external loopback using an optical fibre, I can seen transmitted frame on RX side.
But using and NIC Cards, WIRESHARK cannot see any frames and Link Status window (under WINDOWS7) report that 0 packet has been received.
09-17-2014 01:22 AM
Still need help !
Is there somebody to tell me if Status_Vector bit value show something wrong, because all bits are not documented, so I can't interpret all of them.
Thanks in advance.
09-17-2014 02:17 AM
Are you sure the mapping of status vector is correct as only the bits defined in PG068 are used and remaining bits are not yet have any specific functions and are reserved for future purpose.
Also initially you said only bit 250 is high and remaining bits are ok,what are the changes between these two builds and also cross check the bit mapping you have done during ILA captures.
09-17-2014 06:59 AM
Q: Are you sure the mapping of status vector is correct as only the bits defined in PG068 are used and remaining bits are not yet have any specific functions and are reserved for future purpose.
I don't understand "mapping of status_vector" ... Status_Vector is an output of the core and I just connect them to an ILA probe in my XDC so I don't think how I can make an error in "status_vector mapping".
Q : Also initially you said only bit 250 is high and remaining bits are ok,what are the changes between these two builds and also cross check the bit mapping you have done during ILA captures.
Yes i thought that every think else where ok before I saw that TX was not working correctly. But I just find this morning Why TX Frames where not received by my NIC card. I sent 7 bytes of preamble at 0x55 instead of 6 (one preamble byte is replaced by START byte 0xFB in xGMII). Now it's ok when sending 6 bytes of preamble.
But RX PCS FAULT remains at high state. When i said that only bit 250 was high, I wanted to say that only this bits seemed to show an issue when it is high. For example, Status_Vector(268) is also high but this is not an issue (a fault) since it says that 10GBASE-R receive is aligned.
I rebuilt an ILA for xgmii signals and configuration and status vectors. See File attached
Configuration Vector bits which are high :
Status Vector bits which are high :
These are still the same as in my previous post.