Fast DEVSEL# Decode Recognition in Read Cycles

["Kevin Brace" <kevinbraceusenet@hotmail.com>]

        I am wondering when I should recognize DEVSEL# assertion during a 
read cycle if the target responding does fast DEVSEL# decoding (Asserting 
DEVSEL# one clock cycle after an address phase.).
Yes, if it were a write cycle, things will be easy considering that a 
turnaround cycle doesn't exist in a write cycle, so I can go ahead and 
recognize fast DEVSEL# assertion, but what should I do during a read cycle 
if the target responding does fast DEVSEL# assertion?
PCI Local Bus Specification Revision 2.2 3.3.1. Read Transaction Figure 3-5 
shows an example of a burst read cycle, and in clock 3 of the figure, 
DEVSEL# assertion waveform is shown as optional (DEVSEL# is at asserted and 
deasserted state which I will interpret as optional.), meaning that DEVSEL# 
can be asserted, but doesn't have to be asserted because a read transfer 
won't occur at clock 3 because of a turnaround cycle.
Yes, I understand that DEVSEL# assertion is optional for a target,
but should the initiator still recognize DEVSEL# assertion at clock 3?
The reason I care about such a corner case which probably may not matter in 
practice is because let's say this target does fast DEVSEL# decode in a read 
cycle, and asserts DEVSEL# by clock 3.
The initiator recognizes DEVSEL# assertion at clock 3, and let's say the 
target suddenly does Target Abort at clock 4 (DEVSEL# = 'H', TRDY# = 'H', 
and STOP# = 'L').
Target Abort can only occur after DEVSEL# was asserted for a least one clock 
cycle, so this is a valid Target Abort, and the initiator recognizes the 
Target Abort.
But let's say the initiator didn't recognize fast DEVSEL# assertion at clock 
3 because of a turnaround cycle, and the target suddenly signals Target 
Abort at clock 4.
If the fast DEVSEL# assertion at clock 3 was not recognized by the 
initiator, it shouldn't (won't) recognize the Target Abort at clock 4 
because DEVSEL# is not being asserted when Target Abort is being signaled.
Once Target Abort is being signaled by the target, it keeps asserting it, 
but the initiator didn't recognize the DEVSEL# assertion at clock 3 in the 
first place, so it will end the transaction as a Master Abort . . .
It sounds to me not recognizing DEVSEL# at clock 3 is some kind of protocol 
violation, so I guess fast DEVSEL# assertion has to be recognized at clock 3 
even if it were a read cycle and a turnaround cycle where a valid data 
transfer cannot occur at that clock.
        Thinking about this issue further, let's say in a write cycle, a 
target responding does fast DEVSEL# decode, simultaneously asserts TRDY#, 
and if IRDY# happened to be asserted, then that is a valid transfer.
But let's say in a read cycle, the target responding does fast DEVSEL# 
decode, simultaneously asserts TRDY#, which it is not supposed to do so, and 
IRDY# happened to be asserted.
Of course, that's a protocol violation because TRDY# is not supposed to be 
asserted during a turnaround cycle, but should the initiator still end the 
transaction if FRAME# happened to be deasserted?
If I reword my quesition here, do I have to ignore illegal TRDY# assertion 
at clock 3 of Figure 3-5 if such a thing happened, or should I honor it at 
clock 3 even though it is not suppose to happen?
        My current implementation recognizes fast DEVSEL# assertion in a 
read cycle during a turnaround cycle, and will also recognize illegal TRDY# 
assertion during the same cycle.
In other words, I am treating read and write cycles the same.




Kevin Brace (Typically, don't respond to me directly, and respond within the 
mailing list.)

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com