cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
pspear@dwavesys.com
Adventurer
Adventurer
7,502 Views
Registered: ‎01-25-2012

Aurora 8b10b v8.3 Kintex-7: Clock Correction fails

Jump to solution

I'm having a problem with the clock correction mechanism. My aurora link (4Gbps fiber) works fine with a loopback fiber but fails when connected to a second board with a separate clock. The clock differ by roughly 10ppm. Every 900us or so I see RXBUFSTATUS = '001' . A few micro seconds later RXBUFSTATUS = '101' and the link resets.

 

The problem is clearly due to the clock differences because adding capacitance to the crystal (with a finger) shifts the period between failures.

 

The DO_CC signal is generated but I see no coresponsing correction events on RXCLKCORCNT. It is like the clock correction symbols are not sent from the TX side or are not interpreted properly on the RX side.

 

I'm using the aurora code unmodified other than routing out some of the GTXE2_CHANNEL signals. I attached the coregen aurora.xco file.

 

Anyone had any similar problems? Any workarounds?

 

0 Kudos
1 Solution

Accepted Solutions
pspear@dwavesys.com
Adventurer
Adventurer
8,379 Views
Registered: ‎01-25-2012

OK now I have got it fixed. I went back to venkata's suggestion of generating GT wrapper from Series 7 GTX wizard but using the Vivado IP generator rather than coregen. The Vivado version doesn't have all the all the bugs that renders the aurora 8b10b 4 byte template unusable in Coregen. I replaced all the generic map statements for the GTXE2_CHANNEL component in aurora_gt.vhd. Now the link is working fine.

View solution in original post

0 Kudos
12 Replies
venkata
Moderator
Moderator
7,438 Views
Registered: ‎02-16-2010
To confirm if the CC characters are not transmitted, do you monitor the data input to the GT after you find DO_CC pulse asserted.

Try generating GT wrapper from GTX wizard and compare the clk_cor_min_lat and clk_cor_max_lat settings. Check with the GT wizard values/
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
pspear@dwavesys.com
Adventurer
Adventurer
7,418 Views
Registered: ‎01-25-2012

Thanks for the response.

 

I'm in the process of acquiring chipscope so that I can better view internal busses. I'm not holding my breath though because I have looked at the code and see no reason why the CC symbols would not be generated.

 

I have tried to generate 7 series GTX wizard V2.5 but couldn't outsmart all the bugs in the aurora 8b10b 4 byte template (does anyone test these things before they are released?). Start from scratch works but then I'm not sure if all the parameters are correct. Comparing the GT attributes, there are many differences. Not sure which are important and which aren't. clk_cor_min_lat was 20 in Aurora and is 24 in the GT wizard. clk_cor_max_lat was 28 in Aurora and is 31 in the GT wizard. I'm certainly not convinced that this is the problem. If we started outside the window it would reset immediately. I see many DO_CC signals between failures so there is plenty of opportunity for the elastic buffer to shift.

0 Kudos
Anonymous
Not applicable
7,411 Views

I saw a similar problem years ago with a V5 aurora design. What I discovered was that the clock correction block was never reset. I generated a global reset from the MMCM locked signal however it asserts just as the first clock edge is output so FFs with synchronous resets were not getting cleared. Some piece of logic (an FSM) was not running as a result. After delaying the LOCKED signal by 16 clocks then using it as a reset I saw the CC start working as expected.

 

Hope that helps. (Of course V5 is a long way from V7...)

0 Kudos
pspear@dwavesys.com
Adventurer
Adventurer
7,344 Views
Registered: ‎01-25-2012

Hi Tim

 

Thanks for your response. The reset isn't the problem here. I now have chipscope working and can see the CC symbols being sent and recieved at the GT interface.  The problem really looks like the RX side just does not recognise the CC symbol or fails to adjust the elastic buffer as advertized.

 

Peter

 

0 Kudos
Anonymous
Not applicable
7,340 Views

I'm not sure about the K-7, but I think I'm having a similar issue with the V-7. 

 

The Xilinx Rep. said that the Aurora V8.3 core was designed for pre-production chips and that we should use the Aurora V9.

 

I haven't tested this yet, but hopefully this helps.

0 Kudos
pspear@dwavesys.com
Adventurer
Adventurer
7,329 Views
Registered: ‎01-25-2012

Hey, thanks dkmak, I'll give that a try. It looks like V9 was realeased in Vivado but not ISE.

0 Kudos
pspear@dwavesys.com
Adventurer
Adventurer
7,302 Views
Registered: ‎01-25-2012

Nice! That fixed it. Aurora 8b10b V9.1 from Vivado 2013.2 works as expected.

 

I did download and install the latest and "greatest" ISE 14.6 but corgen still only contains Aurora V8.3.

 

Thank-you very much dkmack! I would never have thought to look in Vivado.

 

No thanks at all to Xilinx and their crappy support. I'm very disappointed and pretty pissed. It took over a month to resolve this problem when apparently it was an known issue.

0 Kudos
pspear@dwavesys.com
Adventurer
Adventurer
7,293 Views
Registered: ‎01-25-2012

Oops, jumped the gun there. The behavior changed in Chipscope and it looked like it was running but I was mistaken. After working though some other issues I noticed the origional problem once again.

0 Kudos
pspear@dwavesys.com
Adventurer
Adventurer
8,380 Views
Registered: ‎01-25-2012

OK now I have got it fixed. I went back to venkata's suggestion of generating GT wrapper from Series 7 GTX wizard but using the Vivado IP generator rather than coregen. The Vivado version doesn't have all the all the bugs that renders the aurora 8b10b 4 byte template unusable in Coregen. I replaced all the generic map statements for the GTXE2_CHANNEL component in aurora_gt.vhd. Now the link is working fine.

View solution in original post

0 Kudos
Anonymous
Not applicable
2,577 Views

Hello

 

I am using Aurora 8B10B v5.3 in my design for virtex V platforms. I am trying to check the example design generated with all the original settings of coregen except the clock freqency. I am giving seprate clocks to both the module. The testbench is not working for different clocks. 

 

Please help and let me know what needs to be done to make it work using different clocks.

 

Saurabh Agrawal

Indian Institute of Technology Bombay

0 Kudos
venkata
Moderator
Moderator
2,574 Views
Registered: ‎02-16-2010
Hi Saurabh,

Can you please start a new thread? This thread is not related to the topic you have posted.

Before you start, provide details like
whether the simulation is done with example design without any changes?
what do you mean by "test bench is not working"? if possible provide some snapshots.
------------------------------------------------------------------------------
Don't forget to reply, give kudo and accept as solution
------------------------------------------------------------------------------
0 Kudos
Anonymous
Not applicable
2,564 Views
Hey Venkata

Just posted my doubt and issues in details. Please help me out.

Thanks

Saurabh
0 Kudos