RTL timing issue

S

salimbaba

Guest
Hi,
I am using a customized board with 1 spartan 3 xc3s4000 FPGA and 2 Gigabi
Phys. My system clock is 125Mhz and i am facing an issue which occurs afte
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 xilin
ISE. I also read the delay report to see if there are any of my critica
signals listed under the worst delay paths,none.

The design is actually a MAC so whatever we receive from one PHY i
transmitted on to the other PHY.
The problem i am facing is that occasionally only one byte in the packe
gets corrupt.And it gets corrupt on the incoming interface i.e. at th
first FF. I can't figure out why would it behave like this occasionally a
it works properly otherwise. Any pointers on how i should proceed furthe
?

PS. There are no setup/hold time violations.


regards

---------------------------------------
Posted through http://www.FPGARelated.com
 
You may want to check that the input data paths from the pads to th
sampli=
ng flip-flops are properly constrained. There's an option in the timin
ana=
lyzer for reporting unconstrained paths.

It's also usually a good idea to put those FFs in the IOBs to minimize th
=
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 wer
effect=
ively placed in the IOBs - you can use the FPGA editor for that.

Hope this helps,
Guy.
http://guy-eschemann.de
Click to expand...
I have already constrained the data paths from the pads to the samplin
FFs.And the FFs are in IOBs because without that i was having a massiv
timing failure and i verified it using the FPGA editor. So already don
that. Thanks =)

any other thing i can check ?

regards


---------------------------------------
Posted through http://www.FPGARelated.com
 
You may want to check that the input data paths from the pads to the sampling flip-flops are properly constrained. There's an option in the timing analyzer 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. After the implementation, you should check that the specified FFs were effectively placed in the IOBs - you can use the FPGA editor for that.

Hope this helps,
Guy.
http://guy-eschemann.de
 
You may try changing the phase of your sampling clock to see if tha
helps.

Cheers,
Guy.
http://guy-eschemann.de
Click to expand...
Done that too.. Actually when i changed the phase of the clock, the byt
corruption was narrowed down to only 1 bit getting corrupt and performanc
got better, like the byte corruption was not frequent as before but stil
it was. So, i delayed the clock a little more , by 1ns , the performanc
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 anythin
to do with the termination ?



Thanks


---------------------------------------
Posted through http://www.FPGARelated.com
 
You may try changing the phase of your sampling clock to see if that helps.

Cheers,
Guy.
http://guy-eschemann.de
 
On Jul 15, 9:53 am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
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 throughhttp://www.FPGARelated.com
Click to expand...
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
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top