How is the device determined in PCI enumeration? (bus/device/function)
up vote
8
down vote
favorite
I am confused about PCI Bus/Device/Function enumeration. Looking at the Wikipedia page for PCI configuration, I see that for a given bus, the master will request vendor ID and device ID for all devices using function 0. If all 0xFFs are returned, then no device is there, and enumeration moves on. If a valid device ID and vendor ID are found, then there is a PCI unit there and it will be enumerated. I am unsure how the device in the bus.device.function is determined.
For example, let's say I have a CPU with one PCI bus and one PCI peripheral attached to it. I understand that the CPU will look on bus 0 (by default) and will check for all device numbers looking at function 0. How does the peripheral's device number get determined?
pci bus
migrated from stackoverflow.com Apr 3 '16 at 12:23
This question came from our site for professional and enthusiast programmers.
add a comment |
up vote
8
down vote
favorite
I am confused about PCI Bus/Device/Function enumeration. Looking at the Wikipedia page for PCI configuration, I see that for a given bus, the master will request vendor ID and device ID for all devices using function 0. If all 0xFFs are returned, then no device is there, and enumeration moves on. If a valid device ID and vendor ID are found, then there is a PCI unit there and it will be enumerated. I am unsure how the device in the bus.device.function is determined.
For example, let's say I have a CPU with one PCI bus and one PCI peripheral attached to it. I understand that the CPU will look on bus 0 (by default) and will check for all device numbers looking at function 0. How does the peripheral's device number get determined?
pci bus
migrated from stackoverflow.com Apr 3 '16 at 12:23
This question came from our site for professional and enthusiast programmers.
add a comment |
up vote
8
down vote
favorite
up vote
8
down vote
favorite
I am confused about PCI Bus/Device/Function enumeration. Looking at the Wikipedia page for PCI configuration, I see that for a given bus, the master will request vendor ID and device ID for all devices using function 0. If all 0xFFs are returned, then no device is there, and enumeration moves on. If a valid device ID and vendor ID are found, then there is a PCI unit there and it will be enumerated. I am unsure how the device in the bus.device.function is determined.
For example, let's say I have a CPU with one PCI bus and one PCI peripheral attached to it. I understand that the CPU will look on bus 0 (by default) and will check for all device numbers looking at function 0. How does the peripheral's device number get determined?
pci bus
I am confused about PCI Bus/Device/Function enumeration. Looking at the Wikipedia page for PCI configuration, I see that for a given bus, the master will request vendor ID and device ID for all devices using function 0. If all 0xFFs are returned, then no device is there, and enumeration moves on. If a valid device ID and vendor ID are found, then there is a PCI unit there and it will be enumerated. I am unsure how the device in the bus.device.function is determined.
For example, let's say I have a CPU with one PCI bus and one PCI peripheral attached to it. I understand that the CPU will look on bus 0 (by default) and will check for all device numbers looking at function 0. How does the peripheral's device number get determined?
pci bus
pci bus
asked Mar 24 '16 at 4:00
simple_symbols
78114
78114
migrated from stackoverflow.com Apr 3 '16 at 12:23
This question came from our site for professional and enthusiast programmers.
migrated from stackoverflow.com Apr 3 '16 at 12:23
This question came from our site for professional and enthusiast programmers.
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
6
down vote
accepted
In the original PCI framework ("Conventional PCI") and in PCI-X as well, devices corresponded to "slots", each with its own connectors attached to the same parallel bus. Each slot had a unique ID pin that was asserted during enumeration. The enumeration was essentially asking (for each slot): "Hey, is there anything present in this slot?" The device responded by driving data onto the bus in response to this signal. Lack of response meant no device.
A device could also be a "bridge" which meant that it formed a subordinate bus. That bus would have a separate ID (assigned from the upstream), and would have its own set of slots that were enumerated independently.
PCI-Express (PCIe) is totally different. PCIe isn't really a bus -- as in a resource shared among devices; instead each device has its own individual point-to-point serial connection to its upstream device (and to any downstream devices -- and if it has downstream devices, that means it is functioning as a bridge too). Think of PCIe like a LAN. Each bridge is analogous to a switch, that has a bunch of ports connected to other devices. The other devices may be terminal devices, or they might be other switches (i.e. PCIe bridges).
PCIe was designed in such a way that its conceptual framework and addressing (and hence the behavior provided to software) is compatible with PCI and PCI-X. The implementation though is completely different. In enumerating devices, for example, since it's point-to-point, the only question that needs to be determined at each point in the enumeration is "anything there?" Since each device has its own independent set of wires, the device IDs are essentially all hard-coded (hence each bridge, including the top-level "root complex", tells each device what its device ID will be).
In all cases, the "function" part of the bus/device/function is handled strictly within the peripheral. For example, a dual port NIC controller will often have two functions, one for each port. They can be configured and operated independently, but the data path from CPU to function is the same for both.
1
The answer is a bit confusing: 1) in PCI "device number" actually means "slot number" (and it makes sense), 2) you say "PCIe is totally different" and "since each device has its own independent set of wires, the device IDs are essentially all hard-coded", which means the set of wires (= the slot) has the ID hard-coded to it, thus it is the same as in PCI. Now, the question is when the "hard-coding" happens? The switches/bridges re-assign the IDs on reset?
– xealits
Apr 12 '17 at 14:23
2
Yeah. That could be worded better. The point is that in PCI, the card is on a shared bus but "knows" what slot it's in and only responds when its slot-specific pin is asserted. In PCIe, the bridge has N different sets of "wires". So the bridge device has a discrete slot number for every set of wires. From the bridge's point of view, that slot has a definite number; it only has to determine whether there's something there. The card itself doesn't know what slot it's in. Once the bridge determines there's something there, it then tells that device what its slot number is.
– Gil Hamilton
Apr 12 '17 at 16:36
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
6
down vote
accepted
In the original PCI framework ("Conventional PCI") and in PCI-X as well, devices corresponded to "slots", each with its own connectors attached to the same parallel bus. Each slot had a unique ID pin that was asserted during enumeration. The enumeration was essentially asking (for each slot): "Hey, is there anything present in this slot?" The device responded by driving data onto the bus in response to this signal. Lack of response meant no device.
A device could also be a "bridge" which meant that it formed a subordinate bus. That bus would have a separate ID (assigned from the upstream), and would have its own set of slots that were enumerated independently.
PCI-Express (PCIe) is totally different. PCIe isn't really a bus -- as in a resource shared among devices; instead each device has its own individual point-to-point serial connection to its upstream device (and to any downstream devices -- and if it has downstream devices, that means it is functioning as a bridge too). Think of PCIe like a LAN. Each bridge is analogous to a switch, that has a bunch of ports connected to other devices. The other devices may be terminal devices, or they might be other switches (i.e. PCIe bridges).
PCIe was designed in such a way that its conceptual framework and addressing (and hence the behavior provided to software) is compatible with PCI and PCI-X. The implementation though is completely different. In enumerating devices, for example, since it's point-to-point, the only question that needs to be determined at each point in the enumeration is "anything there?" Since each device has its own independent set of wires, the device IDs are essentially all hard-coded (hence each bridge, including the top-level "root complex", tells each device what its device ID will be).
In all cases, the "function" part of the bus/device/function is handled strictly within the peripheral. For example, a dual port NIC controller will often have two functions, one for each port. They can be configured and operated independently, but the data path from CPU to function is the same for both.
1
The answer is a bit confusing: 1) in PCI "device number" actually means "slot number" (and it makes sense), 2) you say "PCIe is totally different" and "since each device has its own independent set of wires, the device IDs are essentially all hard-coded", which means the set of wires (= the slot) has the ID hard-coded to it, thus it is the same as in PCI. Now, the question is when the "hard-coding" happens? The switches/bridges re-assign the IDs on reset?
– xealits
Apr 12 '17 at 14:23
2
Yeah. That could be worded better. The point is that in PCI, the card is on a shared bus but "knows" what slot it's in and only responds when its slot-specific pin is asserted. In PCIe, the bridge has N different sets of "wires". So the bridge device has a discrete slot number for every set of wires. From the bridge's point of view, that slot has a definite number; it only has to determine whether there's something there. The card itself doesn't know what slot it's in. Once the bridge determines there's something there, it then tells that device what its slot number is.
– Gil Hamilton
Apr 12 '17 at 16:36
add a comment |
up vote
6
down vote
accepted
In the original PCI framework ("Conventional PCI") and in PCI-X as well, devices corresponded to "slots", each with its own connectors attached to the same parallel bus. Each slot had a unique ID pin that was asserted during enumeration. The enumeration was essentially asking (for each slot): "Hey, is there anything present in this slot?" The device responded by driving data onto the bus in response to this signal. Lack of response meant no device.
A device could also be a "bridge" which meant that it formed a subordinate bus. That bus would have a separate ID (assigned from the upstream), and would have its own set of slots that were enumerated independently.
PCI-Express (PCIe) is totally different. PCIe isn't really a bus -- as in a resource shared among devices; instead each device has its own individual point-to-point serial connection to its upstream device (and to any downstream devices -- and if it has downstream devices, that means it is functioning as a bridge too). Think of PCIe like a LAN. Each bridge is analogous to a switch, that has a bunch of ports connected to other devices. The other devices may be terminal devices, or they might be other switches (i.e. PCIe bridges).
PCIe was designed in such a way that its conceptual framework and addressing (and hence the behavior provided to software) is compatible with PCI and PCI-X. The implementation though is completely different. In enumerating devices, for example, since it's point-to-point, the only question that needs to be determined at each point in the enumeration is "anything there?" Since each device has its own independent set of wires, the device IDs are essentially all hard-coded (hence each bridge, including the top-level "root complex", tells each device what its device ID will be).
In all cases, the "function" part of the bus/device/function is handled strictly within the peripheral. For example, a dual port NIC controller will often have two functions, one for each port. They can be configured and operated independently, but the data path from CPU to function is the same for both.
1
The answer is a bit confusing: 1) in PCI "device number" actually means "slot number" (and it makes sense), 2) you say "PCIe is totally different" and "since each device has its own independent set of wires, the device IDs are essentially all hard-coded", which means the set of wires (= the slot) has the ID hard-coded to it, thus it is the same as in PCI. Now, the question is when the "hard-coding" happens? The switches/bridges re-assign the IDs on reset?
– xealits
Apr 12 '17 at 14:23
2
Yeah. That could be worded better. The point is that in PCI, the card is on a shared bus but "knows" what slot it's in and only responds when its slot-specific pin is asserted. In PCIe, the bridge has N different sets of "wires". So the bridge device has a discrete slot number for every set of wires. From the bridge's point of view, that slot has a definite number; it only has to determine whether there's something there. The card itself doesn't know what slot it's in. Once the bridge determines there's something there, it then tells that device what its slot number is.
– Gil Hamilton
Apr 12 '17 at 16:36
add a comment |
up vote
6
down vote
accepted
up vote
6
down vote
accepted
In the original PCI framework ("Conventional PCI") and in PCI-X as well, devices corresponded to "slots", each with its own connectors attached to the same parallel bus. Each slot had a unique ID pin that was asserted during enumeration. The enumeration was essentially asking (for each slot): "Hey, is there anything present in this slot?" The device responded by driving data onto the bus in response to this signal. Lack of response meant no device.
A device could also be a "bridge" which meant that it formed a subordinate bus. That bus would have a separate ID (assigned from the upstream), and would have its own set of slots that were enumerated independently.
PCI-Express (PCIe) is totally different. PCIe isn't really a bus -- as in a resource shared among devices; instead each device has its own individual point-to-point serial connection to its upstream device (and to any downstream devices -- and if it has downstream devices, that means it is functioning as a bridge too). Think of PCIe like a LAN. Each bridge is analogous to a switch, that has a bunch of ports connected to other devices. The other devices may be terminal devices, or they might be other switches (i.e. PCIe bridges).
PCIe was designed in such a way that its conceptual framework and addressing (and hence the behavior provided to software) is compatible with PCI and PCI-X. The implementation though is completely different. In enumerating devices, for example, since it's point-to-point, the only question that needs to be determined at each point in the enumeration is "anything there?" Since each device has its own independent set of wires, the device IDs are essentially all hard-coded (hence each bridge, including the top-level "root complex", tells each device what its device ID will be).
In all cases, the "function" part of the bus/device/function is handled strictly within the peripheral. For example, a dual port NIC controller will often have two functions, one for each port. They can be configured and operated independently, but the data path from CPU to function is the same for both.
In the original PCI framework ("Conventional PCI") and in PCI-X as well, devices corresponded to "slots", each with its own connectors attached to the same parallel bus. Each slot had a unique ID pin that was asserted during enumeration. The enumeration was essentially asking (for each slot): "Hey, is there anything present in this slot?" The device responded by driving data onto the bus in response to this signal. Lack of response meant no device.
A device could also be a "bridge" which meant that it formed a subordinate bus. That bus would have a separate ID (assigned from the upstream), and would have its own set of slots that were enumerated independently.
PCI-Express (PCIe) is totally different. PCIe isn't really a bus -- as in a resource shared among devices; instead each device has its own individual point-to-point serial connection to its upstream device (and to any downstream devices -- and if it has downstream devices, that means it is functioning as a bridge too). Think of PCIe like a LAN. Each bridge is analogous to a switch, that has a bunch of ports connected to other devices. The other devices may be terminal devices, or they might be other switches (i.e. PCIe bridges).
PCIe was designed in such a way that its conceptual framework and addressing (and hence the behavior provided to software) is compatible with PCI and PCI-X. The implementation though is completely different. In enumerating devices, for example, since it's point-to-point, the only question that needs to be determined at each point in the enumeration is "anything there?" Since each device has its own independent set of wires, the device IDs are essentially all hard-coded (hence each bridge, including the top-level "root complex", tells each device what its device ID will be).
In all cases, the "function" part of the bus/device/function is handled strictly within the peripheral. For example, a dual port NIC controller will often have two functions, one for each port. They can be configured and operated independently, but the data path from CPU to function is the same for both.
answered Mar 30 '16 at 12:48
Gil Hamilton
1763
1763
1
The answer is a bit confusing: 1) in PCI "device number" actually means "slot number" (and it makes sense), 2) you say "PCIe is totally different" and "since each device has its own independent set of wires, the device IDs are essentially all hard-coded", which means the set of wires (= the slot) has the ID hard-coded to it, thus it is the same as in PCI. Now, the question is when the "hard-coding" happens? The switches/bridges re-assign the IDs on reset?
– xealits
Apr 12 '17 at 14:23
2
Yeah. That could be worded better. The point is that in PCI, the card is on a shared bus but "knows" what slot it's in and only responds when its slot-specific pin is asserted. In PCIe, the bridge has N different sets of "wires". So the bridge device has a discrete slot number for every set of wires. From the bridge's point of view, that slot has a definite number; it only has to determine whether there's something there. The card itself doesn't know what slot it's in. Once the bridge determines there's something there, it then tells that device what its slot number is.
– Gil Hamilton
Apr 12 '17 at 16:36
add a comment |
1
The answer is a bit confusing: 1) in PCI "device number" actually means "slot number" (and it makes sense), 2) you say "PCIe is totally different" and "since each device has its own independent set of wires, the device IDs are essentially all hard-coded", which means the set of wires (= the slot) has the ID hard-coded to it, thus it is the same as in PCI. Now, the question is when the "hard-coding" happens? The switches/bridges re-assign the IDs on reset?
– xealits
Apr 12 '17 at 14:23
2
Yeah. That could be worded better. The point is that in PCI, the card is on a shared bus but "knows" what slot it's in and only responds when its slot-specific pin is asserted. In PCIe, the bridge has N different sets of "wires". So the bridge device has a discrete slot number for every set of wires. From the bridge's point of view, that slot has a definite number; it only has to determine whether there's something there. The card itself doesn't know what slot it's in. Once the bridge determines there's something there, it then tells that device what its slot number is.
– Gil Hamilton
Apr 12 '17 at 16:36
1
1
The answer is a bit confusing: 1) in PCI "device number" actually means "slot number" (and it makes sense), 2) you say "PCIe is totally different" and "since each device has its own independent set of wires, the device IDs are essentially all hard-coded", which means the set of wires (= the slot) has the ID hard-coded to it, thus it is the same as in PCI. Now, the question is when the "hard-coding" happens? The switches/bridges re-assign the IDs on reset?
– xealits
Apr 12 '17 at 14:23
The answer is a bit confusing: 1) in PCI "device number" actually means "slot number" (and it makes sense), 2) you say "PCIe is totally different" and "since each device has its own independent set of wires, the device IDs are essentially all hard-coded", which means the set of wires (= the slot) has the ID hard-coded to it, thus it is the same as in PCI. Now, the question is when the "hard-coding" happens? The switches/bridges re-assign the IDs on reset?
– xealits
Apr 12 '17 at 14:23
2
2
Yeah. That could be worded better. The point is that in PCI, the card is on a shared bus but "knows" what slot it's in and only responds when its slot-specific pin is asserted. In PCIe, the bridge has N different sets of "wires". So the bridge device has a discrete slot number for every set of wires. From the bridge's point of view, that slot has a definite number; it only has to determine whether there's something there. The card itself doesn't know what slot it's in. Once the bridge determines there's something there, it then tells that device what its slot number is.
– Gil Hamilton
Apr 12 '17 at 16:36
Yeah. That could be worded better. The point is that in PCI, the card is on a shared bus but "knows" what slot it's in and only responds when its slot-specific pin is asserted. In PCIe, the bridge has N different sets of "wires". So the bridge device has a discrete slot number for every set of wires. From the bridge's point of view, that slot has a definite number; it only has to determine whether there's something there. The card itself doesn't know what slot it's in. Once the bridge determines there's something there, it then tells that device what its slot number is.
– Gil Hamilton
Apr 12 '17 at 16:36
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1060808%2fhow-is-the-device-determined-in-pci-enumeration-bus-device-function%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown