09-20-2016 05:32 AM
On PG046 V11 P55 there is a guideline how to assert and deassert Resets signals on TX and RX core.
We do not have a "reset" signal as seen in Figure 3-7 in our core. We have a "tx_system_reset" and a "tx_reset" signal.
Only the "gt_reset" is clear.
09-21-2016 10:01 AM
09-23-2016 12:00 AM
At the moment tx_reset is connected to the rx_reset on the RX_CORE as sideband signal. So we have no direct influence when this reset is asserted or deasserted with respect to gt_reset and tx_system_reset.
Should we connect the tx_system_reset also to the rx_reset?
10-19-2016 10:51 AM
07-24-2018 06:40 AM - edited 07-24-2018 10:43 PM
I would like to open up this topic again. Sorry for not answering your question!
We use currently the Aurora 8B10B 11.0 IP core.
It is still not clear for me which signal the "reset" in Figure 3-8 is.
1. reset is the tx_reset
2. reset is the tx_system_reset
3. reset is tx_reset AND tx_system_reset
What should be done with the signal not shown?
Is the power on sequence Figure3-7 mandatory or can we always use 3-8? We have the case that the TX device is powered on while RX is still up.
09-29-2020 02:55 PM
I'm trying to figure out the proper order of reset line de-assertions in my system, and have found what looks like a contradiction in the PG046. Reading the section titled, "Use Case 3: tx_system_reset and rx_system_reset assertion in a simplex core", it indicates that the tx_system_reset must be deactivated before the rx_system_reset. However, in the section titled, "Aurora 8B/10B Simplex Power On Sequence", the ordering of edges D and B (Figure 3-7) indicates that the "reset" line on the RX side must be released before that same "reset" line on the TX side.
How are we supposed to interpret this?