Issue with Simulation Stalling in Intel P-Tile Streaming PCIe Gen4 x8 Example Design

Hi

Can you explain how the process starts for link training in the code and how and where the subsequent tasks are called in the BFM for both the Root Port (RP) and Endpoint (EP)? I’d like to understand how the process begins and progresses.
>> The exact flow does not stated clear in user guide, But I try to explain as much as I could referring to my understanding toward PCIe system. It might not be exactly same as P-tile PCIe , but I believe the fundamental would be the same. Those are for your reference purpose, please correct me if you think I am wrong.
>> The link training process begins with the power-up and reset of both the Root Port and the Endpoint. This is managed by the power management and reset control logic of the system. Once powered up and out of reset, the Root Port initiates the link training process by sending a series of training sequences, known as TS1 and TS2, to the Endpoint. These sequences are used to negotiate the link parameters, such as link width and speed.
>> The Root Port then enters a polling state, waiting for the Endpoint to respond with its own training sequences. During this phase, the Root Port and Endpoint exchange information to agree on the link parameters. Once both sides have agreed on the parameters, they transition to the "Link Up" state, indicating that the link is trained and ready for data transfer.
>> On the Endpoint side, after power-up and reset, it waits to receive the training sequences from the Root Port. Upon receiving these sequences, the Endpoint responds with its own training sequences. This exchange continues until both the Root Port and Endpoint agree on the link parameters. Once the negotiation is complete, the Endpoint also transitions to the "Link Up" state.
>>In a BFM, this process is typically modeled using a series of tasks and functions that simulate the behavior of the Root Port and Endpoint. For the Root Port, an initialization task handles the power-up and reset sequence. This is followed by a link training task that sends the training sequences to the Endpoint and waits for a response. Once the link training is complete, a link up task is called to indicate that the link is ready for data transfer.
>> Similarly, for the Endpoint, an initialization task handles the power-up and reset sequence. A link training response task is then called to respond to the training sequences sent by the Root Port. Once the negotiation is complete, a link up task is called to indicate that the link is ready for data transfer. The sequence of calls in the BFM typically starts with the Root Port initialization, followed by the link training and link up tasks. The Endpoint follows a similar sequence, starting with initialization, followed by the link training response and link up tasks. This ensures that both the Root Port and Endpoint are synchronized and the link is properly trained and ready for data transfer

What could be causing these differences, and how can I ensure smooth simulation without getting stuck?
>> Following our user guide https://www.intel.com/content/www/us/en/docs/programmable/683038/24-1-9-1-1/running-simulations-using-questasim.html

>> we are suggested to use ld_debug, using "ld" only could potentially cause malfunction.

How can I avoid this warning while maintaining necessary visibility without impacting simulation performance? Could this warning be related to the delays I’m experiencing?
>> aside of the warning, do you see any error code raise up ?
>> those warning can safely ignored. However I suggest you to try out Quartus v24.3 , I believe we have better optimization on it. let me know if you still seeing the same issue

In the simulation waveform ,One observation is the p0_reset_status_n signal remains low for approximately 100,000 ns, which seems to delay progress. Are there any adjustments or optimizations to reduce this reset assertion time? Could this be the case delay I’m experiencing?
>> I do not experience the same before, perhaps you can check your .v file code and see if you can toggle the p0_reset_status_n signal assertion or not.
>>Check the logic that controls the p0_reset_status_n signal. Ensure that the conditions for deasserting the reset are met as soon as possible. Look for any unnecessary delays or conditions that might be keeping the reset asserted longer than needed. Ensure that the reset signal is properly synchronized with the clock domain it is associated with. Improper synchronization can cause metastability issues, leading to longer reset times.

Regards,
Wincent