[ixp1200] Fast Ports - sop_seq roll over

[Johnson, Erik J]

I will agree with you, that the most probable is this:

the RSM updates SOP_SEQ and pushes the rcv_cntl info into the 4-entry FIFO.
That is, changing SOP_SEQ register before the thread reads the corresponding
rcv_cntl register.

This means that if 4 SOP-MPKTs arrive back to back (that is 4 PACKETS of
length 64Bytes arrive back to back), then when a thread reads the rcv_cntl
register from the top of the FIFO queue, the SOP_SEQ register will already
have changed three more times.


Moreover, assuming that a thread executes the above two commands (repeated
bellow):
>       csr_read(sop_seq, sync_none);
>       csr_read(rcv_cntl, ctx_wait);

Both commands will be queued in the same fbi-fifo (in the pull engine). But
before that the two commands will have to be queued in the local (to the
uengine fifo), and then the Bus Arbiter will decide if both commands will go
back to back on the shared bus to the pull engine or if they will be split
in order for another microengine to be serviced.


If the Bus Arbiter is servicing a microengine until no more requests exist,
then we are ok. If not then we have no guarantee.


Am I right??? Does anyone have more information??

[Erik J. Johnson]  My experiments agree with the above
conclusions/assumptions.  Namely, the two values do differ.  However, I
don't think that this is a consequence of the two commands not being
serviced "atomically", I think this is entirely due to the fact that the
SOP_SEQ is updated immediately by the RSM.

erik

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Erik J. Johnson
Intel Research & Development
erik.j.johnson at intel.com
NOT SPEAKING FOR INTEL
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 Yannis Charitakis
 haritak at ics.forth.gr