[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: Any PCI specs violation? -- a prove on its vaiolation
----- Original Message -----
From: Weng Tianxiang <wtx@umem.com>
To: <fbarlow@matrox.com>
Sent: Tuesday, January 16, 2001 8:53 AM
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
>
>
>