Connectivity

[nicoan87]

Hi,
I'm trying to implement a full-duplex single lane Aurora module (v6.2) using ISE 13.4

I want to connect two spartan6 xc6slx150t and I'm trying with a 600Mb lane rate

to simulate the communication, I instantiated two aurora module and connected each other

in simulation line_up goes high, but channel_up remains low

I checked the following signals in lane_init_sm_i:

begin_r

rst_r

align_r

realign_r

ack_r

ready_r

and they seems to work fine, ready_r goes high and then line_up is asserted

I checked the following in channel_init_sm:

reset_channel -> goes down after line_up is up

wait_for_lane_up_r -> goes down

verify_r -> goes up

all_lanes_v_r -> remains low

got_first_v_r -> remains low

bad_v_r -> remains low

ready_r -> remains low

I'm using the clock_module and the standard_cc_module generated with the aurora core.

all the clock signals are toggling correctly

the simulation tool is ISIM

do you have any ideas on how to fix the problem?

thank you

[nicoan87]

no ideas?
does anyone know how can i try to fix this?
please, i'm stuck in my project

[dbarrowman]

Hi,

I've been doing the same, struggling with Aurora IP cores and simulations, for weeks. You will find that Xilinx has not tested much of this. Especially simulators other than Modelsim, particulary ISE, which is quite ridiculous. I have found simple things, like inverted resets, or a syntax error in a batch file. In the batch file, which you could tell was edited from the (probably working) Linux one, they forgot to change a backslash to a forwardslash (or vice versa). This causes one block to be completely dropped out, which you won't notice since it'll be buried in the 100's of other warnings you get that are "OK", and the simulation won't work at all.

Beware, I've also could never get their Aurora 8B/10B example working at all, on a single channel, that I had fully tested with IBERT (no errors). I finally now just switched to Aurora 64B/66B, and everything works, right away! I wish I would have tried this weeks ago. So I think it's clear they have some bug they haven't found yet. I also am using ISE 13.4.

I hope you enjoy finding Xilinx's bugs for them. I don't.

Let me know specifically which SIM you are trying to run and I'll see if I have it. As I fix Xilinx's bugs, I save the project, so I may still have that one.

Regards,

Dan

[rcingham]

I haven't tried the V6.2 Aurora IP, biut have been successful embedding V5.2 stuff in working FPGAs.

The not-named-as-such active-low reset was briefly annoying.
Also, INIT_CLK had to be less than half the frequency of REF_CLK (or more than twice the period).

[dbarrowman]

In the end, my main problem was this:

http://www.xilinx.com/support/answers/46879.htm

Which was not and is still not, listed in the open issues for Aurora (8B/10B only since 64B/66B doesn't have the hot plug block).

The current version 8.1 which just came out with ISE 14.1 fixes this also.

Unfortunately "simple" bugs can take lots and lots of time to find. I think calling these designs an "IP core" is a bit of a stretch sometimes. "Example design" is a better description.

Regards,

Dan

[dbarrowman]

Thanks for the tip about the INIT_CLK. I was about to use one that was much faster...

Regards,

Dan

[geoffbarnes]

What is the name of that "not-named-as-such" reset?

I noticed in the example design that the clock compensation block is held in reset when all the lanes are up?  Shouldn't the CC module be allowed to run run when the lanes are up?

   assign lane_up_reduce_i = &lane_up_i

    // Clock Compensation
    xfpga_aurora_STANDARD_CC_MODULE standard_cc_module_i
    (
        .RESET         (lane_up_reduce_i),
        // Clock Compensation Control Interface
        .WARN_CC       (warn_cc_i),
        .DO_CC         (do_cc_i),
        // System Interface
        .PLL_NOT_LOCKED(pll_not_locked_i),
        .USER_CLK      (au_clk)
    );

[dbarrowman]

Be careful. In some cases in the example designs, particularly the resets, they may be named as active "high" logic but are actually active "low" logic (or vice versa). I found this difference between the Aurora 8B/10B design and the 64B/66B design.

Dan

[rcingham]

> What is the name of that "not-named-as-such" reset?

RESET. It is actually an active-low reset, and probably would be better named RESET_N.

[geoffbarnes]

Ah yes.   I think the reset inversion was in the "reset_logic.v" module.   I ditched that one.

The CC_MODULE looks to me to have an active high reset, which is driven by LANE_UP..

That seems backwards..    I thought the cc module should run while the link is running and not somthing that happens once while the link is down and training.

Anyone else see this?