02-10-2016 04:41 AM
I am using QSGMII ip core v3.3 in Vivado 2015.3
To get some debug signals like 8b10b code violations or disparity errors I have to configure the ip core with "Additional transceiver control and status ports". But when doing so I get reset inputs ports
gt0_gttxreset_in, gt0_txpcsreset_in, gt0_txpmareset_in, gtt0_rxbufreset_in, gt0_gtrxreset_in, gt0_rxpcsreset_in, gt0_rxpmareset_in
Before activating the "Additional transceiver control and status ports" those reset signals were handled internally in the ip core.
Now I have to control them, although I just wanted some debug outputs.
How can I get solve that conflict?
02-10-2016 05:46 AM
Tie them to zero. You can also refer the example design genrated with the core with Additional transceiver control and status ports enabled on how to handle the extra ports.
02-10-2016 06:17 AM
when I tie the resets to GND, the resets are not active anymore. BUT in the ip core configured without "Additional transceiver control and status ports" the resets were generated internally in the ip core, so they were not tied to GND.
The example design of the QSGMII ip core is not the answer to everything.
02-10-2016 06:34 AM
These resets going into the transceiver ports will be tied to 0 even with Additional transceiver control and status ports disabled while core generation.
Please cross check in the block.vhd file and let me know if see otherwise.
02-10-2016 07:18 AM
In the example design of the ip core without configured Control and Status ports I can see that
the ports GTTXRESET and GTRXRESET of the instance
are not tied to GND! But they are driven from the instances
02-10-2016 08:38 PM
The reset FSM's will generate and drive the transceiver resets irrespective of additional transceiver debug ports.
The top level gt0_gtrxreset_in and gt0_gttxreset_in will just go to a combo logic which does a logical or of the internal generated reset with the external in the wizard module.
You can use the external resets if you want to control them when debug ports are enabled and if not tie them to zero and it will not effect the normal core behaviour(The example design just tie's them to Zero as we don't control this externally and still the internally generated resets are driven in both with and without debug ports).
Refer corename_block.vhd and corename_transceiver.vhd modules for better understanding of this logic or see the implemented design of both the example designs.
Let me know if you still have any confusion.
02-11-2016 12:02 AM
yes, after diving into the deep hierarchy of the ip core I can see a LUT in the schematic view which is an logical OR of the
user reset signal coming from the top and the internally generated reset.
It would be helpful if some note was being put into the User Guide of the QSGMII ip core to avoid confusion.
02-11-2016 12:51 AM
I will give the feedback internally to add an note in the PG029.
Please close the thread by marking the post that answered as a Solution.