PCI arbiter doubts

[[email protected]]

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

 

[PeteS]

The precise specification on the behaviour of a PCI arbiter is in the
PCI spec. You can find that at
http://www.pcisig.com/specifications

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

 

[Georg Acher]

The precise specification on the behaviour of a PCI arbiter is in the
PCI spec. You can find that at
http://www.pcisig.com/specifications

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.

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 ;-)

 

[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

 

[Mac]

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

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

 

[Keith Williams]

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.

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

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

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.

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.

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: http://www.mindshare.com/store/

 

[[email protected]]

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.

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

 

[[email protected]]

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.

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

 

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

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

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

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

 

[Mac]

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

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