state machine 2.0:some thoughts

[Norman J Rasmussen <Norman_J_Rasmussen@ccm.jf.intel.com>]

Text item: 

Quickest answer -- get a copy of the 2.1 spec, it has added a variable called 
D_done in the equations.  This is Decode done and resolves the issue for slow 
and medium decode. The equations do not take affect until decode is done except 
when DEVSEL# has been asserted.  This last case it does not matter if decode 
actually completed or not since another agent claimed the access.  THis is 
required since a single cycle (write) transaction could have started and 
completed (fast decode) before the slow decode device completes the decode 
process.

Norm Rasmussen


  >
> >On page 131 of the book "PCI system architecture" : 
> >
> >"the initiator doesn't have to assert IRDY immedately upon entering a >data 
> >phase"
> >
> >Does this also count for a single data phase ? 
> >Because the book also says:
> >
> >        "The initiator asserts IRDY# to indicate that it is ready to
> >receive the first data item from the target ... if this were the final 
> >data phase, the initiator would assert IRDY# and deassert FRAME#.."
>
> The problem is that a "DATA PHASE" is actually a clock cycle which 
> is not an "ADDRESS/COMMAND PHASE". So, you can have a data phase
> WITHOUT DATA TRANSFER. Your first excerpt from the spec says that 
> after the address phase, if the initiator is not ready it doesn't
> have to assert IRDY immediately. But the clock cycle is still called 
> a DATA PHASE. If your initiator is ready, it can assert IRDY
> immediately and wait for TRDY. Once again, if the target is not
> ready it will not assert TRDY, but the cycle will still be called a 
> DATA PHASE (without data transfer).
>
     
Maybe I didnt make myself clear what I was trying to ask, sorry for that. 
I'll formulate it this way :
     
IF I have a SINGLE data transfer :
     
PCI specs2.0 on p174
     
     STATE=IDLE
     goto B_BUSY if !FRAME#*!HIT
     
Suppose on clock 2, FRAME is asserted,address is latched, slow decoding -> 
goto state B_BUSY
     
on p175
     next STATE=B_BUSY
     goto B_BUSY if(!FRAME#+!IRDY)*!HIT
     
For a single data transfer, FRAME must be deasserted at clock 3. 
And suppose the address is still not decoded.
So this equation tells that IRDY# must be asserted IMMEDIATELY after the 
address phase.
This equation also tells that for a BURST, IRDY# does NOT have to be 
asserted immediately after the address phase.
Because in this case, FRAME is still asserted indicating that this isn't 
the last data phase.
     
Second problem :
     
p175
     STATE=B_BUSY
     goto B_BUSY if(!FRAME#+!IRDY)*!HIT
     goto IDLE if FRAME#
     goto S_DATA if (!FRAME#+!IRDY)*HIT*...
     
I'm confused about the second equation.
If the address is decoded with a base address match, but FRAME is 
deasserted because we're in a SINGLE data phase.
I should go to S_DATA.
But the second equation tells me also that I should go to IDLE because 
FRAME is deasserted.
     
So my first question is :
can I assume that IRDY must be asserted immediately after the address 
phase for a single data phase ?
     
Second question :
What's the use of GOTO IDLE in the state B_BUSY ?
     
Thanks in advance !
     
Kim

Text item: External Message Header

The following mail header is for administrative use
and may be ignored unless there are problems.

***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.

To: Mailing List Recipients <pci-sig-request@znyx.com>
Resent-Sender: pci-sig-request@znyx.com
Precedence: list
X-Loop: pci-sig@znyx.com
X-Mailing-List: <pci-sig@znyx.com> archive/latest/3444
Resent-Message-Id: <"p4JbN.0.l43.57q3o"@dart>
Content-Type: text
X-Mailer: ELM [version 2.4 PL23c]
Date: Mon, 12 Aug 1996 16:36:06 +0200 (DST)
Subject: state machine 2.0:some thoughts
Message-Id: <9608121436.AA11607@is2e.vub.ac.be>
From: tw38966@is1.bfu.vub.ac.be (Rafiki Kim Hofmans)
Resent-Date: Mon, 12 Aug 1996 16:36:06 +0200 (DST)
Received: by znyx.com (5.65/1.35)
     id AA12630; Mon, 12 Aug 96 07:39:48 -0700
Received: from znyx.com by netcomsv.netcom.com with SMTP (8.6.12/SMI-4.1)
     id GAA11058; Mon, 12 Aug 1996 06:23:47 -0700
Received: from netcomsv.netcom.com (uumail1.netcom.com [163.179.3.50]) by ormail
.intel.com (8.7.4/8.7.3) with SMTP id HAA19267; Mon, 12 Aug 1996 07:48:27 -0700
(PDT)
Resent-From: pci-sig-request@znyx.com
Received: from ormail.intel.com (ormail.intel.com [134.134.248.3]) by relay.jf.i
ntel.com (8.7.4/8.7.3) with ESMTP id HAA24250; Mon, 12 Aug 1996 07:48:26 -0700 (
PDT)
Return-Path: pci-sig-request@znyx.com

<)