12-18-2018 03:15 PM
My setup: Central FPGA is Artix-7 200T talking to many cartridges (also Artix-7 200T). Each link is Aurora 8b/10b (2.5Gbps) using 2 GTP channels. Vivado 2018.2.
I know each channel works separately because I tested with IBERT, so the hardware works.
In the cartridges FPGA, there is only one Aurora link. All the cartridges use the same bit file. In the Central FPGA, 2 Aurora links share the same GTP-Quad. To do this, I generated an Aurora core with the Shared logic instantiated in the example design. I generated the example design. I took the Aurora_8b10b_0_support.Vhd file and I added a second Aurora_8b10b_0 instance in it, duplicating some ports as needed.
With this setup, I can get the original Aurora to work, but the added Aurora never gets the lane-up/channel-up. I am sure there must be something I did not connect correctly but there is not a lot of help in the PG046 for doing this.
12-19-2018 08:30 AM
To make this work you should have to modify this module in both designs to remove the GT common from one and and to drive the signals from the remaining common to the other module to drive the signals that the removed common module would have driven. In this module gt common remains and I don't see any outputs that could be routed to the other module. If your design contains 2 aurora's in one quad and both have GT common instantiated then one must be instantiated in an otherwise unused quad and can't drive the lanes in a different quad.
12-19-2018 10:00 AM
Both Aurora instances are already in the file I posted. So there is already only one GT common.
The Aurora_support instantiates the following modules:
- 2x aurora_8b10b_0 (named aurora_8b10b_0_i & aurora_8b10b_1_i)
The signals from the GT common drive both instances of the Aurora links within the posted module. There is no need to remove it or to bring the signals out.
12-19-2018 10:50 AM
I see, I only saw 2 lanes at the top. I think you are only running these 1 lane each at the moment. You don't have the reset for one of the PLLs connected although I would expect it to lock on its own. I think the fastest way to debug this would be to simulate it or have done that already?
12-19-2018 11:24 AM
I have two lanes, see entity:
rxp : in std_logic_vector(0 to 1);
rxn : in std_logic_vector(0 to 1);
rx1p : in std_logic_vector(0 to 1);
rx1n : in std_logic_vector(0 to 1);
txp : out std_logic_vector(0 to 1);
txn : out std_logic_vector(0 to 1);
tx1p : out std_logic_vector(0 to 1);
tx1n : out std_logic_vector(0 to 1);
What reset are you talking about? Both Aurora are configured to use the same PLL from the GT common since it is the same code instantiated twice? Do I have to use a different PLL for the second Aurora?
I have not done simulation of this. Would I have to do a testbench with two cartridges, to have all the aurora modules?
12-20-2018 12:08 AM
The two Auroras can share a PLL.
For simulation, you can put two cartridges in test bench. For simpler design, you can also connect TXP/N to RXP/N of the center boards in the test bench and see if the channel up can go high.
Besides simulation, did you check the following status ports of the Added aurura?
If you set 'loopback1' to 010, can channel up go high?
12-20-2018 04:38 AM
With loopback at 010, the channel up goes high.
tx_lock1_i is high.
I will check for the reset done signals and come back.
12-20-2018 09:11 AM - edited 12-20-2018 09:13 AM
It looks like your reference clock is connected to the wrong input. Your active Quad would need to have the reference clock input on AH14/AG14 and they are connected to AG18 and AH18 which is an unused quad. Open your *DCP file and trace your reference clock connections. It could also be only your refclk input is in the right place and everything else is wrong.
12-20-2018 09:39 AM
The reference clock does come in on pins AG18/AH18 on the PCB but the other Quad is used. This was an error by the PCB designer but it should still work as per UG482:
Each GTPE2_COMMON in a Quad has four clock inputs available:
• Two local reference clock pin pairs, GTREFCLK0 or GTREFCLK1
• Two reference clock pin pairs from the other Quad situated in the same half of the device
12-20-2018 09:50 AM
I see what you mean, I will bring out the pins for the Reference clock selection and fix them for choice '6' instead of '1' for this Quad.
12-20-2018 09:54 AM - edited 12-20-2018 09:55 AM
I see, I also see Pll1PD is tied high and I see PLL1 driving 2 lanes. It does seem like you could use just use PLL0 only. Vivado should be handling the refclk selection. I don't think that is the issue.
12-20-2018 05:48 PM
I checked the TxResetDone and RxResetDone and both are high.
I tried to change the PLL reference clock, but there is still no channel up on the second Aurora.
Any other ideas?
12-21-2018 07:33 AM - edited 12-21-2018 07:34 AM
I double checked and see Pll1PD is tied high and I see PLL1 driving 2 lanes. If the PLL is in power down you are done! It will never work. It does seem like you could use just use PLL0 only but that isn't what I see in the design.
If you have only one refclk driving the GT Vivado will set it up correctly behind the scenes don't get bogged down on the refclksel ports.
12-21-2018 12:50 PM
HI Roy, Looking at the GTPE2_CHANNEL ports, all have the RXSYSCLKSEL(1:0) and TXSYSCLKSEL(1:0) as "00" meaning they use only PLL0 and not PLL1. Can you tell me where you see PLL1 being used?
12-26-2018 12:07 PM
It fooled me because the PLL1 outputs are not normally routed if they are not used. This might mean that the PLL1LOCK is routed as well and since it can't go high it could block the STARTUP state machines from completing. If nothing is obvious there the fastest way to debug would be to simulate.
12-26-2018 12:40 PM
Yes, Simulation is my next step. I also compared al the proprieties and the connections of each GTP but could not find anything obvious that would explain the behaviour.