Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Peripheral Component Interconnect
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Data phases=== After the address phase (specifically, beginning with the cycle that DEVSEL# goes low) comes a burst of one or more ''data phases''. In all cases, the initiator drives active-low byte select signals on the C/BE[3:0]# lines, but the data on the AD[31:0] may be driven by the initiator (in case of writes) or target (in case of reads). During data phases, the C/BE[3:0]# lines are interpreted as active-low ''byte enables''. In case of a write, the asserted signals indicate which of the four bytes on the AD bus are to be written to the addressed location. In the case of a read, they indicate which bytes the initiator is interested in. For reads, it is always legal to ignore the byte-enable signals and simply return all 32 bits; cacheable memory resources are required to always return 32 valid bits. The byte enables are mainly useful for I/O space accesses where reads have side effects. A data phase with all four C/BE# lines deasserted is explicitly permitted by the PCI standard, and must have no effect on the target other than to advance the address in the burst access in progress. The data phase continues until both parties are ready to complete the transfer and continue to the next data phase. The initiator asserts IRDY# (''initiator ready'') when it no longer needs to wait, while the target asserts TRDY# (''target ready''). Whichever side is providing the data must drive it on the AD bus before asserting its ready signal. Once one of the participants asserts its ready signal, it may not become un-ready or otherwise alter its control signals until the end of the data phase. The data recipient must latch the AD bus each cycle until it sees both IRDY# and TRDY# asserted, which marks the end of the current data phase and indicates that the just-latched data is the word to be transferred. To maintain full burst speed, the data sender then has half a clock cycle after seeing both IRDY# and TRDY# asserted to drive the next word onto the AD bus. <pre style="line-height: 1"> 0_ 1_ 2_ 3_ 4_ 5_ 6_ 7_ 8_ 9_ CLK _/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ ___ _______ ___ ___ ___ AD[31:0] ---<___XXXXXXXXX_______XXXXX___X___X___ (If a write) ___ ___ _______ ___ ___ AD[31:0] ---<___>~~~<XXXXXXXX___X_______X___X___ (If a read) ___ _______________ _______ ___ ___ C/BE[3:0]# ---<___X_______________X_______X___X___ (Must always be valid) _______________ | ___ | | | IRDY# x \_______/ x \___________ ___________________ | | | | TRDY# x x \___________________ ___________ | | | | DEVSEL# \___________________________ ___ | | | | FRAME# \___________________________________ _ _ _ _ _ |_ _ |_ |_ |_ CLK _/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ \_/ 0 1 2 3 4 5 6 7 8 9 </pre> This continues the address cycle illustrated above, assuming a single address cycle with medium DEVSEL, so the target responds in time for clock 3. However, at that time, neither side is ready to transfer data. For clock 4, the initiator is ready, but the target is not. On clock 5, both are ready, and a data transfer takes place (as indicated by the vertical lines). For clock 6, the target is ready to transfer, but the initiator is not. On clock 7, the initiator becomes ready, and data is transferred. For clocks 8 and 9, both sides remain ready to transfer data, and data is transferred at the maximum possible rate (32 bits per clock cycle). In case of a read, clock 2 is reserved for turning around the AD bus, so the target is not permitted to drive data on the bus even if it is capable of fast DEVSEL. ====Fast DEVSEL# on reads==== A target that supports fast DEVSEL could in theory begin responding to a read on the cycle after the address is presented. This cycle is, however, reserved for AD bus turnaround. Thus, a target may not drive the AD bus (and thus may not assert TRDY#) on the second cycle of a transaction. Most targets will not be this fast and will not need any special logic to enforce this condition.
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Peripheral Component Interconnect
(section)
Add topic