PCI calculation

No, yes. Maybe. ;-) MAX_LAT tells the arbiter the maximum latency this master (these registers are meaningless for a target) requires. It describes how fast this device wants service after it asserts REQ#. The bus arbiter uses this information to adjust priority. This doesn't mean that the device will ask for service every MAX_LAT time, only that once it does it wants to be serviced within this time.

MIN_GNT is a hint to PCI configuration indicating the burst length this device wants. This information is useful to set the bus master latency timers. Basically, this master doesn't want to be terminated within this time period. This doesn't mean that the master will always use this burst length, or that it will never do more if allowed.

These values don't translate directly into max (or min) bandwidth because the device _could_ keep the bus forever (if no one else issues a GNT#). OTOH, this master may never issue a REQ# so may not use any bandwidth. These only indicate than when the device issues a REQ# that it wants to be serviced in MAX_LAT time and once it gets its GNT# it would like to not have GNT# dropped for MIN_GNT time.

--
  Keith

Keith:

Thanks for your reply.

I have some questions.

####### It describes how fast this device wants service after it asserts REQ#. The bus arbiter uses this information to adjust priority. This doesn't mean

that the device will ask for service every MAX_LAT time, only that once it does it wants to be serviced within this time. ########

1) Lets suppose the bus is making the peripheral wait every MAX_LAT. Will the device be serviced every MAX_LAT + MIN_GNT, or just every MAX_LAT? In other words, when you say "how fast the device wants the server after it asserts REQ#", is this after a transmission period of GNT ends (MAX_LAT + MIN_GNT) or does the MIN_GNT fall within every MAX_LAT?

2) I'm confused by the throughput calculations of the PCI bus. 33mhz

• 32 bits = 1,056,000,000bps. Where does the 133mbps number come from? What is the overhead here?

Wrong number.... The number is 133MBps. Notice the capitals. 133 million bytes per second.

4 bytes, 33 million transfers. Overhead varies with the chipset. Typically a minimum of perhaps 90MBps, and some DMA cards, on some well behaved chipsets, can have figures up to perhaps 120MBps.

Best Wishes

If someone else is demanding service the arbiter will remove GNT# after MIN_GNT and give GNT# to someone else until the next MAX_LAT expires. If there is noone else demanding service it'll allow your device to keep its GNT# until somone else demands service. Note that MAX_LAT and MIN_GNT are only suggestions to the arbiter. It's teh arbiter that determines these things with the latency timers. It's certainly possible that there isn't enough bandwidth to service all initiators MIN_GNT.

No, it's really got little to do with MIN_GNT. ALL MAX_LAT is doing is suggesting to the arbiter that when it wants service it needs it within MAX_LAT or perhaps something bad will happen.

IOW, these registers are simply telling the arbiter that every time the device asserts REQ# it needs service (GNT#) within MAX_LAT and may keep the bus for MIN_GNT, so set the latency timers and arbitration priority accordingly. It's the latency timers in the arbiter that run the show.

As Roger said above, it's four bytes (32bits) times 33MHz, or

133MegaBytes per second.

--
  Keith

Keith:

######### No, it's really got little to do with MIN_GNT. ALL MAX_LAT is doing is suggesting to the arbiter that when it wants service it needs it within MAX_LAT or perhaps something bad will happen.

IOW, these registers are simply telling the arbiter that every time the

device asserts REQ# it needs service (GNT#) within MAX_LAT and may keep

the bus for MIN_GNT, so set the latency timers and arbitration priority

accordingly. It's the latency timers in the arbiter that run the show.

#########

Whether or not the device gets bus service "at least" MAX_LAT is where I'm foggy.

1) When does the device de-assert REQ? At the moment it is granted the bus? If this is the case, then it is always the possible the device will REQ for the bus again, even while the device currently has the bus seized. In this case, if the arbiter takes the bus away at the end of MIN_GNT and hands it over to another device, then the answer to my question is "MAX_LAT." The device is indicating it wants the bus exactly every MAX_LAT.

2) But if the device does not or can not (by rule of PCI spec) assert REQ while it already has control of the bus, this means that the device desires not to wait more than MAX_LAT *between* MIN_GNT (between transimissions). Then in this case the answer is "MIN_GNT + MAX_LAT"

I'm aware that these are only suggested values. However, they are chosen by the vendor for a reason I'm guessing so I'm wondering what sort of throughput the vendor is hoping for by setting these values. I know that in the real world a lot of BIOSes or OSes don't care anyway.

Again, thanks for your patience. Any more illumination anyone might have on this would be greatly appreciated.

Ugh.. I should have edited that before I posted it.

In #1 I mean "the device is indicating it wants the bus *at least* every MAX_LAT.

I'm wondering if the MAX_LAT is occuring between the (a) *end* of the last transmission and the beginning of the next, or (b) the *beginning* of the last transmission to the beginning of the next.

Please use customary posting protocol...

MAX_LAT is *only* a sugggestion to the arbiter that this is the "Maximum Latency" that this device can tollerate. It's up to the arbiter to balance this aginst the needs of other devices. ...or not (as I suspect is the usual case)

When it has something interesting to do that requires the bus.

No, it gets GNT#, *then it can have the bus. MAX_LAT is a suggestion to the arbiter that this device needs service from REQ# to GNT# of this time. It's up to the arbiter and it's latency timers to make this happen (if it does).

Nope. It cannot request the bus again while it already has it. REQ# is held active as long as the device requires the bus, or until it is forced off the bus by the arbiter dropping GNT# (after its latency timer has expired). If the initiator drops REQ# it's given up the bus and must re-arbitrate for it. Thus, it's meaningless to for a GNT# to be on top of a GNT#. GNT# is a level.

*IF* the device needs service again, yes. It *should* be given back the bus after it asserts REQ#, within MAX_LAT. ...if the arbiter really cared about MAX_LAT (don't count on it in PC class stuff) and it's not out of resources.

It can't assert somehtin it's already asserted. If it drops it to assert it again, it may have to wait another MAX_LAT (or longer). A device can't assert what it already has.

Just because it has MIN_GNT, doesn't mean that it will *always* use this entire time. You're assuming too much from these numbers (primarly that anyone is listening to them ;).

Exactly! Now we're getting somehwere! ;-) Might I suggest getting a copy of the spec from

(it's *not* free for non SIG members) *AND* a copy of "PCI System Architecture" from (either as an eBook or dead tree). The MindShare book is *highly* recommended and not terribly expensive either.

Not a problem. It's good to dust the cobwebs out at times. ;-)

--
  Keith

It has to relenquish the bus before it can request it again. Gotta drop REQ# and wait for GNT# to drop before it can re-assert REQ#. MAX_LAT would then start over, no matter how much of MIN_GNT time was used.

As soon as the device need service it asserts REQ#. From *THAT* time, MAX_LAT matters (assuming anyone cares about this value). It doesn't matter how long after the last transmission has occured. When _this_ transmission is requested, MAX_LAT is the suggestion telling the arbiter how long it has to respond.

No, it's from the time the initiator knows (request) that *this* transmission is necessary to the time it's allowed (grant) to transmit (on a good day).

It's got nothing to with what happens within a GNT# cycle or an idle cycle. If the bus is idle the initiator gets a GNT# immediately after a REQ#.

--
  Keith