Re: same RTL on two same boards giving different behaviour

It might be a logic bug. He said packets coming in one side and going out the other. For that to work without a common clock, you have to have occasional idle time on the fast links so the slow links can keep up. Maybe it's something like he isn't discarding the idle markers on the way info the FIFO and recreating them as needed on the output side. That would break if the input side is faster.

I don't disagree with combing the STA reports, the synth/map/route warnings, and the async hand-offs for clues or even smoking guns. That needs to be done. But using chipscope could be fruitful if you are able to isolate where errors are first identified, such as where the first packet gets dropped. I imagine that would be an easy condition to trigger on, and your appropriate choice of signals to monitor might tell you exactly where the faulty hand-off occurs. Won't hurt to monitor all appropriate FIFO flags along with any other error detection logic. Of course, be careful not to create new problems. Use the correct (sync) clock for the signals you are monitoring. Also, hopefully your performance margins have enough headroom to absorb the added chipscope logic. It would be especially wasteful if you had to jump through hoops just to meet timing with the chipscope logic.

- John

I find that it frequently helps to use SmartGuide when adding ChipScope to a design. Start with the design that is meeting timing and is already fully implemented. Then add ChipScope to the design. Then turn on SmartGuide and finish the build. To turn on SmartGuide, in the Hierarchy window with the implementation view selected, right click on the top level of your design and select SmartGuide from the pop up menu. Do the same to turn it back off latter. This will both reduce the impact on timing of adding ChipScope, and when I use this on my designs it reduces the implementation times to about 1/3 of what they normally are.

That said, this does sound like a timing problem.

Regards,

John McCaskill

Hi salimbaba

... That's exactly what's happening, when the FPGA cools down, it again starts to transmit packets for a while and then eventually stops when the FPGA is hot. ...

Assuming your timings constraints are correctly defined, the implementation reports don't show errors and the silicon it's Ok, this sound like an asynchronism in the design.

Walter

Hey, Thanks a lot everyone for the help, it surely taught me a lot of new things in the domain of debugging. The problem wasn't with the RTL or anything, it was a problem with the PHY. It was getting very hot, still in the operating range according to the datasheet but i don't know why it was transmitting any packets. So now i have attached a heat sink n a fan with it and everything is back to normal =) .

Thanks a lot for your help guys.

Regards

--------------------------------------- Posted through