Network Communications News (NCN) December 2016 - Page 20

F E AT U R E PON designed for customers that are in a stage where they want to select the product and are not yet ready to integrate it. As a hardware vendor, the framework for software stress testing is a very good starting point. However, you’ll want to see hardware working and that is job for the second BCDR framework, which uses the KCU1250 Characterszation Kit for the Kintex UltraScale FPGA. This framework generates and checks packets in hardware continuously so as not to see a single bit error or lose a single packet. Virtex-7 FPGAs are used in an array of applications such as 10G to 100G networking, portable radar, and ASIC Prototyping. a passive optical splitter. Users must therefore transmit in bursts, one at a time, because they share a single fibre medium to the OLT. All bursts operate at the same frequency with user-dependent phase. The OLT receiver re-synchronises its sampling phase at the beginning of each burst to properly receive the data. Each burst places a specific pattern at the beginning calle d the preamble, which helps the OLT attain lock for each specific burst. The front-end receiver of each OLT is called a ‘BCDR’ (Burst-mode Clock and Data Recovery) unit. Increasing the preamble time makes it easier to design the BCDR, but clearly a long preamble reduces upstream bandwidth efficiency. The BCDR is a key OLT component. Its efficiency directly affects the upstream efficiency of the PON line and thus the revenue/bit for the PON operator. Xilinx’s FPGA technology is pervasive in OLTs, not only in the back end as it was for DSLAMs, but also on the front end. Xilinx offers the most comprehensive set of BCDR solutions with its Xilinx UltraScale All Programmable device families. These solutions operate at 1.25Gbps and 2.5Gbps. Both rates are available on every UltraScale SerDes port, even at the lowest speed grade. Thus the UltraScale device families already represent a scalable platform for your GPON, XGPON, and NGPON2 OLTs with additional capabilities ready for future designs. Specifically, the BCDR works with 32bit deterministic locking time for efficient upstream communication. This capability exceeds ITUT G984, G987 and G989 specifications. The BCDR is delivered with instructions and collaterals to support the users address the following; How do I simulate the BCDR? How do I validate the BCDR? For an integrator, the primary problem is to select a product. A BCDR can only be tested in a PON environment, which is the integrator’s product. It’s not possible to first develop the product and then validate the BCDR. What would happen if we discover that the BCDR is not as we expected at the end of the development cycle? That is why Xilinx offers a framework around the BCDR. Together with the BCDR, you get a complete simulation test bench with a packet generator and a packet checker used to prove the BCDR’s correct operation. Much more than that: this development environment will not only test the BCDR; it will stress it and it will find its ultimate capabilities. Here are some examples: A set of multiple ONUs is generated ONUs can be forced to operate in ‘hammer’ mode, where the packet-topacket phase jump is always 0.5 per cent of the UI. We want to make sure the BCDR is absolutely insensitive to that fluctuation. All packets generated in hammer mode are shifted by 1 psec each time a multiframe packet restarts to ensure that the BCDR’s phase detector has no ‘dead’ areas. The time to lock must always be 32 bits - short and deterministic. You can also change the packet preamble length from 0 to 8K+, which covers the most stringent PON requirements from the ITU.T and the less stringent ones from the IEEE. The simulation environment runs with a script. You can see waveforms in few minutes without writing a single line of code. This environment has been How can you emulate a PON environment with a demo card? How can you hammer test a BCDR with one? The upstream data is always synthetised at double rate and the TX serialiser always generates two identical bits per upstream bit. This way, at the fabric level, the hardware framework can emulate a 0.5UI jump between any two consecutive packets, the worst that could happen in a PON environment. A hardware framework stresses the BCDR by inserting a worst-case phase step between any two packets. The payload in this framework is a truncated PRBS, which restarts after the delimiter in each packet. If your BCDR skips a packet, you will see an error in the payload. You can also change the preamble length on the fly. The full hardware test-bench is scriptable and Vivado Hardware Analyser is embedded into this bench with a large set of controls. In addition to the hammer testing, error insertion and accumulation, you can change the many SerDes features and many features of the BCDR itself, such as its digital bandwidth on the fly. SerDes configuration is another aspect that sometimes concerns users who are not so familiar with FPGA technology, so the BCDR framework includes instructions with step-by-step descriptions for configuring the SerDes to help you set up a PON OLT interface. These techniques allow you to select a complex product like a BCDR with just a GUI. In principle, you can do this even without knowing the underlying technology details. Once you have evaluated the BCDR, the hardware test-bench is your best starting point for the real project. You can embed the BCDR simply by removing the demo packet generator/ checker and replacing those modules with a real PON MAC. 20 18-20 PON – Xilinx.indd 20 02/12/2016 11:04