Workaround For CertusPro-NX's Reveal Controller Hard IP access - PCIeLL

Workaround For CertusPro-NX's Reveal Controller Hard IP access - PCIeLL

Issue Description/Symptom:
The user RTL is unable to write to PCIe Link Layer registers through LMMI when PCIeLL is enabled and accessed on the Hard IP Setup of the Reveal Controller.

Figure 1:

Root Causes:
Reveal will insert a MUX which handles the arbitration between LMMI signals in the user design, and the generated LMMI bus from Reveal controller as can be seen from Figure 2. This method of arbitration will allow user logic to function as normal, and Reveal will only access the LMMI interface when it needs to perform reads or writes as a result it de-asserts the usr_lmmi_ready_o signal.
Figure 2:

Root Cause scenario #1: Considering that the usr_lmmi_ready_o is de-asserted when the Reveal Controller performs a read or write request, which means that the LMMI bus is busy, as a result, the user RTL cannot perform either a read or write request during that time. So, if the design does assertion and de-assertion of the PCIe Link Layer reset during initialization while Reveal Controller is accessing the PCIeLL, this will likely lead to Link Down.
Root Cause scenario #2: The Reveal Controller is using a slow JTAG clock that slows down the LMMI bus. Therefore, if the RTL is accessed using a fast LMMI clock, it could fail to access the PCIe Link Layer Registers through LMMI.

Workaround/Mitigation:
The LMMI interface can only be access by Reveal Controller after PCIe initialization from the RTL.
Use LMMI clock =/< 100MHz.

Note: If using Reveal Analyzer, ensure to use continuous clock for Reveal Sampling Clock.