cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
2,231 Views
Registered: ‎11-26-2016

PCIe Tandem Stage 1 - Logic Register Access

Jump to solution

Hi,

 

I am using a Kintex Ultrascale FPGA with Gen3 Integrated PCI Block in Tandem Configuration. According to pg156:

"Before stage 2 is loaded, TLP requests return unsupported requests (URs)." What I need is a way for the Host to set a register in the logic from the PCIe Register Space available in Stage 1. How can this be done?

 

I will be greatful for any help.

0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
2,638 Views
Registered: ‎12-10-2013

HI @so-lli1,

 

Can you clarify whether you are using UltraScale or UltraScale+ architecture? 

 

You need to respond to all requests in the documented address ranges, and place your capability at the base of the documented range.  The "Next Cap" Pointers are set based on the address range, and point to the base address.  If it is an address you aren't implementing (for example above your VSEC), then you need to respond with all 0 to read requests.  The core is not "protocol aware" in this area, and all CfgRds must be responded to.

 

For Ultrascale, the range needed to be implemented is 0x120-3FF (Dword address).    (See documentation on the cfg_ext_read_received)

 

For Ultrascale+, the range is 0x120-0x13F (Dword address)

 

So to summarize:

- Your VSEC capability needs to start a 0x480 (Byte address) - as that is where all the next capability pointers are showing in configuration space.

- You need to implement the full range, though you can just return 0x0000_0000 for everything beyond your capability addresses

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

7 Replies
Highlighted
Xilinx Employee
Xilinx Employee
2,176 Views
Registered: ‎12-10-2013

Hi @so-lli1,

 

For the Integrated Block IP, which register are you targeting?   The block can very much handle Configuration Read / Write transactions during stage one, so you can talk to Configuration Space. 

 

The TLP requests that will respond with UR are the Memory Requests sent to the BARs during this time.  The BAR / Memory accesses are only enabled during Stage 2.

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Highlighted
Adventurer
Adventurer
2,162 Views
Registered: ‎11-26-2016

Hi @bethe,

 

My initial thought was to enable PCI Express Extended Configuration Space (User Defined Configuration Capabilities within the PCIe Core). Is this the correct approach? If a User Defined Configuration Capabilities register is the way to go, how can this be implemented?

 

Thank you very much for clearifying the BAR / Memory access case.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,146 Views
Registered: ‎12-10-2013

Hi @so-lli1,

 

Using the Integrated Block, in the Advanced Mode - Extd. Cap tabs, you can find "Enabled Extended Configuration Space".  This will add an interface to the core where Configuration Rd/Wr to certain extended registers will be presented to user logic.  The Product Guide (PG156 for US, PG213 for US+) details the area of configuration space that will become available to you, and the ports that will be created.  The Configuration Space linked list will also be update to point to this capability space. 

 

You could add user logic that then received and responded via the Extended interface and register those interchanges.  These should all be placed in the Stage 1 PBlock - which means you want to keep it fairly small and simple.  But it should serve the purpose. 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------
Highlighted
Adventurer
Adventurer
2,093 Views
Registered: ‎11-26-2016

Hi @bethe,

 


You could add user logic that then received and responded via the Extended interface and register those interchanges. 


And this is where I have a little bit of trouble. The only information I could find about the ext_cfg_* interface is pg156, page 57. This describes the interface signals, but not how to actually create your own config space.

 

I wrote some logic, that responds to the addresses 0x100-0x107 (PCIe bytewise addressing 0x400-0x41C). The first 4bytes represent the VSEC Header and the second 4bytes the Vendor Specific Header with the VSEC Length encoded in Bit 31:20. These are then followed by 6 user registers. According to PCI_Express_Base_Specification 7.19.2, the VSEC Length indicates the number of bytes in the entire VSEC structure ((6 user registers + 2 Header) * 4bytes/reg = 0x20).

 

With this implementation, the system is not even booting. It seems like the Interface is waiting for more data because read_received is set to an address above 0x107 which I don't handle.

 

Am I missing something here?

 

Edit: For clarification, the screenshot below shows the logic behavior when reading the continuous register space of the VSEC area in simulation.

 

Capture.PNG
0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
2,639 Views
Registered: ‎12-10-2013

HI @so-lli1,

 

Can you clarify whether you are using UltraScale or UltraScale+ architecture? 

 

You need to respond to all requests in the documented address ranges, and place your capability at the base of the documented range.  The "Next Cap" Pointers are set based on the address range, and point to the base address.  If it is an address you aren't implementing (for example above your VSEC), then you need to respond with all 0 to read requests.  The core is not "protocol aware" in this area, and all CfgRds must be responded to.

 

For Ultrascale, the range needed to be implemented is 0x120-3FF (Dword address).    (See documentation on the cfg_ext_read_received)

 

For Ultrascale+, the range is 0x120-0x13F (Dword address)

 

So to summarize:

- Your VSEC capability needs to start a 0x480 (Byte address) - as that is where all the next capability pointers are showing in configuration space.

- You need to implement the full range, though you can just return 0x0000_0000 for everything beyond your capability addresses

 

 

-------------------------------------------------------------------------
Don’t forget to reply, kudo, and accept as solution.
-------------------------------------------------------------------------

View solution in original post

Highlighted
Adventurer
Adventurer
2,054 Views
Registered: ‎11-26-2016

Hi @bethe,

 



 

For Ultrascale, the range needed to be implemented is 0x120-3FF (Dword address).    (See documentation on the cfg_ext_read_received)

 

 


This is strange (pg156). I am using the IP version 3.4 which describes the address range 0x100-0x3ff. Only the datasheet of version 4.4 shows 0x120-0x3ff. The version history does not say anything about a corrected error, therefore I am not sure if 0x100 or 0x120 is correct in my case.

 


 

If it is an address you aren't implementing (for example above your VSEC), then you need to respond with all 0 to read requests.  The core is not "protocol aware" in this area, and all CfgRds must be responded to.

 

 


Therefore cfg_ext_read_data_valid also needs to be asserted. I guess this is missing in the documentation.

 

EDIT: I used 0x100 as a starting address for the VSEC in the 4.3 IP and after responding to all addresses within the range with cfg_ext_read_data_valid, everything works as expected.

 

@bethe Thank you very much for your support.

0 Kudos
Highlighted
Newbie
Newbie
880 Views
Registered: ‎02-13-2019

Can you send me the first part of the code you connect to the extende configuration ports?

Somehow I don't see the information in lspci and I don't knwo why, perhaps it has something to do with the data.

0 Kudos