cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
7,197 Views
Registered: ‎01-04-2011

PCIe Root Port Fatal Error

Jump to solution

Hello,

 

I'm currently simulating using Xilinx PCIe Root Port v1.6 along with a version 2.0 EP model. I have modified both the PIO RTL for the model and the example code so that I can generate memory reads and writes from the model to the root port (and generate completions from the root port). The transactions are routed to a Block RAM interface. 

 

I have hooked up the configuration port and enabled the bus master bit of the toot port. Through a configuration write, I also changed the BAR0 address (to 0x6000). In addition, I modified the BAR0 parameter to X"FFFFC000" to indicate that it is a memory region of size 16KB. 

 

I'm able to generate a MEMWR32 from the endpoint to the root port. The data is written to the correct address. However, when sending a MEMRD32 from that address, I observe a 0x25 (fatal error) on the root port's cfg_dstatus register, and I do not see the trn interface on the root port show the read.

 

The only thing I can thing is that the fatal error is from a malformed TLP, but it looks correct to me. The MEMRD32 TLP is as follows:

0x00000001506F010F

0x0000600000000000

 

Any ideas or help would be greatly appreciated.

 

Michael

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
8,777 Views
Registered: ‎04-06-2010

I would double check that the BAR is setup correctly.  Try issuing self config reads through the cfg interface to make sure that your BAR is set as you expected.  I would also ensure that your memory enable bit of the command register is also set.

 

I would also make sure that trn_trem_n is '1' when you assert trn_teof_n.  This makes sure that only the upper DW of trn_td is used as part of the packet.  Otherwise the packet is malformed.

 

Hope this helps.

View solution in original post

4 Replies
Highlighted
Xilinx Employee
Xilinx Employee
8,778 Views
Registered: ‎04-06-2010

I would double check that the BAR is setup correctly.  Try issuing self config reads through the cfg interface to make sure that your BAR is set as you expected.  I would also ensure that your memory enable bit of the command register is also set.

 

I would also make sure that trn_trem_n is '1' when you assert trn_teof_n.  This makes sure that only the upper DW of trn_td is used as part of the packet.  Otherwise the packet is malformed.

 

Hope this helps.

View solution in original post

Highlighted
Visitor
Visitor
7,156 Views
Registered: ‎01-04-2011

Thanks for your reply. Just to be more clear on what I'm seeing- the trn interface on the root port is inactive during the fatal error. The EP model trn interface is active. The xfers happen as follows:

 

  1. Data/Addr/Type/Tag are put on the hacked Tx interface in the PIO_TX_ENGINE of the endpoint

  2. TRN interface on the endpoint changes accordingly and a TLP is visible.

  3. RXP/RXN of the endpoint, and TXN/TXP of the rootport are active.

  4. Fatal error is seen on cfg_status (0x0025).

 

I added a configuration read of the BAR register. I did notice a problem when I set the BAR to 0x6000 (read back as 0x4000), but it read back fine when set to 0x8000. I did set the memory enable bit, but the root port should ignore this bit according to the documentation. The Bus Master bit is set. The bus master bit of the root port is also set.

 

The trn_trem_n of the root port is '1', but the root's trn interface does not change during the error. The trn_trem_n of the root port is 0x0F during the assertion of trn_teof_n, but otherwise it is 0x00.

 

Is it possible to  enable the cfg_dev_control_fatal_err_reporting_en? I don't see that in any of the cfg command registers. It would be nice to have some better idea of the general causes. Also, AER is not supported by the PCIe block, correct?

 

It strikes me as strange that the write from the EP would work, but not the read. I'm not very well versed in the flow control aspect of the PCIe. That is one of the possible causes of the fatal error. (Training error, DLL protocol error, flow control protocol error, malformed TLP, receiver overflow).  

 

If anything else comes to mind, I'd really appreciate any help. Hitting a brick wall here.

 

Thanks, 

Mike

 

0 Kudos
Highlighted
Visitor
Visitor
7,150 Views
Registered: ‎01-04-2011

Thanks again for the reply- you were correct regarding the trn_trem_n signal. I was looking at the PIO_TX_ENGINE signals. There, trn_trem_n is 0x0F. In the pcie_app_v6.vhd file, the 0x0F selects either a '0' or '1' (when trn_trem_n_out is 0x0F). However, the trn_trem_n_out signal was unknown. In the PIO_EP.vhd file, the trn_trem_n signal is driven by tren_trem_n_int, which is unconnected. Instead, I connected it to the PIO_TX_ENGINE.vhd output and life was great.

 

Thanks again! Now, on to the next bug.

 

Michael

0 Kudos
Highlighted
Anonymous
Not applicable
6,497 Views

Hi Michael,

 

I would like to do the same test you did before.  Generated a root port design from Coregen. Then, modified endpoint model to send memory write request. Also, enabled the root port Bus Master bit by writing through configuration port.

 

But, i found that the memory write request (send from endpoint) could not be received at root port. When i read back the bus master register through configuration port, the bus master bit was still off.

 

May i know when did you write the root Bus Master bit and BAR0 address? Was it before link up or after configuration done to endpoint?

 

Thanks,

Ivan

 

 

 

 

 

 

 

0 Kudos