Synchronizing TXCVR & RXCVR

--- Quote Start ---

if I want to send pattern h1234 to be detected by the Fabric on the receiver end, how do I guarantee that the data at the receiver (rx_dataout [15..0]) will be h1234 and not hxx12 (first word) , h34xx (next word)

I guess in general I am asking how do I synchronize to know where my data begins on what byte , etc..

PS: first time using Transceivers

--- Quote End ---

What device are you using? Cyclone IV GX, Stratix IV GX/GT?

Read the Handbook for the transceiver, and look at the transceiver configuration section. The ALTGX component in Basic mode has a receiver pattern detect block which can be used to do what you want.

Take a look at the appropriate handbook and try to create an ALTGX component. If you get stuck, ask, and I'll try to help.

Cheers,

Dave

Hi:

I am using the Cy IV. I instantiated transceiver with Automatic synchronization . I see the pattern signals indicated the K28.5 coding correctly .. they came h9CBC, BCBC. I figured this happens sometimes after the RX reset is de-asserted.

So now the RX FSM knows the interface is good ( Ithink).

1- If the transmitter is up an running, when should it start sending real data

2- Since the FPGA FSM transmitter side is sending "something" on every clock cycle while the synchronization is detected by the RXCVR and after when does the transmitter start sending real data? How does the FPGA FSM know the beginng of real data vs the "filled data" that was sent until synchronization ocurrs? I assume at this point a protocol with beginning or frame or something needs to be detected as well and then every clock cycle is valid data until some kind of "end of frame"? (based on some type of protocol I assume)

2- In fig 1-23 the byte order is shown misaligned but the byte ordering block that follows should put the data back into the same byte ordering as the transmitter (correct?)

thank you

--- Quote Start ---

I am using the Cy IV.

--- Quote End ---

I assume you mean Cyclone IV GX.

--- Quote Start ---

I instantiated transceiver with Automatic synchronization . I see the pattern signals indicated the K28.5 coding correctly .. they came h9CBC, BCBC. I figured this happens sometimes after the RX reset is de-asserted.

--- Quote End ---

Depending on the IP core you use, its up to you to supply the correct reset sequence, so there should be no "I figure ...", you should know when it is supposed to happen :) But yeah, once the receiver CDR locks and it transitions to lock-to-data mode, it should start synchronizing.

--- Quote Start ---

1- If the transmitter is up an running, when should it start sending real data

--- Quote End ---

The transmitter can send data whenever it likes. Whether or not the receiver at the other end is listening is another thing ...

--- Quote Start ---

2- Since the FPGA FSM transmitter side is sending "something" on every clock cycle while the synchronization is detected by the RXCVR and after when does the transmitter start sending real data? How does the FPGA FSM know the beginng of real data vs the "filled data" that was sent until synchronization ocurrs? I assume at this point a protocol with beginning or frame or something needs to be detected as well and then every clock cycle is valid data until some kind of "end of frame"? (based on some type of protocol I assume)

--- Quote End ---

Yes, it depends on the protocol. In basic mode, you have to define the protocol.

--- Quote Start ---

2- In fig 1-23 the byte order is shown misaligned but the byte ordering block that follows should put the data back into the same byte ordering as the transmitter (correct?)

--- Quote End ---

Yep. Depending on the ALTGX setup, you can access this signal manually, or the IP core wrapped over the ALTGX might use it to get data aligned correctly.

Simulate the ALTGX component and you'll get a better feel for how things work.

Cheers,

Dave

I thought I read that after reset the Transmitter sends 3 K28.5 code words automatically.

"Yep. Depending on the ALTGX setup, you can access this signal manually"

What signal are you referring?

Is there a sample simulation available somewhere?

thank you very much

--- Quote Start ---

I thought I read that after reset the Transmitter sends 3 K28.5 code words automatically.

--- Quote End ---

That is quite possible, as I said, it depends on the protocol you are using. I use the ALTGX components in Basic mode and in PCIe mode, so I've never sent a K28.5 code word, which sounds like a 10GbE protocol. The transceivers have a lot of features ...

--- Quote Start ---

"Yep. Depending on the ALTGX setup, you can access this signal manually"

What signal are you referring?

--- Quote End ---

The byte alignment signal. In basic mode, some of these signals are available for you to toggle.

--- Quote Start ---

Is there a sample simulation available somewhere?

--- Quote End ---

You'll have to check for whatever protocol you are using. I've simulated the ALTGX in basic mode, and PCIe mode, and the simulations are completely different.

Cheers,

Dave

Hi Dave:

I have read the TXCVR spec byte ordering section but still have some questions.

One thing I don't understand is the 9-bit pattern. Why is it 9-bits and not 10?

As an example, using the 8B/10B encoder on the RXCVR portion of the ALTGX configuration the default value for the ordering pattern is b'111111011 (is this a K word?). Does the pattern need to be code word to differentiate from data?

My interface to the TXCVR parallel connection to the fabric is 16-bits.

How does this pattern b'111111011 translates to the pattern that I need to send on the parallel interface, Tx_datain[15..8]= ????, Tx_datain[7..0]= ????

The ALTGX will provide a signal rx_byteorderalignstatus to indicate when the pattern was found. The configuration also provides a pad pattern, should we use this pattern for anything (we already have the signal rx_byteorderalignstatus)? I am wondering why this is user configurable.

thanks again

--- Quote Start ---

I have read the TXCVR spec byte ordering section but still have some questions.

One thing I don't understand is the 9-bit pattern. Why is it 9-bits and not 10?

As an example, using the 8B/10B encoder on the RXCVR portion of the ALTGX configuration the default value for the ordering pattern is b'111111011 (is this a K word?). Does the pattern need to be code word to differentiate from data?

My interface to the TXCVR parallel connection to the fabric is 16-bits.

How does this pattern b'111111011 translates to the pattern that I need to send on the parallel interface, Tx_datain[15..8]= ????, Tx_datain[7..0]= ????

--- Quote End ---

I don't use the 10G features of the core, so I'm not sure. When I'm trying to learn how a core works, I setup a simulation and try different stimulus inputs to see how/why things work.

--- Quote Start ---

The ALTGX will provide a signal rx_byteorderalignstatus to indicate when the pattern was found. The configuration also provides a pad pattern, should we use this pattern for anything (we already have the signal rx_byteorderalignstatus)? I am wondering why this is user configurable.

--- Quote End ---

You want to make sure the pad pattern is something that will be ignored by whatever protocol you are using. You don't want the pad pattern to be recognized as a synchronization code (whatever that happens to be).

Again, getting a simulation running can help answer a lot of these questions.

Cheers,

Dave

Hi vlsi99, I'm have the same questions concerning the byte ordering pattern as you posted on May 31st, 2012. I assume that you've found an answer to them? Could you post it?

Thanks, Roland.