1. Home
  2. Field-Programmable Gate Arrays
  3. Virtex 4 FX Sonet Alignment

Virtex 4 FX Sonet Alignment

Is there anybody in this group who has experience with V4FX MGT Sonet Alignment?

The documentation is rather short on details. The interaction of the two alignment stages is not clear to me at all. What we see is that we get a comma detect signaled and the output data stream is correctly aligned. As a reaction on that we turn off ENPCOMMAALIGN and ENMCOMMAALIGN.

But nevertheless the MGT keeps realigning on any new occurence of the comma pattern. (only the bits are shifted around, there is no new comma detect signaled.)

What am I missing?

Kolja Sulimma

Reply to
comp.arch.fpga
Loading thread data ...

The ENPCOMMAALIGN and ENMCOMMAALIGN are for 8b10b encoded steams which are not used by SONET.

Ed McGettigan

-- Xilinx Inc.

Reply to
Ed McGettigan

According to Table 3-18 in ug076 the attribute ENMCOMMAALIGN controls the byte aligner and ENPCOMMAALIGN controls both the byte aligner and the SONET aligner.

According to that table when ENxCOMMAALIGN = '1' the byte aligner should "realign byte alignment mux when the A1 symbol is found on a non-byte aligned boundary". That is exactly what we see happening even tens of clock cycles after we set ENxCOMMAALIGN = '0'. Instead we require it to "hold alignement mux position" as it should according to documentation.

Kolja Sulimma

Reply to
comp.arch.fpga

Hi,

If you know how to write your framing and encoding for SONET you might get there with V4, otherwise look for other solutions - better documented, proven technology, etc...

Luc

Reply to
lb.edc

Actually, we are not doing SONET, we are only using the same sync pattern. We have confirmed in simulation and with chipscope that the byte aligner does not "hold alignment mux position" when ENxCOMMAALIGN='0': We have 20 prototypes in production so moving to another vendor or moving to Virtex-5 is not an option at this moment.

Kolja

Reply to
comp.arch.fpga

Here is some more detail, in case someone has any suggestions.

We transmit some random data and then insert this sequence:

6F6F6F6F 6F6F6F6F 14141414 14141414 E220BBDE 9620DD9A 90392A84 AAB44413 72642AF0 DF353E5C 16888F7F 52AAF5E6 2A4D4995 4EC21316 E399DB7C 6A4C770D

from the the receiver we get a one clock cycle pulse of RXCOMMADET and RXREALIGN. As a consequence we immediately negate ENMCOMMAALIGN and ENPCOMMAALIGN. There is some pipeline delay and after seven clock cycles the receiver outputs: EDEDEDED

6F6F6F6F (byte alignment took place) 14141414 14141414 E220BBDE 9620DD9A 90392A84 AAB44413 72642AF0 DF353E5C 16888F7F 52AAF5E6 2A4D4995 4EC21316 (everything fine till here) 6F1CCEDB (new alignment took place to first 6F) 9B5263B8 (data is no longer aligned correctly)

Clearly the byte aligner ist still operating 21 clock cycles after it has been disabled. Or is there any other part of the MGT that could affect the output data stream in the way described? RXCOMMADET and RXREALIGN are not asserted by the receiver again. We see exactly the same behaviour in simulation and with chipscope.

Kolja Sulimma

Reply to
comp.arch.fpga

Wow. From UG076 Page 125: "It is recommended that the SONET user application enable ENPCOMMAALIGN and ENMCOMMAALIGN together, and then turn them both off when alignment is achieved."

Page 195: "SONET: [...] Always keep ENPCOMMAALIGN active to prevent data misalignment."

Well, it's hard to meet both rules. So which one should take precedence?

Kolja

Reply to
comp.arch.fpga

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.