cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable
7,321 Views

How does the PCIE Core model electrical domain behavior at on the PCI_EXP interface?

Jump to solution
I am having trouble running Denali Puresuite LTSSM tests against the Xilinx PCIE Core integrated inside the Virtex-6 FPGA. The issue involves how the Xilinx core models electrical domain behavior. I setup the testbench using the Xilinx SERDES interface PCIE signals (PCI_EXP interface). The problem that I am having is trying to determine how Xilinx models analog behavior such as “Receiver Detection sequence” and “electrical idle exit conditions” on the differential signals. For example, when debugging my waves, I see that the Xilinx PCIE core drives Electrical Idle with 1/1 on the PCI_EXP interface in Detect.Quite state. I was expecting the PCIE core to drive “receiver detection” with some other value that in state Detect.Active. Instead, I see the PCIE core driving 1/1. Looking deeper I do see that the Xilinx PIPE signals exhibit different behavior in states Detect.Quite & Detect.Active. For example, in state Detect.Quite the PIPETXxDATA is 0 and in state Detect.Active it is non-zero. This difference in behavior is not promted to teh SERDES interface. This is one of a few issues that I am running into due to electrical domian modeling. I realize that these issues are not specified in the PCIE Sepcification. Bottom line, in order to run the LTSSM test suite I need to have some understanding of a way to drive/monitor the “analog behavior” on the Xilinx PCIE interface. Is this possible to model using the SERDES interface with some XILINX parameters? Do I need to use the PIPE interface instead – we ideally would like to run compliance tests with the SERDES interface? Do you have some kind of glue logic that I can integrate into my testbench to model the PCIE “electrical domain” behavior inside my functional verification PCIE testbench?
0 Kudos
Reply
1 Solution

Accepted Solutions
Xilinx Employee
Xilinx Employee
11,216 Views
Registered: ‎04-06-2010
You won't see the analog behavior of the detect state on the serial lines. Instead you'll see the pipe interface assert txdetectrx and the GT should always come back with phystatus pulsing and the rxstatus indicating that something is present.

Is you link partner not able to get past the detect state? Or is the FPGA not able to get past detect?

View solution in original post

0 Kudos
Reply
2 Replies
Xilinx Employee
Xilinx Employee
11,217 Views
Registered: ‎04-06-2010
You won't see the analog behavior of the detect state on the serial lines. Instead you'll see the pipe interface assert txdetectrx and the GT should always come back with phystatus pulsing and the rxstatus indicating that something is present.

Is you link partner not able to get past the detect state? Or is the FPGA not able to get past detect?

View solution in original post

0 Kudos
Reply
Anonymous
Not applicable
7,301 Views

It looks like I would need to examine the PIPE signals to determine what LTSSM Detect state of the FPGA as you have shown in this message. The SERDES interface does not give a clear indication.

 

I am able to bring the FPGA and the link partner to L0 state using the SERDES interface for most of my testing. However, when I am running compliance tests that verify fine LTSSM behavior in Detect State for activity such as LTSSM state jumps and/or timeouts and/or lanes being disabled then the test(s) fails due to the SERDES interface not modeling analog behavior.  

 

BTW - This analog behavior also occurs in other LTSSM states other than Detect state such as Disable state.

 

Potential Solution:

It appears that my work around this is to use the PIPE interface instead of the SERDES. Do you have any information and/or example and/or denali soma file for using your PIPE interface for simulation? Do you have any parameters/ifdefs that could help me use the PIPE interface?

 

In addition, even more importantly, using the PIPE interface will improve our simulation performance for a great majority of our testing.

0 Kudos
Reply