cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
9,753 Views
Registered: ‎06-03-2008

aurora channel_up vs lane_up

Jump to solution

Hello,

 

I am using Vivado 2015.1 and a ZC706 board, and I want to reset the Aurora core via software that runs on the PS. For testing purposes, the Aurora core uses MGT3 (X0Y11) that is connected in loopback.

 

When setting the MGT loopback mode to "Near-end PMA", I see that both channel_up and lane_up are asserted.

When setting the MGT loopback mode to "Normal", I see that channel_up remains deasserted, but lane_up is asserted.

 

I should note that I have a channel with only one lane. Is it safe to consider that the link is working when only the lane_up is asserted? If not, how can it happen that although my single channel is up, the lane is not?

 

Thanks,

Dimitris

 

 

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Adventurer
Adventurer
17,090 Views
Registered: ‎06-03-2008

Re: aurora channel_up vs lane_up

Jump to solution

Eventually, I switched to SMA_MGT and everything is working fine. The reason that I was facing this problem was because, Vivado, instead of using MGT3 (the one in loopback), it was bypassing my choice during the implementation, and utilized the SMA_MGT one. However, because I thought I was using MGT3, I hadn't connected any SMA cables on the SMA_MGT side..

 

This was verified by the fact that, although in the IP configuration I had selected the X0Y11 MGT (MGT3), in the implemented design I could see that Vivado bypassed my choice and used the X0Y9 MGT (SMA_MGT)! Maybe this happened because as MGT clock source I had selected W8 and W7 pins, hence Vivado thought that I wanted to use the SMA_MGT at first place..

 

Eventually, I connected two SMA cables in the SMA_MGT TX and RX connectors in loopback mode, and now it works! :)

 

Thanks for the help,

Dimitris

 

View solution in original post

0 Kudos
8 Replies
Highlighted
Teacher
Teacher
9,742 Views
Registered: ‎07-09-2009

Re: aurora channel_up vs lane_up

Jump to solution

I don't know, but dont lane up and channel up depend upon different state machines in the core ?

    so they are checking different events / synbols.

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Moderator
Moderator
9,731 Views
Registered: ‎02-16-2010

Re: aurora channel_up vs lane_up

Jump to solution
Is this Aurora 8B10B (or) Aurora 64B66B?
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Highlighted
Adventurer
Adventurer
9,717 Views
Registered: ‎06-03-2008

Re: aurora channel_up vs lane_up

Jump to solution

Thanks for the reply.

 

This is an Aurora 64/66b  v10.0 core.

 

According to PG074 - Hardware Debug Chapter, page 121, yes based on the Transceiver flowchart, aurora first checks for lane_up, and then the channel_up is asserted after "four verification sequences" have been received.

 

Now, according to the Aurora protocol:

 

"While channel bonding, all lanes in a full-duplex channel must transmit a mix of Not Ready and Channel Bonding blocks (all lanes must transmit the Channel Bonding blocks simultaneously). The minimum number of Not Ready blocks between each Channel Bonding block is four."

 

I assume that there is no hardware problem, since the lane_up is asserted, plus the MGT TX goes directly to its RX (since it is wired in a capacitively coupled TX-to-RX loopback configuration).

 

 

0 Kudos
Highlighted
Moderator
Moderator
9,700 Views
Registered: ‎02-16-2010

Re: aurora channel_up vs lane_up

Jump to solution
With Aurora 64B66B, parallel data is not verified until channel_up stage in verification step. So, it is not correct to assume link is up when only lane_up is asserted.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
Highlighted
Adventurer
Adventurer
9,698 Views
Registered: ‎06-03-2008

Re: aurora channel_up vs lane_up

Jump to solution

OK, this is what I also think.

 

I should mention that all other status signals seem OK:

1. gt_pll = 1

2. soft_err = 0
3. mmcm_not_locked = 0

4. hard_err = 0.

 

Finally, I have exported the pma_init and reset_pb to two push buttons (SW7 and SW9). While pressing either of them, deasserts the lane_up. Could it be that I am missing something during the aurora reset?

0 Kudos
Highlighted
Adventurer
Adventurer
9,646 Views
Registered: ‎06-03-2008

Re: aurora channel_up vs lane_up

Jump to solution

So the current state is as follows:

 

While using MGT3 that is wired in a capacitively coupled TX-to-RX loopback configuration (thus I don't have any external cables/connections that could be damaged), I have the following results:

 

When setting the MGT loopback mode to "Near-end PMA", I see that both channel_up and lane_up are asserted.

When setting the MGT loopback mode to "Normal", I see that channel_up remains deasserted, but lane_up is asserted.

 

Any hints on where I should check for problems?

 

Thanks!

 

 

0 Kudos
Highlighted
Adventurer
Adventurer
9,642 Views
Registered: ‎06-03-2008

Re: aurora channel_up vs lane_up

Jump to solution
As a sidenote, in the ZC706 board datasheet, regarding MGT3 is mentioned the following:

"Contains 1 GTX transceiver which is unused and is wired in TX-to-RX loopback configuration"

Does this mean that I cannot use it for testing purposes?
0 Kudos
Highlighted
Adventurer
Adventurer
17,091 Views
Registered: ‎06-03-2008

Re: aurora channel_up vs lane_up

Jump to solution

Eventually, I switched to SMA_MGT and everything is working fine. The reason that I was facing this problem was because, Vivado, instead of using MGT3 (the one in loopback), it was bypassing my choice during the implementation, and utilized the SMA_MGT one. However, because I thought I was using MGT3, I hadn't connected any SMA cables on the SMA_MGT side..

 

This was verified by the fact that, although in the IP configuration I had selected the X0Y11 MGT (MGT3), in the implemented design I could see that Vivado bypassed my choice and used the X0Y9 MGT (SMA_MGT)! Maybe this happened because as MGT clock source I had selected W8 and W7 pins, hence Vivado thought that I wanted to use the SMA_MGT at first place..

 

Eventually, I connected two SMA cables in the SMA_MGT TX and RX connectors in loopback mode, and now it works! :)

 

Thanks for the help,

Dimitris

 

View solution in original post

0 Kudos