cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dtheodor
Adventurer
Adventurer
10,282 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
Reply
1 Solution

Accepted Solutions
dtheodor
Adventurer
Adventurer
17,619 Views
Registered: ‎06-03-2008

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
Reply
8 Replies
drjohnsmith
Teacher
Teacher
10,271 Views
Registered: ‎07-09-2009

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
Reply
venkata
Moderator
Moderator
10,260 Views
Registered: ‎02-16-2010
Is this Aurora 8B10B (or) Aurora 64B66B?
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Reply
dtheodor
Adventurer
Adventurer
10,246 Views
Registered: ‎06-03-2008

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
Reply
venkata
Moderator
Moderator
10,229 Views
Registered: ‎02-16-2010
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
------------------------------------------------------------------------------
dtheodor
Adventurer
Adventurer
10,227 Views
Registered: ‎06-03-2008

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
Reply
dtheodor
Adventurer
Adventurer
10,175 Views
Registered: ‎06-03-2008

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
Reply
dtheodor
Adventurer
Adventurer
10,171 Views
Registered: ‎06-03-2008
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
Reply
dtheodor
Adventurer
Adventurer
17,620 Views
Registered: ‎06-03-2008

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
Reply