1. Home
  2. Field-Programmable Gate Arrays
  3. Re: same RTL on two same boards giving different behaviour

Re: same RTL on two same boards giving different behaviour

>

>> I tried to capture the >> packets on CHIPSCOPE, like on the transmitting end just before the

packet=

s >> exits the FPGA, the packet is fine till that point. So i placed another >> FPGA to capture it and it showed me a garbage packet, like data_valid >> signal going low right after SFD. >> > >Chipscope will not find the problem, it is not the right tool. Your >best bet is to turn off the board, walk away from it, lock it up, do >something to get it out of the picture but do not attempt to debug >this problem on the bench with the board. You have a timing problem, >and you'll never be able to find it via debug of the hardware so any >time you spend trying to solve this problem by looking at the physical >board is wasted time. > >The correct tool to use is static timing analysis which, if you follow >the guidelines I suggested, will solve the problem if you apply them >correctly. > >KJ >

ok thanks a lot =)

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

formatting link

Reply to
salimbaba
Loading thread data ...

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.

--
These are my opinions, not necessarily my employer's.  I hate spam.
Reply to
Hal Murray

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

Reply to
jc

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

formatting link

Reply to
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

Reply to
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

formatting link

Reply to
salimbaba

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.