Hi Lim, I don't have this book but let me give it a shot.

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? ]

From the above code it is pretty clear that the packet is already in the SDRAM. There should be code somewhere that handles packet reception and transfer from port --> rfifo --> SDRAM. Since it is pretty generic it should be provided at one place and then not repeated. The dispatch loop must call the Ingress macro which performs the packet reception before it will call the WWBump macro.

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?).

The dl_buffer_handle is the buffer handle for one particular packet, and it is set some where before the above code, probably by Ingress. You will have to look at the dispatch loop and follow the macros to understand. The SDRAM doesn't return anything, the offset is calculated by your code that puts the data in the SDRAM in the first place. Look at the code for dispatch loop macros for a better idea.

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 5 converts the boff to a quadword, by dividing it by 8 (>>3). So a value of 36 will turn into 4 after line 5. The 4th quadword starts with byte 32. Again, it is your code that is doing the conversion, and no internal mechanism.

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??

If WWBump doesn't have the code, I guess there is some code (probably EthernetIngress) that does the stuff. Look at the dispatch loop to see what is called before WWBump. That's what I can assume, someone who has the book will be able to shed more light on the code. -- Shyamal Pandya Addr: 920 S Terrace Rd #102 Tempe AZ 85281 Phone: 1-480-966-1982 _________________________________________________________________ Share your photos without swamping your Inbox. Get Hotmail Extra Storage today! http://join.msn.com/?PAGE=features/es