The remaining part of this section familiarizes you with the simulation test bench outcome, which requires an understanding of the test bench architecture.
The simulation test bench block diagram in the following figure includes:
- A G-PON-like pattern generator that can be programmed to operate at 1.25 Gb/s or 2.5 Gbit/s.
- An ideal serializer (emulating the SerDes transmitter in the ONT).
- An ideal deserializer (emulating the SerDes receiver, in lock to reference mode).
- A G-PON-like pattern checker.
- An optional section that regenerates the bursty recovered clock for debugging.
Ideal serializers and deserializers are used in place of the real SerDes models to make the simulation platform independent and to speed up simulation times.
The structure of the G-PON-like frame is shown in the following figure.
The G-PON-like pattern generator generates frames that start with a preamble and a start of frame (SOF), followed by a 16-bit counter that increases at each frame and wraps around. The payload is a truncated PRBS 7 pattern. Although any PRBS pattern can be selected for the payload, PRBS 7 has been chosen to avoid SOF/EOF emulation during the payload.
The preamble has 48 bits with alternating 1 and 0 values. The preamble length is user-programmable through the port PREAMBLE_LENGTH, with 1-bit resolution. The pattern start is an interleaved version of F628 fixed at 32 bits in length. Some fixed zeros are implemented to prevent the counter emulating the start of the pattern.
The test bench is managed by the attribute SIM_CASE in the script run_sim.do per the following table.
| SIM_CASE | Upstream Rate (Gb/s) | Oversampling Ratio |
|---|---|---|
| 1 | 1.25 | 10 |
| 2 | 2.5 | 5 |
| 3 | 2.5 | 6 |
| 4 | 1.25 | 5 |
| 5 | 1.25 | 6 |
| 6 | 1.25 | 5 |
Any bit error is detected by the truncated PRBS 7 error checker. The output PAYLOAD_ERR (from the pattern checker) counts the errors detected by the pattern checker. This counter can be reset at any time by pulsing RES_PAYLOAD_ERR asynchronously. The pattern checker continuously compares the received data to a standard PRBS7 for debugging purposes. The outputs PRBS_ERR and RES_PRBS_ERR serve this purpose.
The frame counter is used by the G-PON-like packet checker to identify the condition when one or more packets have been skipped. This condition is indicated by the line FRAME_ERR being pulsed to 1. The signal FRAME_ALIGN is always NOT(FRAME_ERR) and is thus a redundant signal.
The signals displayed in the simulation window are described first. After, the simulation results are commented (see the following table).
| SIGNAL NAME | TYPE | DESCRIPTION |
|---|---|---|
| SIM_CASE | ATTRIBUTE - TOP_LEVEL | See Table 1. |
| RES_PAYLOAD_ERR | ASINCHRONOUS INPUT - Pattern Checker | When set to 1, the PAYLOAD_ERR is set to 0. |
| RES_PRBS_ERR | ASINCHRONOUS INPUT - Pattern Checker | When set to 1, the PRBS_ERR is set to 0. |
| PAYLOAD_ERR | OUTPUT - Pattern Checker | Number of errors detected in the G-PON-like pattern. |
| PRBS_ERR | OUTPUT - Pattern Checker | Number of errors detected in the PRBS pattern. |
| PREAMBLE_LENGHT | SYNCHRONOUS INPUT - Pattern Generator | The preamble length can be set to any value between 0 and 65535. |
| FRAME_ALIGN | OUTPUT - Pattern Checker | This signal is set to 1 by the G-PON-like pattern checker when the packet number is consistent with the packet number in the previous packet. |
| FR_LOSS | OUTPUT - Pattern Checker | This is always NOT (FRAME_ALIGN) and is thus a redundant indication. |
| BURST_EN | INPUT - BCDR | When set to 0, the burst detection capability of the BCDR is disabled. This is a debug condition. This signal is connected directly to the BURST_EN input of the BCDR core. |
| DT_IN | INPUT - BCDR | Deserialized oversampled data, from the ideal deserializer. |
| FR_START | OUTPUT - Pattern Checker | It marks the frame start as seen by the G-PON-like packet checker. |
| FR_END | OUTPUT - Pattern Checker | It marks the frame end as seen by the G-PON-like packet checker. |
| FR_NM | OUTPUT - Pattern Checker | Frame number as seen by the G-PON-like packet checker. A skipped packet always produces bit errors and forces the FRAME_ALIGN to temporarily go to 0. |
| rit_int | TIME | Transport delay applied to DT_IN. |
| EN_HAMMER | INPUT - Pattern Generator | When set to 1, consecutive transmitted packets have 0.5 unit interval (UI) phase difference. |
| EN_RIT | INPUT - Pattern Generator | EN_RIT is for simulation only. Enables hammer testing and shifts all packets by 1 ps every 4 packets. The condition EN_RIT and EN_HAMMER is not allowed. |
| PRBS_EN | INPUT - Pattern Generator | When set to 1, the transmitted pattern is a PRBS 7. |
| ERR_INS | ASINCHRONOUS INPUT - Pattern Generator | Flips one bit in the transmitted data pattern, PRBS or G-PON-like. |
| PHE_BST_DRU | SIGNED OUTPUT - BCDR | This is the phase error of the incoming data. |
| PHE_BST_BURST | SIGNED OUTPUT - BCDR | This is the phase profile of the incoming data as seen by the BCDR. |
| PHE_BURST_AVE | SIGNED OUTPUT - BCDR | Average of the above signal PHE_BURST. |
| PL_O | OUTPUT - BCDR | When set to 1 by the BCDR, a preamble has been detected. |
The simulation is divided in two parts:
- Up to about 1.5 ms, the signal BURST_EN is set to 0 (debug condition).
- Afterwards, it is set to 1 (default).
The first part of the simulation shows how the BCDR behaves when the burst injection capability has been disabled. The following figure is a detail of the simulation across the BURST_EN change from 0 to 1.
On the left half of the simulation, burst detection capability is not active (debug condition). Note the phase error (in violet) being reduced with an exponential transient by the tracking loop in the lower branch. The pink trace is the phase profile of the incoming data, as seen by the BCDR. On the right side, the preamble detector is active and the NCO is steered at the beginning of each packet to the phase of the incoming data. The phase error is always kept close to 0 by the tracking loop.
This portion of the simulation on the right shows the effect of BURST_EN=1 (operating condition). The tracking loop is steered at the beginning of the packet, so that the starting phase error is minimized. It is a task of the BCDR to correctly decode all bits in the packet, sacrificing only the bits in the preamble. Only when BURST_EN is set to 1, two signals from the G-PON-like pattern checker can be used to decide whether bit errors have been seen and no frames have been lost:
- PAYLOAD_ERR: Must always be 0. Errors are accumulated if detected.
- Packet number: This value increases over time. Being the payload of a truncated PRBS, a bit error or simply a packet skip is detected through a PRBS error.
Figure 3 shows BCDR behavior when the burst injection capability has been disabled. It shows a zoom of the simulation across the BURST_EN change from 0 to 1.
When the counter is increasing over time and PAYLOAD_ERR is 0, the system is working correctly. The condition in which PAYLOAD_ERR is only equal to 0 is not enough to conclude that the system is working, because it might be that no packets are detected. For this reason, it is important that the packet number is increasing over time. In the simulation, four packets of different lengths are periodically generated roughly every 125 μs. The cyclical nature of the test bench is a simulation choice and the BCDR does not use this information.
During simulation, a delay is introduced and increased in 1 ps steps at the beginning of each group of four packets. The intent of increasing the delay is to scan all possible input phases relative to the local clock to verify that the phase detector works unbiased over a 2π radiant. One ps equals 0.9 degrees or 2.5 mUI. The phase profile of the incoming packets moves slowly as the time increases. While the first packet phase increases by 1 ps at each cycle, the second packet phase is shifted 0.5 UI backwards compared to the first packet. The intent of this test is to stress the receiver with the maximum phase change of 0.5 UI from packet to packet and verify that each frame is still captured with no bit errors. This is the most significant test conducted during the simulation and hardware test. For this reason, it is called the hammer test in the context of this application note.