Connectivity

[rcingham]

Well, in the Aurora module we are using (based on v5.2 CoreGen), it does indeed runs during normal operation.

I note that I am driving its 'RESET' input with a signal called 'link_not_up_i' in my lightly-modified wrapper.

[geoffbarnes]

Yes, just made that change myself....

Fixed all my issues, since I'm running the endpoint on different reference clocks..

Not sure how that slipped by.   For endpoints with the same clock, then the clocks are already locked.   Difficult to see in sim as well unless you contrive the clocks and run long enough...

Maybe it's already errata already...

[dbarrowman]

Thanks, is that a signal you added or something that already existed in the example design?

The v8.1 design has this:

lane_up_reduce_i <= AND_REDUCE(lane_up_i);
rst_cc_module_i <= not lane_up_reduce_i;

I've been able to get the example design running but I'm still having some issues with my own design, unfortunately.

Dan

[geoffbarnes]

Yeah, I am using 6.x, so I had to edit the example to invert the reset to the CC block..

.... it looks like they fixed it 8.1..

[dbarrowman]

One thing I'm not clear about....apparently the hot plug block (only in Aurora 8B/10B) uses the non-reception of CC characters to determine whether it should attempt to reset the link. However, the CC block is reset if the link isn't up. So I'm not sure how that doesn't result in a race condition/loop between these two state machines? But it does seem to work in the example.

I'm considering removing the hot plug block and/or the clock compensation block.

Dan

[rcingham]

I have found (Virtex-5, Aurora 8B/10B v5.2) that hot plug works.

If you are running the 2 ends from different RefClks, you MUST do Clock Compensation, but you could design your own block to do it.

[dbarrowman]

Ok, thanks. I definitely am planning to keep it, and I don't believe hot plug is necessarily the problem.

It looks like the lane init state machine on one side gets to the ACK_r state (just before READY_r) but doesn't get the SPA characters from the other side (rxack_4d_done_r), so stays there until finally the watchdog triggers and then does it cycles through the state machine all over again (Begin -> Rst -> Align -> Realign -> Polarity -> Ack).

On the other side, I'm seeing RX disparity and RX not in table errors. What can cause that, assuming the data connection is good (verified with IBERT and the Aurora example working)? Could a reset on the GTX itself be wrong?

I saw this before (RX disparity and symbol errors), with my previously mentioned/referenced problem and answer record, when the hot plug block was resetting things, however, this is no longer happening.

I have also had an issue with the Aurora 8B/10B example, where both sides seem to be "stuck", at least until I reconfigure the FPGAs, or even power cycle and reconfigure, then suddenly they start running and passing data. Am I missing a necessary reset to "kick" them? Although when I try to reset using the included Chipscope VIO, it doesn't seem to help. Could this be the same problem I'm seeing in my own design?

Unfortunately, Chipscope is quite cumbersome and time consuming for debugging. Also, you cannot easily include both a VIO unit and an ILA unit (that covers all over the design anyway, using Chipscope inserter), at the same time.

The Chipscope GUI is torture....at this point, I think I'd pay someone myself to write a new GUI for it! :)

Thanks,

Dan

[dbarrowman]

I am still struggling with this 8B/10B disparity problem. It seems to change each time with a reconfiguration, and at either end of the link. I either see no disparity errors or constant disparity errors. An overall GTX reset seems to change it sometimes, but mostly not. Reconfiguring the FPGA has the most effect. I'm wondering if it could be once again the hot plug circuit or the clock compensation? But it doesn't look like either block is causing a problem. At least as far as I can tell from Chipscope.

I'm also running the Xilinx example and I see that sometimes it also won't come up. I have to reconfigure the FPGA to get it running. Has anyone else seen problems with reset/configuration that can cause almost constant disparity errors?

I'm about ready to just give up completely on Aurora 8B/10. I've run the Xilinx example for Aurora 64B/66B and have had no problems at all. Unfortunately it will take some work to adapt my design to that, so I haven't done it yet.

Any help or advice is appreciated.

Thanks,

Dan

[dbarrowman]

Hi, can you clarify why the init clock must be less than half of the ref clock frequency? Is this due to the reset debounce? According to Xilinx's example, used on their board, the init clock is 200MHz, but I believe the ref clock is only 156MHz.

Thanks,

Dan

[geoffbarnes]

I believe the INIT_CLK was just used for the reset debounce...

I ditched that block since I didn't need the reset to be "debounced", but I just made sure the resets were properly synchronized, etc. 

If you're having flakey operation, then I would double check  your resets are properly synchronized on the correct clock domains etc.   There's a chance an unclean reset is causing grief at startup.