Hi all,

 

Thanks Shyamal! I've visualize and understood the problem.  But i think the previous confusion is due to my misunderstanding on the below line of code,

 

1.  alu[dpoff, dpoff, +, 16]  ; Add Ether+TCP offsets
2.  Buf_GetData[base, dl_buffer_handle] ; Get buffer base address
3.  DL_GetBufferOffset[boff]  ; Get data offset in buf.
4.  alu[boff, boff, +, dpoff]  ; Compute byte address
5.  alu_shf[boff, --, B, boff, >>3]  ; Convert to Q-Word addr.
6.  sdram[read, $$hdr0, base, boff, 1], ctx_swap ; Read 8 bytes

 

Assume the packet reach at the IX_Bus interface. [This is a big assumption... and is it correct? If not, when dispatch loop runs the WWBump macro, the entire packet is currently in SDRAM? ]

 

Line 2 get the SDRAM base address for the xfer reg to copy packet data into.

 

Line 3 get the packet offset currently located in buffer (rfifo? SDRAM?), and i wonder how, by this command, the rfifo (SDRAM?) will know which is the correct current packet offset to return, amongst so many packets resided in rfifo (SDRAM?).

 

Assume IP header = 20 bytes, dpoff = 36 bytes.

Line 4 & 5 calculate dpoff and convert to quadword. In this context, SDRAM should read from 32 - 39 bytes. But, how does the SDRAM knows to read from 32 bytes, instead of 36 bytes?? Is there an internal mechanism to convert??

 

Line 6, this line, make me confuse, i assume, this line actually read packet data from SDRAM into transfer register, where the packet data offset, is at base+boff. So, the previous assumption --> data is in rfifo is wrong. Then, which part of the code in WWBump, where microengine instructs IX-Bus to transfer packet into SDRAM??