[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REQ64# <-> ACK64# - handshake-mechanism in performing a single 64-bit (Write)-Transfer
Hi,
In the attachment file, there are one Target error and one improvement for
Master.
Weng
----- Original Message -----
From: Kirchmayer Markus <markus.kirchmayer@mchr2.siemens.de>
To: <pci-sig@znyx.com>
Sent: Wednesday, December 06, 2000 1:11 AM
Subject: REQ64# <-> ACK64# - handshake-mechanism in performing a single
64-bit (Write)-Transfer
> Hi,
>
> We have designed a PCI card with a Lucent-PCI-Interface Controller
> (OR3LP26). Unfortunately we have a problem in a
> 64bit PCI environment and at the moment we don't know if the OR3LP26 or
the
> PCI Host-Bridge causes the problem. Also the
> PCI spec. seems to be not very clearly at that point (at least we haven't
> found it).
> The question is now, if it is necessary that the master keeps FRAME#
> and REQ64# asserted until the target responses with DEVSEL# asserted and
> ACK64# asserted (or not asserted in case of
> a 32bit-target) or is it ok to deassert FRAME# and REQ64# as soon as the
> master is ready to signal that it is in the final (single)
> data phase (IRDY# asserted, FRAME# and REQ64# deasserted). This would
result
> in max. 2 TW-Cycles, in which neither REQ64#
> nor ACK64# are asserted. The attached text file shows a trace of this
> situation.
>
> Any comments would be appreciated. Thank you very much.
>
> Regards,
>
> Markus Kirchmayer
>
>
> <<psa8_64_short.TXT>>
>
> ********* Please note my new office and email addresses below. *********
>
>
> Company: SIEMENS
> Department: ATD IT PS 8 MCH
> Name: Markus Kirchmayer
> Postal Address: P.O.Box 830951
> D-81730 Munich
> Office Address: Otto-Hahn-Ring 6
> (Mch P, R. 75.410)
> D-81739 Munich
> Voice: +49-89-636-43309
> Fax: +49-89-636-49804
> E-mail: mailto:Markus.Kirchmayer@mchr2.siemens.de
> Web(Internet): http://www.atd.siemens.de/itps
> Web(Internet): http://www.eda-services.com
> Web(Internet): http://www.mvn-services.com
> Web(Intranet): http://www2.mchr.siemens.de/tdmch8
>
>
>
Sample TimeRel Burst# State C/BE[7:0]# AD[63:32] AD[31:0] FRAME# DEVSEL# IRDY# TRDY# STOP# ACK64# REQ64# Ext74
53: 30.3ns . .... 00000000 040120A0 000120A0 1 1 1 1 1 1 1 1111
54: 30.3ns . .... 00000000 040120A0 000120A0 1 1 1 1 1 1 1 1111
55: 30.3ns . Addr MemWri 00000000 80200100 0 1 1 1 1 1 0 1111 Req64#=0
56: 30.3ns . TW 00000000 040120A0 000120A0 1 1 0 1 1 1 1 1111 Req64#=1
57: 30.3ns . TW 00000000 040120A0 000120A0 1 0 0 1 1 0 1 1111
58: 30.3ns . TW 00000000 040120A0 000120A0 1 0 0 1 1 1 1 1111
59: 30.3ns . TW 00000000 040120A0 000120A0 1 0 0 1 1 1 1 1111
60: 30.3ns . Data 00000000 040120A0 000120A0 1 0 0 0 1 1 1 1111
61: 30.3ns . .... 00000000 040120A0 000120A0 1 1 1 1 1 1 1 1111
62: 30.3ns . .... 00000000 040120A0 000120A0 1 1 1 1 1 1 1 1111
REQ64# <-> ACK64# - handshake-mechanism in performing a single 64-bit (Write)-Transfer:
Is it necessary that the master keeps FRAME# and REQ64# asserted until the target responses with DEVSEL# asserted
and ACK64# asserted (or not asserted in case of a 32bit-target) or is it ok to deassert FRAME# and REQ64# as soon as
the master is ready to signal that it is in the final (single) data phase (IRDY# asserted, FRAME# and REQ64# deasserted).
This would result in max. 2 TW-Cycles, in which neither REQ64# nor ACK64# are asserted.
Weng note:
1. Target ACK64# generation has problem:
PCI 2.2, p.17: ACK64# should have the same timing as DEVSEL#; In another words, it cannot
be changed during DEVSEL# asserted period;
2. The better way to transfer a 64-bit word is doing 2 32-bit transaction. The reason is:
If the Master outputs are as above, and Target responses with ACK64# deasserted, Master can only transfer
1 32-bit word. It is terrible to restart next transaction to transfer the remaining 32-bit word.