1. Home
  2. Electronics Design
  3. PCI arbiter doubts

PCI arbiter doubts

Hi all,

I have some basic doubts on PCI arbiter.

1)how is the "framen" controlled -- i guess it is a shared resource on the PCI bus wher all the devices sitting on the PCI bus have access to it. 2)If a "request" is received from a device on PCI bus ,should the "grant" be issued immediately or should the PCI arbiter wait until the "framen" is dropped (asserted). 3)If a "request" is received from a device on PCI bus , but the "framen" is not dropped at all.how should the PCI arbiter react to this condition.

Regards, Praveen

Reply to
praveen.kantharajapura
Loading thread data ...

The precise specification on the behaviour of a PCI arbiter is in the PCI spec. You can find that at

formatting link

Indeed, the activity of all devices is in the spec. Get the spec and read it, because that's the only way you'll get proper PCI compliance.

Cheers

PeteS

Reply to
PeteS

I have (unfortunately) met that one.

I have had designs I inherited that would completely lock up (for a different reason - the vendor introduced an 'improved' device) - not easy to explain to the boss that the unit they are selling 10s of thousands of a month needs to be replaced because the bug can hit at a

1% rate.

I agree the spec is not perfect, but the poster has asked PCI questions before -and back then I mentioned 'get the spec'. As always, **once you have the spec**, be careful and ask, but get the spec first :)

Cheers

PeteS

Reply to
PeteS

And be careful: There's a nice statemachine description for target, master and arbiter at the end, almost inviting to translate it 1:1 into VHDL/Verilog.

But the master equations contain a bug, which is hard to hit in reality, but it can disturb the bus very seriously... Been there, done that. Now I know why they printed a disclaimer in front of the appendix ;-)

--
         Georg Acher, acher@in.tum.de
         http://wwwbode.in.tum.de/~acher
         "Oh no, not again !" The bowl of petunias
Reply to
Georg Acher

Me too. This whole PCI thing will never work.

If you try to design a PCI arbiter without reading the PCI specification VERY carefully, you are a fool.

I am sure this is covered in the spec.

--Mac

Reply to
Mac

Yes. Each initiator must be able to drive FRAME#. Each device (both initiators and targets) listens to FRAME#.

Either way. If GNT# is asserted before another master is finished, the new initiator can't take control until the current initiator completes its transaction (which may be some time, depending on the latency timers) and parks the bus.

FRAME# can't be asserted until GNT# has been. Assuming GNT# has been asserted in the above, the arbiter may assume the initiator is dead 16 cycles (not sure this number is in the spec) after the bus has been idled with an outstanding GNT#. What to do with a dead PCI resource is left for the student.

In addition to the spec, I highly recommend PCI_System_Architecture_, by Shanley and Anderson (MindShare). It can be purchased in either dead-tree or ebook form at:

formatting link 

--
  Keith
Reply to
Keith Williams

U mean to say that once a request is given by a device, first the GNT# should be asserted then only the FRAME# can to be asserted.

What happens if the GNT# is asserted after the FRAME# is been asserted???

Reply to
praveen.kantharajapura

U mean to say that once a request is given by a device, first the GNT# should be asserted then only the FRAME# can to be asserted.

What happens if the GNT# is asserted after the FRAME# is been asserted???

Reply to
praveen.kantharajapura

An initiator can only assert FRAME# if it has GNT# and the bus is idle. If GNT# is de-asserted it doesn't immediately have to de-assert FRAME# (unless the latency timer has run out).

The world ends. Only the initiator with GNT# may begin a transaction.

--
  Keith
Reply to
Keith Williams

Praveen,

You cannot design an arbiter like this. You will have to obtain a book or the PCI specification or both if you ever want your arbiter to work.

--Mac

Reply to
Mac

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.