Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
19520 Discussions

Native PHY LTD and LTR Switch

OLevy1
Beginner
575 Views

hi,

i am using the StratixV GX Native PHY in Rx Mode to receive ONU Bursts (the same way the OLT in NGPON2 Network - chrome-extension://efaidnbmnnnibpcajpcglclefindmkaj/viewer.html?pdfurl=https%3A%2F%2Fwww.intel.com%2Fcontent%2Fdam%2Fwww%2Fprogrammable%2Fus%2Fen%2Fpdfs%2Fliterature%2Fwp%2Fwp-01143-next-gen-po.pdf&clen=509581&chunk=true)

as i understand, while not expecting Burst, the Native Phy should be configured to LTR mode (asserting the set_lock_to_ref and deasserting the set_lock_to_data) and while expecting a Burst, the Native PHY should be configured to LTD mode (asserting the set_lock_to_data and deasserting the set_lock_to_ref).

should i also toggle the digitareset signal while the doing the switchovers between the modes?

i would also like to know what is the minimum time between bursts that this switch supports?

 

thanks,

Oren

0 Kudos
9 Replies
OLevy1
Beginner
554 Views

hi,

attached is the sequence i am using switching from LTR to LTD.

in the example attached there are 3 bursts of data (first one at sample -528, second in -269 and a third at -125).

time period of each sample is ~3nS (311MHz clock).

the problem can be seen in the third burst:

the Native PHY managed to lock on the preamble pattern - the rx_parallel_data AAAAAAAA (sample -108) but after that the rx_parallel_data is 0x1977B9AA (sample -92)  and 0x3E1461A1 (sample -91) when it should be 0x1977B9AA and 0xBE1469A1.

 

it looks like the problem is not the preamble length, because in case the bursts are not so close in time, there is no problem.

seems like the problem is the amount of time that the Native PHY digital reset is changing from '1' to '0' (switching from LTR to LTD).

 

i will need someone to help me solve this.

 

thanks,

Oren 

OLevy1
Beginner
507 Views

hi,

can anyone help with this one?

 

Oren

Farabi
Employee
470 Views

Hi Oren, 

 

I am Farabi who will be supporting your request. 

 

May I know few things of your setup: 

1. What kind of reset controller you used? custom logic or  using Transceiver PHY reset controller IP ? 

2. transceiver reconfiguration mode details. 

 

regards,
Farabi 

OLevy1
Beginner
465 Views

Hi Farabi,

1. i am using Transceiver PHY reset controller IP

2. the transceiver reconfiguration is attached

 

thanks,

Oren

Farabi
Employee
452 Views

Hi Oren, 

 

I am still working with engineering to confirm the issue at our side. I will update you once we have conclusion for this issue. 

 

regards,
Farabi

Farabi
Employee
433 Views

Hi Oren, 

 

based on the 3 bursts you implemented on Stratix V GX, we come into a conclusion where the shortest burst is limited to the RX deserialization factor which shown in table below :

1st burst :

1st_burst_data_no_error_locktodata.PNG

2nd burst : 

2nd_burst_data_no_error_locktodata.PNG

 

3rd burst ("rx_digitalreset" signal shortest period):

3rd_burst_data_error_but_can_lock.PNG

 

RX deserialization latency in Stratix V devices:

RX_deserialization_latency.PNG

what you can do is to prolong the "rx_digitalreset" signal so that it will allow sometime for the RX deserialization block to function properly.  That is why you see the "rx_set_locktodata" signal is asserted but the parallel data is not deserialized correctly, especially when changing from LTR to LTD. 

 

regards,
Farabi

OLevy1
Beginner
370 Views

Thanks Farabi,

I don't really understand:

the 'rx_digital_reset' signal between 2nd and 3rd bursts is '1' for 83 clocks (311MHz),  250nS.

shouldn't it be enough?

 

Oren

Farabi
Employee
321 Views

Hi Oren, 

 

If your design can't set rx_digital_reset longer than 250ns, due to hardware limitation, you can reduce the bit width of the FPGA fabric interface width from 32bits to 16bits to shorten the data deserialization time. 

 

regards,
Farabi

Farabi
Employee
321 Views

Hi Oren, 

 

I am transferring this case to community support. If you have new question, feel free to open a new thread to get support from Intel. Otherwise, the community users will continue to help you on this thread. Thank you. 

 

regards,
Farabi

 

Reply