D-2
Am79C965A
SETUP:
The driver should set up descriptors in groups of 3, with
the OWN and STP bits of each set of three descriptors
to read as follows: 11b, 10b, 00b.
An option bit (LAPPEN) exists in CSR3, bit position 5.
The software should set this bit. When set, the LAP-
PEN bit directs the PCnet-32 controller to generate an
INTERRUPT when STP has been written to a receive
descriptor by the PCnet-32 controller.
FLOW:
The PCnet-32 controller polls the current receive de-
scriptor at some point in time before a message arrives.
The PCnet-32 controller determines that this receive
buffer is OWNed by the PCnet-32 controller and it
stores the descriptor information to be used when a
message does arrive.
N0: Frame preamble appears on the wire, followed by
SFD and destination address.
N1: The 64th byte of frame data arrives from the wire.
This causes the PCnet-32 controller to begin frame
data DMA operations to the first buffer.
C0: When the 64th byte of the message arrives, the
PCnet-32 controller performs a look-ahead opera-
tion to the next receive descriptor. This descriptor
should be owned by the PCnet-32 controller.
C1: The PCnet-32 controller intermittently requests the
bus to transfer frame data to the first buffer as it ar-
rives on the wire.
S0: The driver remains idle.
C2: When the PCnet-32 controller has completely filled
the first buffer, it writes status to the first descriptor.
C3: When the first descriptor for the frame has been
written, changing ownership from the PCnet-32
controller to the CPU, the PCnet-32 controller will
generate an SRP INTERRUPT. (This interrupt ap-
pears as a RINT interrupt in CSR0.)
S1: The SRP INTERRUPT causes the CPU to switch
tasks to allow the PCnet-32 controller
’
s driver to
run.
C4: During the CPU interrupt
–
generated task switch-
ing, the PCnet-32 controller is performing a look-
ahead operation to the third descriptor. At this point
in time, the third descriptor is owned by the CPU.
[Note: Even though the third buffer is not owned by
the PCnet-32 controller, existing AMD Ethernet
controllers will continue to perform data DMA into
the buffer space that the controller already owns
(i.e. buffer number 2). The controller does not know
if buffer space in buffer number 2 will be sufficient
or not, for this frame, but it has no way to tell except
by trying to move the entire message into that
space. Only when the message does not fit will it
signal a buffer error condition
–
there is no need to
panic at the point that it discovers that it does not
yet own descriptor number 3.]
S2: The first task of the driver
’
s interrupt service routine
is to collect the header information from the PCnet-
32 controller
’
s first buffer and pass it to the applica-
tion.
S3: The application will return an application buffer
pointer to the driver. The driver will add an offset to
the application data buffer pointer, since the
PCnet-32 controller will be placing the first portion
of the message into the first and second buffers.
(The modified application data buffer pointer will
only be directly used by the PCnet-32 controller
when it reaches the third buffer.) The driver will
place the modified data buffer pointer into the final
descriptor of the group (#3) and will grant owner-
ship of this descriptor to the PCnet-32 controller.
C5: Interleaved with S2, S3 and S4 driver activity, the
PCnet-32 controller will write frame data to buffer
number 2.
S4: The driver will next proceed to copy the contents of
the PCnet-32 controller
’
s first buffer to the
begin-
ning
of the application space. This copy will be to
the exact (unmodified) buffer pointer that was
passed by the application.
S5: After copying all of the data from the first buffer into
the beginning of the application data buffer, the
driver will begin to poll the ownership bit of the sec-
ond descriptor. The driver is waiting for the
PCnet-32 controller to finish filling the second
buffer.
C6: At this point, knowing that it had not previously
owned the third descriptor, and knowing that the
current message has not ended (there is more data
in the fifo), the PCnet-32 controller will make a
“
last
ditch look-ahead
”
to the final (third) descriptor; This
time, the ownership will be TRUE (i.e. the descrip-
tor belongs to the controller), because the driver
wrote the application pointer into this descriptor
and then changed the ownership to give the de-
scriptor to the PCnet-32 controller back at S3. Note
that if steps S1, S2 and S3 have not completed at
this time, a BUFF error will result.
C7: After filling the second buffer and performing the
last chance look-ahead to the next descriptor, the
PCnet-32 controller will write the status and
change the ownership bit of descriptor number 2.
S6: After the ownership of descriptor number 2 has
been changed by the PCnet-32 controller, the
next
driver
poll of the 2nd descriptor will show owner-
ship granted to the CPU. The driver now copies the
data from buffer number 2 into the
“
middle section
”