Page History

...

Based on experience of implementing PGP Version 3, we determined that only 1 USER K-code was all that's needed.  In Version 4, we reduce the number of USER codes from 8 to 1 which help reduce the gate logic resource usage. This also leaves 7 reserved BTF codes available for future use.

Difference between PGP4 to Pgp4Lite

PGP Version 4 Lite (Pgp4Lite) is nearly identical to PGP Version 4 (Pgp4).  But Pgp4Lite only supports a subset of all the Version 4 features.  Here are the features that are not supported in Pgp4Lite:

• no SOC (Start of Cell)
• no EOC (End of Cell)
• VC (Virtual Channel) is supported but interleaving is NOT supported

Link Layer

PGP4 uses 64b/66b encoding to achieve DC balance of the serial data stream. Each 64-bit word is scrambled with a source synchronous scrambler with polynomial G(x)=x⁵⁸+x²⁹+1. Two bits are then appended to each word, 0b01 to mark regular data, and 0b10 to mark control characters (K-Codes). This ensures that a transition between 0 and 1 at least once every 66 bits. It is also used for word alignment. These 66-bit words can then be serialized and deserialized using the high speed transceivers found in modern FPGAs. The protocol does not specify any link rates, and any link speed may be targeted provided that the link medium and FPGA on each side can support it.

...

The number of Virtual Channels supported can be configured via VHDL generics, allowing for better resource utilization when fewer channels are needed. Total resource utilization depends on the number of Virtual Channels synthesized and the amount of buffering required per channel. 

PGP4Lite Implementation Discussion

For Pgp4TxLite, we don't instantiate the Packetizer, and instead have a customized Pgp4TxLiteProtocol block that is 90% similar to Pgp4TxProtocol, but includes the CRC logic normally handled by the Packetizer. This also removes a pipeline register stage, which is useful in ASICs to reduce area.In Pgp4RxLite, we've instead added a new Depacketizer mode that removes the packet sequence RAM. I imagine this removes a good chunk of the depacketizer logic, but the depacketizer register stage is still there. This is probably a decent tradeoff. I guess we just want to be aware that there is additional optimization to be had if needed in the future.

Going forward, it might make sense not to define "PGP4Lite" as such. Instead we'd just have a set of features which may or may not be supported.

• Cell Size
• Max Frame Size (set == Cell Size to disable SOC/EOC)
• NUM VC
• Interleaving
• Elastic Buffer - (Not needed when source synchronous)

Then the logic gets optimized based on the settings. We'd have to change the current "TxLite" to be more like "RxLite", with an optimized packetizer. A lot of automatic logic optimization is possible around the settings above, except for the extra pipeline stage in the packetizer/depacketizer.

Contact

Ben Reese

bareese@slac.stanford.edu