[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fast DEVSEL# Decode Recognition in Read Cycles
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
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
Join the world’s largest e-mail service with MSN Hotmail.