AEK_8220_Libraries/firmware_vhdl_evr320
0
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

Add robustness to comma-detection and reset generation. #8

Merged
straumann_t merged 1 commits from added_robustness into master 2021-03-16 07:44:45 +01:00
Conversation 2 Commits 1 Files Changed 2 +10 -2
straumann_t commented 2021-03-15 16:35:51 +01:00 (Migrated from git.psi.ch)
Copy Link

This patch addresses issues I occasionally observed:

  1. I have experienced occurrences when the GTX deasserts RXBYTEISALIGNED
    while the RXLOSSOFSYNC is not asserted.

    The comma-alignment state machine can be stuck in 'idle' believing
    all is well when in fact RXBYTEISALIGNED is deasserted.

    The proposed patch monitors RXBYTEISALIGNED in addition to
    RXLOSSOFSYNC in 'idle' state. This ensures that a proper
    resynchronization is performed if either RXLOSSOFSYNC or
    RXBYTEISALIGNED is asserted.

  2. The synchronizer (inst_cdc_fast_stat) which takes the pulse
    width/delay to the EVR clock domain relies on a proper
    reset sequence for correct operation.

    It is possible, however, that the 'evr_clk' (which is generated
    from the recovered RX clock) is not ticking at all when 'xuser_RESET'
    resets said synchronizer. If e.g., there is no GTX reference clock
    present (because it requires i2c initialization which is performed
    at a later stage, by software) then the EVR clock may not be ticking
    and prevent the destination side of the synchronizer from being reset. This
    has the consequence of 'width' and 'delay' never being
    updated.

    The proposed patch asserts the synchronizer reset while the RX PLL
    and/or MMCM are not locked.

I have tested this patch (by power-cycling and restarting many times)
and verified that it solves our problem.

This patch addresses issues I occasionally observed: 1) I have experienced occurrences when the GTX deasserts RXBYTEISALIGNED while the RXLOSSOFSYNC is *not* asserted. The comma-alignment state machine can be stuck in 'idle' believing all is well when in fact RXBYTEISALIGNED is deasserted. The proposed patch monitors RXBYTEISALIGNED in addition to RXLOSSOFSYNC in 'idle' state. This ensures that a proper resynchronization is performed if either RXLOSSOFSYNC or RXBYTEISALIGNED is asserted. 2) The synchronizer (inst_cdc_fast_stat) which takes the pulse width/delay to the EVR clock domain relies on a proper reset sequence for correct operation. It is possible, however, that the 'evr_clk' (which is generated from the recovered RX clock) is not ticking at all when 'xuser_RESET' resets said synchronizer. If e.g., there is no GTX reference clock present (because it requires i2c initialization which is performed at a later stage, by software) then the EVR clock may not be ticking and prevent the destination side of the synchronizer from being reset. This has the consequence of 'width' and 'delay' *never* being updated. The proposed patch asserts the synchronizer reset while the RX PLL and/or MMCM are not locked. I have tested this patch (by power-cycling and restarting many times) and verified that it solves our problem.
stef_b commented 2021-03-16 07:44:45 +01:00 (Migrated from git.psi.ch)
Copy Link

merged

merged
stef_b commented 2021-03-16 07:44:45 +01:00 (Migrated from git.psi.ch)
Copy Link

mentioned in commit 5bf9caae3a

mentioned in commit 5bf9caae3a0db6697560a8af9d6ecff4973d293f
Sign in to join this conversation.
Reviewers
No Reviewers
Labels
Clear labels
Bug_tb
Improvement
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
stef_b
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: AEK_8220_Libraries/firmware_vhdl_evr320#8
No description provided.
Delete Branch "added_robustness"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?