UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Adventurer
Adventurer
11,229 Views
Registered: ‎02-06-2012

Incorrect assignment of 64bit BAR addresses

Hello,

 

I've encountered a problem when using PCIe core with specific BARs settings.

Bug happens bot in simulation and real systems. Problem spotted on Artix XC7A200T chip, ISE 14.6, core version 1.10.

I've got 3 64-bit BARs:

BAR0 - 1KByte (registers and stuff)

BAR2 - 512Mbyte (DDR memory), prefetchable

BAR4 - 4GBytes (Wishbone extension modules)

 

When trying to enumerate design in x86 PC with Linux OS:

[root@tms]# dmesg | grep 0000:08:00
[359240.057465] pci 0000:08:00.0: [10ee:7014] type 00 class 0x058000
[359240.057518] pci 0000:08:00.0: reg 10: [mem 0x00000000-0x000003ff 64bit]
[359240.057556] pci 0000:08:00.0: reg 18: [mem 0x00000000-0x1fffffff 64bit pref]
[359240.057592] pci 0000:08:00.0: reg 20: [mem 0x00000000-0xffffffff 64bit]
[359240.057729] pci 0000:08:00.0: PME# supported from D0 D1 D2 D3hot
[359240.057740] pci 0000:08:00.0: PME# disabled
[359240.071059] pci 0000:08:00.0: disabling BAR 4: [mem 0x00000000-0xffffffff 64bit] (bad alignment 0x100000000)
[359240.072153] pci 0000:08:00.0: BAR 2: assigned [mem 0xc0000000-0xdfffffff 64bit pref]
[359240.072181] pci 0000:08:00.0: BAR 2: set to [mem 0xc0000000-0xdfffffff 64bit pref] (PCI address [0xc0000000-0xdfffffff])
[359240.072187] pci 0000:08:00.0: BAR 0: assigned [mem 0xb0000000-0xb00003ff 64bit]
[359240.072213] pci 0000:08:00.0: BAR 0: set to [mem 0xb0000000-0xb00003ff 64bit] (PCI address [0xb0000000-0xb00003ff])

and relevant lspci output:
        Region 0: Memory at b0000000 (64-bit, non-prefetchable) [size=1K]
        Region 2: Memory at c0000000 (64-bit, prefetchable) [size=512M]
        Region 4: Memory at <unassigned> (64-bit, non-prefetchable) [size=4G]

I think the same bug can be spotted in simulation (with Questa).

Look at BAR0,BAR1 and BAR4,BAR5 spaces. These two 64bit BARs get exactly the same addresses!

# [70435000.0 ps] PCI EXPRESS BAR MEMORY/IO MAPPING PROCESS BEGUN...
# 	BAR 0: VALUE = 00000000 RANGE = fffffc04 TYPE =  MEM64 MAPPED
# 	BAR 1: VALUE = 00000001 RANGE = ffffffff TYPE =      DISABLED
# 	BAR 2: VALUE = 20000000 RANGE = e000000c TYPE =  MEM64 MAPPED
# 	BAR 3: VALUE = 00000001 RANGE = ffffffff TYPE =      DISABLED
# 	BAR 4: VALUE = 00000000 RANGE = 00000004 TYPE =  MEM64 MAPPED
# 	BAR 5: VALUE = 00000001 RANGE = ffffffff TYPE =      DISABLED
# 	EROM : VALUE = 00000000 RANGE = 00000000 TYPE =      DISABLED

 Which of course propagates later in simulation. When I try to write one of these BARs, TLP also hits another one:

 

Can anyone comment on this problem? Is it a PCIe core bug? Or maybe PCIe core simply doesn't support BARs larger than 2 gigabytes, even when using 64 bit addressing?

Attached core XCO file.

Tags (3)
0 Kudos
1 Reply
Contributor
Contributor
11,207 Views
Registered: ‎02-13-2009

Re: Incorrect assignment of 64bit BAR addresses


BAR4 - 4GBytes (Wishbone extension modules)
Most likely your BIOS does not allow such a big memory space BAR. Actually I have never seen a real PCIe device with more than 512MB mapped into memory space. Why would you want to do this? If you think to have a reason for that, check again whether your application really requires this amount of memory being always accessible at the same time or if you could also handle this with a paging mechanism.

I think the same bug can be spotted in simulation (with Questa).

Look at BAR0,BAR1 and BAR4,BAR5 spaces. These two 64bit BARs get exactly the same addresses!


This might be a bug in the BAR initialization code of the simulation. most likely this also has not been tested with such big memory regions. Although requesting more than 2GB seems to be not explicitly forbidden by the spec, I would suggest to stick to this limit for compatibility reasons, since this is the maximum which can be supported by a system without 64-bit addressing capabilities.
Regards
Martin
0 Kudos