PCI byte enalbes in read cycles

Hi all, I'm implementing a PCI interface in FPGA, but I'm stuck trying to figuring out what happens with byte enables in burst read cycles. Specifications are not clear about this point, saying that if you perform a burst read, byte enable are *usually* all active on all cycles. Even figures always show this situation. This hide the real timing or behaviour of BEs. I mean: are in general BEs referred to the data present on the bus in next clock cycle? (BEs signals are asserted one clock in advance during read cycles...). Or this happens only on the first data cycle?

To be more clear, I'll try to draw what I mean... :-)

This is what specs show for a burst read cycle:

AD -----... BE ...

But if BE need to change during data phase will we have something like this:

AD -----... BE ...

or this:

AD -----... BE < cmd>...

Can anybody enlighten me? :-) Thank you in advance for any answer, and excuse me for this very specific question and for the cross post.

Antonio

Reply to
A.D.
Loading thread data ...

While PCI Express has detailed the use of byte enables for the start and end of burst transactions, the PCI bursts tend to be linear from the start word address. Read Multiple Line bursts are terminated when there's no more data to feed because of cache-line or other memory boundary restrictions. A Read Multiple Line does not request a precise number of words or bytes so byte enables don't make much sense. If you need to read from an odd read boundary, do the byte gating yourself and don't expect the PCI interface to deliver everything you think you need for the partial word that starts you off.

Is your need above and beyond typical use?

Reply to
John_H

From PCI System Architecture, Chapter 8, pg 131...

"PCI permits burst transactions where the byte enables change from one data phase to the next. Furthermore, the initiator may use any byte enable setting, consisting of contiguous or non-contiguous byte enables. During a read transaction, the initiator will typically assert all of the byte enables during each data phase (because burst reads are typically reading a stream of dwords or quadwords), but it may use any combination."

As for timing, the BEs must *NOT* change during a data phase. So although the BEs are asserted before the 1st phase, they don't change until the start of the 2nd phase (which may be while the phase 1 data is still being driven, and before the phase 2 data is valid).

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

Actually, I correct myself, they're not asserted *BEFORE* the 1st phase, but during the 1st phase...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

Ok, so will new BEs for the second data phase be put on the bus starting from clock 3? (I'm considering figure 3.5 of PCI

2.2 specs, that is commonly used and reproduced to show the read cycle).

Antonio

Reply to
A.D.

No! They must not changed until the data has been transferred for the current phase.

From section 3.3.1...

"The C/BE# lines contain the byte enable information for data phase N+1 on the clock following the completion of data phase N."

Since phase 1 ends on clock 4, the BE for phase 2 is valid on clock 5.

Also see fig 3-6...

Regards,

--
Mark McDougall, Engineer
Virtual Logic Pty Ltd, 
 Click to see the full signature
Reply to
Mark McDougall

If there are no side-effects for reading the bytes, you can just return them all. Not many modern memory architectures are going to run faster by reading anything smaller than a 32-bit word, anyway.

You might want to look at the PCI-X docs. My vague recollection is that the pipelining of BE (and a few other signals) changed in PCI-X and there might be something that explains the change so as to enlighten you as to the operation of "old" PCI.

--
Ben Jackson AD7GD

http://www.ben.com/
Reply to
Ben Jackson

Ok, this is what I undestood at first. But suppose you want to use BEs for a simple gating of the byte lanes: you have to do it in a combinational way, or you have to insert a wait state to latch BEs values and then put gated data on the bus on the next clock. Am I wrong? Both these things are quite bad! In the first case you could obtain long propagation delay, in the second case you waste 50% of clock cycles!

Regards, Antonio

Reply to
A.D.

Are you trying to design at target interface or a master interface?

Assuming that you are designing a target interface (your device returns the read data) for then there are two possibilities:

- the act of reading a byte can change the state of your device (read side-effects)

- the act of reading a byte does NOT change the state of your device (no read side-effects)

If the later case (no read side-effects) then you can IGNORE the byte-enables and return all bytes for every data-phase (this is the tyipical case).

An example of a device that has read side-effects would be a device that has a data FIFO rather than a RAM. The act of reading the FIFO removes an entry (thus you have read side-effects). BUT this is a poor example for burst transactions so I doubt that this is applicable to you.

But there is one more thing that you should consider. How is the burst read transaction being generated? Generally, reads from a CPU (i.e. by a device driver) do NOT generate burst read transactions (they generate single DWORD reads) even for memory-mapped devices. In other words, drivers don't generally cannot generate Memory Read Line or Memory Read Multiple transactions UNLESS they use platform-specific (chipset-specific) features AND the device is mapped into a PREFETCHABLE memory address range.

On the other hand.... if you are building a master interface (a device that initiates read transactions) AND you expect the target device to respect random byte enables in each data-phase of a read burst transaction then you should consider the characteristics of the target device you are addressing. Typically, your device will be reading system memory. In this case the memory will ignore the read byte enables and return all bytes (because it does NOT have read side-effects). If your master device is initating peer-to-peer transactions with a device other than system memory then you study the characteristics of that devie to understand its read behavior.

And finally, remember that target devices can simply DISCONNECT after each data-phase and turn a burst transaction into a series of single data-phase transactions. So, even if the master has gone to the lengths of trying to implement use of byte enables in read burst transactions I expect most targets will simple use disconnect to decompose the bust into a series of single data-phase reads so you are UNLIKELY to get any benefit.

Bottom line... you are probably worrying about implementing complexity that either doesn't matter, or won't give you the results that you desire.

TC OR

Reply to
Mindspring Newsgroups

Perhaps you're looking at this the wrong way. Software defines the valid data for each of the bus cycles [when it sets up the data to be transferred] and the hardware takes care of transferring said data.

PCI is *already* a hog of bandwidth for it's transaction system - a few more cycles with invalid data on D[x:n] won't really matter.

Cheers

PeteS

Reply to
PeteS

And if you are the target in this case, you can just align your fifo registers to the PCI bus width to avoid any possible overlap. If you want the possibility of reading them simultaneously, replicate the registers elsewhere in a 32-bit block. Video chips do a lot of this so that when you need to do some operation that sets 3 values, you might find one register word that's the combo of all those three and do the work in a single write.

--
Ben Jackson AD7GD

http://www.ben.com/
Reply to
Ben Jackson

Yes, I know: it is very unlikely that BEs change during a burst read. But specifications say it is still possible...

They matter if you bus power consumption is a concern! :-)

A.

Reply to
A.D.

There are a number of situation in which you can not neglet BEs, for example when dealing with non-prefetchable devices or when you want to minimize bus power consumption (by minimizing bus switching activity). I was considering also this kind of situations for possible enhancement... In effect my current implementation just ignore BEs! :-)

A.

Reply to
A.D.

I thought the problem was for BEs during bursts. There are no bursts for non-prefethcable devices.

Reply to
John_H

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.