1. Home
  2. Field-Programmable Gate Arrays
  3. RTL timing issue

RTL timing issue

Hi, I am using a customized board with 1 spartan 3 xc3s4000 FPGA and 2 Gigabit Phys. My system clock is 125Mhz and i am facing an issue which occurs after a while but since it occurs so it is a problem for me.

I have no timing failures in my design, at least none reported by xilinx ISE. I also read the delay report to see if there are any of my critical signals listed under the worst delay paths,none.

The design is actually a MAC so whatever we receive from one PHY is transmitted on to the other PHY.

The problem i am facing is that occasionally only one byte in the packet gets corrupt.And it gets corrupt on the incoming interface i.e. at the first FF. I can't figure out why would it behave like this occasionally as it works properly otherwise. Any pointers on how i should proceed further ?

PS. There are no setup/hold time violations.

regards

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

formatting link

Reply to
salimbaba
Loading thread data ...

You may want to check that the input data paths from the pads to the sampli= ng flip-flops are properly constrained. There's an option in the timing ana= lyzer for reporting unconstrained paths.

It's also usually a good idea to put those FFs in the IOBs to minimize the = delay from the pads to the FFs. You can use the IOB constraint for that. Af= ter the implementation, you should check that the specified FFs were effect= ively placed in the IOBs - you can use the FPGA editor for that.

Hope this helps, Guy.

formatting link

Reply to
Guy Eschemann

sampli=

ana=

=

Af=

effect=

I have already constrained the data paths from the pads to the sampling FFs.And the FFs are in IOBs because without that i was having a massive timing failure and i verified it using the FPGA editor. So already done that. Thanks =)

any other thing i can check ?

regards

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

formatting link

Reply to
salimbaba

You may try changing the phase of your sampling clock to see if that helps.

Cheers, Guy.

formatting link

Reply to
Guy Eschemann

helps.

Done that too.. Actually when i changed the phase of the clock, the byte corruption was narrowed down to only 1 bit getting corrupt and performance got better, like the byte corruption was not frequent as before but still it was. So, i delayed the clock a little more , by 1ns , the performance stayed the same. I was thinking of changing the clock termination resistor, at the moment i have a 33Ohms resistor in place, do u think it has anything to do with the termination ?

Thanks

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

formatting link

Reply to
salimbaba

abit

er

s

One idea is that this problem is being caused by the receiver's inability to recover a "scrolling" source clock frequency. The clock frequency of the source box that is transmitting the traffic into the receiver which is reporting periodic corruption is asynchronous. True, that frequency may be based on 125 MHz +/- some ppm, but it will still "scroll" left or right (temporally speaking) in relation to the receiver clock. But as long as it is in PPM spec, this should happen slowly enough that the receiver can continuously synchronize to the traffic by using the idle time sync bytes.

A quick test is to see if the corruption occurs in loopback, in which case, the receiver should be referencing a clock that is synchronous to it, assuming that one single oscillator provides the source frequency to both the Tx and Rx domains. If this is a scroll problem, the receiver should not report corruption. (Be careful not to provide an "external sync" to the receiver in this "isolation" loopback test.

Also test to see if the corruption is traffic dependent. Try different packet sizes. Then try varying the traffic content.

- John

Reply to
jc

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.