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@intel.com NOT SPEAKING FOR INTEL ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Yannis Charitakis haritak@ics.forth.gr