PCI byte enalbes in read cycles

On 2007-09-13, Mindspring Newsgroups <noone@nowhere.com> wrote:
>
> 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).

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
<ben@ben.com>
http://www.ben.com/

PeteS <axkz70@dsl.pipex.com> wrote in message
s-qdnRgwjIWx3HXbRVnytwA@pipex.net...
> 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.

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


> 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.

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

A.

Mindspring Newsgroups <noone@nowhere.com> wrote in message
13eh0g4iju9p4fd@corp.supernews.com...
>
> Bottom line... you are probably worrying about implementing
> complexity that either doesn't matter, or won't give you the
> results that you desire.

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.

A.D. wrote:
> Mindspring Newsgroups <noone@nowhere.com> wrote in message
> 13eh0g4iju9p4fd@corp.supernews.com...
>> Bottom line... you are probably worrying about implementing
>> complexity that either doesn't matter, or won't give you the
>> results that you desire.
> 
> 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.

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