> I guess we want to make sure that upon startup, we only ever put good data > in the 10gbe so that we don't have to reset it? > > We can just mask the tx_valid line low until data arrives at the 10gbe, > then let it do its thing. > > On Mon, Feb 27, 2012 at 3:05 PM, Kevin Zheng <[email protected]> wrote: > >> So how else can I reset the FIFO and the 10Gbe? Is there any fix out >> there?
Hi all. Here's how our machine works. In the earlier versions, we used the reset line, and occasionally it went wrong. Now the tx_discard line is used to reset the internal fifos with the sync_out pulse. Look to the middle right of the drawing gpt yjr ten_GBE yellow block. This thing is running nearly all the time, and it seems to work fine. I guess there's a newer 10 gbe yellow block, ( the _v2 block) but I don't know if it has similar issues. John >> >> >> On 2/27/2012 2:58 PM, John Ford wrote: >> >>> After working on the 10Gbe for a while and reading the replies to this >>>> thread >>>> http://www.mail-archive.com/**[email protected]/**msg02275.html<http://www.mail-archive.com/[email protected]/msg02275.html>, >>>> we >>>> used a reset scheme that holds the valid into 10Gbe low first, and >>>> then >>>> reset the 10Gbe, then let it startup, and release the valid line last >>>> and start transmitting data. >>>> >>>> However, there seems to be an inserted word in the beginning when the >>>> 10Gbe starts to transmit. It is always the first word of the first >>>> packet, and it happens randomly. Sometimes it's find and sometimes >>>> it's >>>> not, we have to keep doing reset and if lucky enough we will get it >>>> right. Is this a known issue to 10Gbe or has anyone found a good work >>>> around? >>>> >>>> The reset line is flaky. Don't use it... >>> >>> :( >>> >>> John >>> >>> >>> >> >> >
bGOUT_10GbE.pdf
Description: Adobe PDF document
