Hi Jon. > This is a known problem and I don't believe anybody's working on a fix. There > is a slight complication in that the core uses multiple clock domains so > there is potential for race conditions during reset at clock boundaries if > this is not handled properly. David George (10GbE core author) can probably > comment further.
Jason is correct here. The business of multi clock-domain resets is a pain. Reset signals have to be registered multiple times and have an unknown propagation and deassertion time. In principle the most correct way to do this would be to have a "reset_done" reply signal back to the user. Another way of doing this is to define a safe back-off period, for example waiting 16 cycles. Another way of doing it is to not use the reset at all (which is my personal favourite). > FWIW, you only have to mask the "valid" line because EOF is ignored unless > the valid line is asserted. I am also using this workaround in the packetised > correlator. This is a pretty good work-around. It doesn't cost anything extra in the controller as would a reset-done or hardware enforced back-off. This particular reset situation could be made better by using a synchronous FIFO reset. Currently the issued reset only affects the data fifos on assertion and other logic throughout. So you accumulate junk in the fifos until you de-assert the reset. A fix is simple, but I don't really have time to test it. The issue of what happens when you clear the reset is a little more complicated and may require a back-off period. This same issue affects the DRAM (and possibly others). I think the moral of the story is that it is worth being paranoid when issuing resets. Hope this sheds some light on the situation. Regards, David
