Hi Anthony It is not necessary to wait for the the buffer to be empty before starting transmission of the next block of data. As long as transmission is stopped when tx_afull is high to prevent FIFO overflows you should be able to continually send new packets.
When the tx_end_of_frame signal is pulsed with tx_data_valid, a count of the number of data elements written to the FIFO is saved and the counter reset. If more data is sent, the counter will start counting again and again be saved when tx_end_of_frame is pulsed with tx_data_valid. The count value itself is saved to a FIFO (along with the IP address and port the packet is to be sent to) and so will not be overwritten. This FIFO is 16 elements deep so you should be able to have up to that many waiting for transfer (also depends on the data packet size of course) but tx_afull will tell you when you are approaching this limit. A few things to note: Don't ignore the tx_afull line. If FIFOs overflow, the synchronisation between data and info on that data will be lost. Strobe tx_end_of_frame with tx_data_valid only once at the end of a packet. If you are interested in delving deeper into how the ten_GbE_v2 block works, look in xps_lib\XPS_ROACH_base\pcores\kat_ten_gb_eth_v1_00_a\hdl\verilog. Hope this explains things Regards Andrew 2009/7/23 Weerasinghe, Anthony D (335J) <[email protected]> > Hi, > > > > I am currently working on a design that uses the ten_GbE_v2 block from the > CASPER library. I have a question regarding the TX buffer in this block. > Let’s say that I am sending a 500 word packet that has been loaded into the > TX buffer using tx_valid. When the last word is being sent, I pulse > tx_end_of_frame so that the core will wrap the packet and begin > transmission. Once transmission has begun, do I have to wait until the > buffer is empty before tx_valid can be set high and new data can be written > to the buffer? Or does the ten_GbE_v2 core have a secondary buffer that > allows continuous writing to the TX buffer after tx_end_of_frame has been > pulsed? > > > > Thanks very much for your help, > > Anthony Weerasinghe >
