[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Any PCI specs violation? -- a prove on its violation
Hello Weng,
You are right about case 5: the "master based fast-back-to-back mechanism"
can
generate a situation where you won't be able to evaluate properly the real
status
of the PCI bus if you are using a registered nFRAME.
I'm not sure if there is actually any PCI master device that can initiate
fast-
back-to-back cycles without is "fast-back-to-back enable bit" set, even if
the
"master based fast-back-to-back mechanism" allows it. But you are right:
this
situation is enough on its own to prohibit the use of a registered nFRAME
when
starting a new PCI transaction as a PCI master device. I don't know neither
if
all PCI target devices do support the "master based fast-back-to-back
mechanism"
properly. Thank you for your reply, that has been a good discussion.
Regards,
François.
**********************************
François Barlow
Asic Design Leader
Matrox electronic systems
Imaging department
tel: 514-685-7230 x2280
fax: 514-822-6110
email: fbarlow@matrox.com
**********************************
-----Original Message-----
From: Weng Tianxiang [mailto:wtx@umem.com]
Sent: Tuesday, January 16, 2001 11:54 AM
To: fbarlow@matrox.com
Subject: Re: Any PCI specs violation? -- a prove on its vaiolation
Hi Francois,
Your conclusion for case 1 situation is right: no clock is wasted.
By "on Clock x" it means all signals happen with their values before Clock x
rising edge.
My explanations:
1. case 1 situation: The following situations are permitted:
On clock -2, nFRAME = '1', nIRDY = '0', nGNT = '1';
On clock -1, nFRAME = '1', nIRDY = '1, nGNTa = '0'; nFrame_R = '1'
On clock 0, nFRAME = '0', nIRDY = '1, nGNTa = '0';
I disagree with your 2nd conclusion: If my board doesn't support fast
back-to-back transaction, no bus crash under case 5.
1. Do you agree case 5 will happen?
2. If it happens, PCI 2.2 specs page 3.4.2 says:
"... This type of fast back-to-back(Weng: the same master that accesses to
the same agent) is optional for a master, but must be decoded by a target.
The target must be able to detect a new assertion of FRAME#(from the same
master) without the bus going to the idle state."
When a Master is in case 5 situation and it is going to do a same-target
fast back-to-back transaction, and MY BOARD IS NOT INVOLVED IN THE
TRANSACTION.
The following sequence is possible:
On clock -1: nFRAME = '1', nIRDY = '0' and nGNTx = '0' -- case 5
On clock 0: nFRAME = '0', nIRDY = '1' and nGNTa = '0' , nFrame_R = '1'
On clock 0, bus owner is the bus owner of clock -1, not my board, and it is
its first data clock with inserting wait clock.
On clock 0, all three conditions are met, so on clock 1 my board will
attempt to drive its command, a bus crash! It seems to me that no matter my
board supports fast back-to-back transaction or not, bus will crash.
Thank you.
Weng Tianxiang
Micro Memory Inc.
9540 Vassar Av.
Chatsworth, CA 91311
Phone: 818-998-0070, Fax: 818-998-4459
----- Original Message -----
From: Francois Barlow <fbarlow@Matrox.COM>
To: <wtx@umem.com>
Cc: <pci-sig@znyx.com>
Sent: Monday, January 15, 2001 4:07 PM
Subject: RE: Any PCI specs violation? -- a prove on its vaiolation
Hi Weng,
As mentionned in my previous email, if fast-back-to-back cycles are not
supported by your PCI device (as a master AND as a target), there is no
problem using a registered version of nFRAME to start your master state
machine. In "case 1", you think you are wasting one clock cycle. This
is not true.
You wrote:
> case 1: nFRAME = '1' and nIRDY = '1 and nGNTa = '0':
> It means on Clock -1 the Master module state machine should transfer from
> start state.
> Starting transfer from start state on Clock 0 is one clock delayed. NOT A
> GOOD DESIGN using nFrame_R to replace nFRAME!!!
If fast-back-to-back cycles are not allowed, you can be sure that signal
nFRAME
will be '1' at least two clock cycles between each PCI transaction (the
first
one being during the last data phase of the transaction, the other one being
the
IDLE cycle on the bus). In that situation, there are no extra clock cycle
wasted
on the bus because the IDLE cycle is needed and can then be used to evaluate
the
registered version of nFRAME (which is also '1' during the IDLE cycle, since
the
previous clock cycle was the last data phase of the transaction, and nFRAME
is
always '1' during the last data phase of any PCI transaction).
François.
**********************************
François Barlow
Asic Design Leader
Matrox electronic systems
Imaging department
tel: 514-685-7230 x2280
fax: 514-822-6110
email: fbarlow@matrox.com
**********************************
-----Original Message-----
From: Weng Tianxiang [mailto:wtx@umem.com]
Sent: Monday, January 15, 2001 2:31 PM
To: pci-sig@znyx.com
Subject: Re: Any PCI specs violation? -- a prove on its vaiolation
Hi Francois, Olaf and Peter,
The following is a stricter prove on the assersion:
Start transition condition of Master module state machine:
nFRAME = '1' and nIRDY = '1' and nGNT = '0'
CANNOT BE REPLACED CORRECTLY IN ANY CASE by
nFrame_R = '1' and nIRDY = '1' and nGNT = '0'
even if the Master module itself doesn't issue fast-back-to-back command;
nFrame_R is registered value of nFRAME.
All capital signals are PCI direct signals; leading 'n' replaces tailing
'#'.
By "on Clock x" it means all signals happen with their values before Clock x
rising edge.
Conditions:
Clock -1: nFRAME = '1'
Clock 0: nIRDY = '1' and nGNT = '0'
Prove:
If we can draw a conclusion under 6 cases on Clock -1
case 1: nFRAME = '1', nIRDY = '1' and nGNTa = '0'
case 2: nFRAME = '1', nIRDY = '1' and nGNTx = '0'
case 3 nFRAME = '1', nIRDY = '1' and nGNT = '1'
case 4 nFRAME = '1', nIRDY = '0' and nGNTa = '0'
case 5 nFRAME = '1', nIRDY = '0' and nGNTx = '0'
case 6 nFRAME = '1', nIRDY = '0' and nGNT = '1'
that on Clock 0 nFRAME must be '1', that is all. My analysis is not the
case.
By nGNTa = '0' it means nGNT is asserted on our own board, nGNTx = '0' means
nGNT is asserted on other board.
on Clock -1
case 1: nFRAME = '1' and nIRDY = '1 and nGNTa = '0':
It means on Clock -1 the Master module state machine should transfer from
start state.
Starting transfer from start state on Clock 0 is one clock delayed. NOT A
GOOD DESIGN using nFrame_R to replace nFRAME!!!
on Clock -1
case 2: nFRAME = '1' and nIRDY = '1 and nGNTx = '0':
Based on conditions given, on Clock 0 nGNTa = '0'.
The situation violates the PCI 2.2 specs page 254: One GNT# can be
deasserted coincident with another GNT# being asserted if the bus is not in
the idle state. Otherwise, a one clock delay is required between the
deassertion of a GNT# and the assertion of the next GNT#.
It means case 2 will not happen at all.
on Clock -1
case 3 nFRAME = '1' and nIRDY = '1 and nGNT = '1':
On Clock -1: bus is idle, no bus owner now. So on Clock 0 nFRAME should be
'1'.
on Clock -1
case 4 nFRAME = '1' and nIRDY = '0' and nGNTa = '0':
Our board is bus master and bus is in the last data cycle.
This is the situation the Master can start issuing command on Clock 0 and
from Clock 0 nIRDY = '1', we can get nFRAME must be '0' on Clock 0. That
means if we want to use nFrame_R to replace nFRAME, the Master module cannot
start fast back-to-back transactions or it can do it with additional logic
to test before starting transfer.
on Clock - 1
case 5 nFRAME = '1' and nIRDY = '0' and nGNTx = '0':
Bus owner is other one's, and it is a last data cycle. PCI 2.2 specs page
254, 21.b says: The agent is permitted to start a transaction only in the
following two cases:
b. GNT# is asserted in the last data phase of a transaction and the agent is
starting a new transaction using fast back-to-back timing. So the bus owner
has the right to start a fast back-to-back transaction. In that case, on
Clock 0, nFRAME will be '0' and nIRDY = '1' and nGNTa can be '0' and nGNTx =
'1'. It will cause bus crash if we use
nFrame_R = '1' and nIRDY = '1' and nGNT = '0' to start a new command.
On Clock -1
case 6 nFRAME = '1', nIRDY = '0' and nGNT = '1'.
Bus owner has last data cycle and it has no bus grant any more and cannot
issue another fast back-to-back command after the data cycle is finished.
Conditions of nIRDY = '1' and nGNTa = '0' on Clock 0 means nFRAME = '1' on
Clock 0.
The following is the conclusion list for all cases on Clock -1:
case 1: nFRAME = '1', nIRDY = '1' and nGNTa = '0': one clock is delayed and
wasted
case 2: nFRAME = '1', nIRDY = '1' and nGNTx = '0': not happen
case 3 nFRAME = '1', nIRDY = '1' and nGNT = '1': good
case 4 nFRAME = '1', nIRDY = '0' and nGNTa = '0': not happen if Master
doesn't issue fast back-to-back command.
case 5 nFRAME = '1', nIRDY = '0' and nGNTx = '0': will cause bus crash if
the current bus master issues a fast back-to-back transaction.
case 6 nFRAME = '1', nIRDY = '0' and nGNT = '1': good.
Based on the above analyses, I will not use nFrame_R to replace nFRAME to
start Master transition even my Master doesn't issue fast back-to-back
commands.
Any comments on the above analyses are appreciated.
Thank three of you. Your answers to my emails gave me a chance to increase
my analysis ability.
Weng Tianxiang
Micro Memory Inc.
9540 Vassar Av.
Chatsworth, CA 91311
Phone: 818-998-0070, Fax: 818-998-4459
----- Original Message -----
From: Francois Barlow <fbarlow@Matrox.COM>
To: Olaf Reichenbaecher <Olaf.Reichenbaecher@sci-worx.com>; <wtx@umem.com>
Cc: <pci-sig@znyx.com>
Sent: Friday, January 12, 2001 9:23 AM
Subject: RE: Any PCI specs violation?
Hi,
> __ __ __ __ __
> CLK _| 1|__| 2|__| 3|__| 4|__| 5|_
> ___________________
> GNT#(A) ________|
> ________ _______
> GNT#(B) |___________|
> ________ _____________
> FRAME#(A) |_____|_____________
> ______________
> IRDY#(A) |_____________
> ______________ _______
> FRAME#(B) |_____|_______
> ____________________
> IRDY#(B) |_______
>
The situation described by your waveform is not accurate,
because the PCI spec says that "a GNT# can be deasserted
coincident with another GNT# being asserted if the bus is
not in the IDLE state" (PCI spec rev 2.2 page 254, Arbitration
section point 23-b).
In the situation above, one clock delay is required
between GNT#(A) deassertion and GNT#(B) assertion because
the bus was IDLE when the arbiter took the decision to
remove GNT#(A) signal.
Using the registered version of FRAME# to know the state
of the bus is possible only if you can insure that no
fast-back-to-back cycle are perform on the PCI bus.
If fast-back-to-back cycles are supported, the problem
would appear in the following situation, where a fast-
back-to-back cycle is performed by master "A" (where
master "B" is still your PCI master device):
__ __ __ __ __
CLK _| 1|__| 2|__| 3|__| 4|__| 5|_
_____________________
GNT#(A) ________|
________
GNT#(B) |_____________________
_____ _______________
FRAME#(A) __| |_____|_______________
_____
IRDY#(A) ________| |_______________
______________ _________
FRAME#(B) |_____|_________
____________________
IRDY#(B) |_________
During cycle 1, Master "A" was in the last data phase
of its transaction and is allowed to initiate a fast-back-
to-back cycle on cycle 2 because GNT#(A) was asserted
during cycle 1. However, during cycle 1 the arbiter sees
the bus busy and it is then allowed to change both GNT#
signals simultaneously at cycle 2. During cycle 2, if
master "B" is not able to see that the bus is busy (it'll
be the case using a registered version of FRAME#), master
"B" transaction will interfere with master "A" transaction.
François.
**********************************
François Barlow
Asic Design Leader
Matrox electronic systems
Imaging department
tel: 514-685-7230 x2280
fax: 514-822-6110
email: fbarlow@matrox.com
**********************************
-----Original Message-----
From: Olaf Reichenbaecher [mailto:Olaf.Reichenbaecher@sci-worx.com]
Sent: Friday, January 12, 2001 3:07 AM
To: wtx@umem.com
Cc: pci-sig@znyx.com
Subject: Re: Any PCI specs violation?
hi there,
> I have been designing PCI 66MHz/64-bit core. The following is a code
> excerpt. I want to know if the following equation violates any PCI
> specs:
>
> case MState is
> when MIdle_S =>
> -- device is not disconnected and is granted PCI bus
> -- here nFRAME can be replaced by nFrame_R
> if(MEnableMemory and nGNT = '0' and nFrame_R = '1' and
> nIRDY = '1') then
> -- if requested by Master module
> if(nReq_O = '0') then
> ...
>
> 1. This is a Master state machine first state: Master idle state;
> 2. nFrame_R is registered value of nFRAME, 1 clock later than nFRAME;
> 3. If nFrame_R above is replaced by nFRAME, there is no any problem;
> 4. The reason to replace nFRAME with nFrame_S is to reduce nFRAME
> fanout as much as possible;
>
> Is there any possibility that the above replacement causes problem?
your master state machine is going to detect the PCI bus' idle state
before starting any activity on the bus. by the time IRDY# has gone
inactive from some previous transaction FRAME# has already been
deasserted at least one cycle before. so far no problem.
i have constructed the following signal scheme. although not very
likely (?) the PCI spec permits it:
suppose agent B is your master device and agent A is another one.
the arbiter serves agent B with a higher priority than agent A.
since the arbiter is allowed to deassert GNT# at any time while
FRAME# is deasserted in order to serve a higher priority master,
it removes the GNT# from A and gives it to B in cycle 2. agent A
asserts FRAME# in the same cycle since it has seen it's GNT#. in
cycle 3 your device (agent B) sees it's GNT# asserted. IRDY# is not
yet asserted and the registered FRAME# is still in inactive state
as well, so your device asserts FRAME# in order to start a transaction
and this way interferes with the transction of agent A.
__ __ __ __ __
CLK _| 1|__| 2|__| 3|__| 4|__| 5|_
___________________
GNT#(A) ________|
________ _______
GNT#(B) |___________|
________ _____________
FRAME#(A) |_____|_____________
______________
IRDY#(A) |_____________
______________ _______
FRAME#(B) |_____|_______
____________________
IRDY#(B) |_______
i hope my example is clear enough in order to reveal the potential
functional problem. being a PCI core designer on my own i don't
think you might be able to reduce the fanout on PCI bus signals
significantly by using the registered ones instead at such specific
points.
cheers!
olaf
--
Olaf Reichenbaecher
Senior Design Engineer
_____________________________
sci-worx GmbH
Garbsener Landstr. 10
30419 Hannover
Germany
Tel +49 (0)511 277-1432
Fax +49 (0)511 277-2410
Olaf.Reichenbaecher@sci-worx.com
http://www.sci-worx.com