Aurora_401 reference allows 8B/10B bypass?

[Johnson]

I am currently using version 1.7 of the VHDL Aurora 401 reference
design for Xilinx Vertex II Pro RocketIO interface and trying to find
a way to bypass 8B/10B. What I do is to change the configurations of
ports and attributes of GT_CUSTOM as suggested in RocketIO transceiver
User Guide (page 59 to 61 for Ver2.1). Those ports/attributes are:

TXBYPASS8B10B
RX_DECODE_USE
TXCHARDISPMODE
RXCHARDISPVAL

It turns out that CHANNEL_UP is never asserted. The protocol engine
seems sending the Sync sequence, but the link is nerver initialized.
Does anybody know if Aurora_401 allows bypassing 8B/10B by some easy
reconfiguration? If not, is there any sample codes in VHDL using
GT_CUSTOM for RocketIO and bypassing 8B/10B? Thanks!

Best Regards,

Johnson
Univeristy of Delaware

 

[Philip Freidin]

On 22 Nov 2003 21:30:45 -0800, wangxiao@eecis.udel.edu (Johnson) wrote:

I am currently using version 1.7 of the VHDL Aurora 401 reference
design for Xilinx Vertex II Pro RocketIO interface and trying to find
a way to bypass 8B/10B. What I do is to change the configurations of
ports and attributes of GT_CUSTOM as suggested in RocketIO transceiver
User Guide (page 59 to 61 for Ver2.1). Those ports/attributes are:

TXBYPASS8B10B
RX_DECODE_USE
TXCHARDISPMODE
RXCHARDISPVAL

It turns out that CHANNEL_UP is never asserted. The protocol engine
seems sending the Sync sequence, but the link is nerver initialized.
Does anybody know if Aurora_401 allows bypassing 8B/10B by some easy
reconfiguration? If not, is there any sample codes in VHDL using
GT_CUSTOM for RocketIO and bypassing 8B/10B? Thanks!

Best Regards,

Johnson
Univeristy of Delaware

If you are bypassing the 8B/10B encoder on transmit, are you doing
something in your logic that guarantees that you are still sending
a balanced code? what about max run length of "0" and "1"?

If you have disabled 10B/8B at the receiver, are you still sending
it comma characters for it to sync to (K28.5 I think).

I suspect the intention of the 8B/10B bypass is for an occasional
character in a transmit stream that is predominantly valid 8B/10B
encodes, with the bypass being used to achieve something that is
very non-standard. While you could use it to send 100 10B characters
of "0000000000", I would not expect a receiver to tolerate this.

What is you reason for wanting to bypass the 8B/10B encoder.

Philip Freidin


Philip Freidin
Fliptronics

 

[Marc Randolph]

Philip Freidin wrote:

On 22 Nov 2003 21:30:45 -0800, wangxiao@eecis.udel.edu (Johnson) wrote:

I am currently using version 1.7 of the VHDL Aurora 401 reference
design for Xilinx Vertex II Pro RocketIO interface and trying to find
a way to bypass 8B/10B. What I do is to change the configurations of
ports and attributes of GT_CUSTOM as suggested in RocketIO transceiver
User Guide (page 59 to 61 for Ver2.1). Those ports/attributes are:

TXBYPASS8B10B
RX_DECODE_USE
TXCHARDISPMODE
RXCHARDISPVAL

It turns out that CHANNEL_UP is never asserted. The protocol engine
seems sending the Sync sequence, but the link is nerver initialized.
Does anybody know if Aurora_401 allows bypassing 8B/10B by some easy
reconfiguration? If not, is there any sample codes in VHDL using
GT_CUSTOM for RocketIO and bypassing 8B/10B? Thanks!

Whenever I see stuff discussing a channel being "up", I usually assume
it refers to connections that use 8B/10B unless it says otherwise....
so... are you sure that CHANNEL_UP can be asserted even when 8B/10B is
not being used?

If you are bypassing the 8B/10B encoder on transmit, are you doing
something in your logic that guarantees that you are still sending
a balanced code? what about max run length of "0" and "1"?

If you have disabled 10B/8B at the receiver, are you still sending
it comma characters for it to sync to (K28.5 I think).

I have to admit that I don't understand what you are saying here.
Unless I'm mistaken, if 10B/8B is disabled, the comma characters
wouldn't (and actually, couldn't) be extracted from the datastream.
Wouldn't that typically cause problems?

I suspect the intention of the 8B/10B bypass is for an occasional
character in a transmit stream that is predominantly valid 8B/10B
encodes, with the bypass being used to achieve something that is
very non-standard. While you could use it to send 100 10B characters
of "0000000000", I would not expect a receiver to tolerate this.

What is you reason for wanting to bypass the 8B/10B encoder.

We bypass it to do SONET.

Have fun,

Marc