gigabit ethernet problem

Hi, I am using xilinx spartan3 xc3s4000 in my design. It is interfaced with 2 national Gigabit PHYs. So i receive a packet from phy A and transmit it to PHY B and vice versa. Now the problem i am facing is that one of the bytes in the packet randomly gets corrupt after a while..

First the packet drop was very frequent at high speeds, then i checked the power requirements of my PHYs and got to know that my regulator couldn't source that much current. Then i changed the regulator and now the problem occurs very rarely or it doesnt occur at all.

I have some checks in the RTL to identify if the error is FCS or buffer overflow.So every time the packet drops, my fcs flag is raised. So i viewed the incoming packet and saw that it always had some random corrupt byte. Like i was sending packets with known pattern, so after a while some random byte is getting corrupt. I don't know what to look for from now onwards.

I thought maybe it was the heat issue so used heat gun but nah it wasn't the heat problem.

My ground noise is 80mv peak-to-peak.

Need some pointers..

Regards

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

formatting link

Reply to
salimbaba
Loading thread data ...

hi have your problem solved, cause i 'm facing the same problem with Realtek RTL8201 chip at the receive section,i connected RXD to TXD and RXDV to TXE to test the chip in loopback through fpga xilinx spartan 3 xc3s400, in this test i got 4 out of 50 packets with fcs error at the pc. what's the issue?

tnx for any help

to

bytes

the

problem

viewed

random

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

formatting link

Reply to
nba83

Can you please describe the hardware setup in more detail - is it your own board or a known good board. Has this hardware setup ever worked (ie been error free ?). Is there any pattern in the 'random' corruption (eg is it always bit 0 or a 1 seen as 0 (or a 0 seen as 1) etc etc. Is it always the nth byte in a packet etc. Michael Kellett

Reply to
MK

i designed and rout the pcb board,i have one RTL8201BL as lan phy layer and Xilinx Spartan 3 XC3s400 as controller. i transmit raw packets. i don't have any error in sending packets, i tested transmit section at 95% bandwidth without a packet loss, but at receive there are random error receiving packets. the bytes that are corrupt are also random and does not have a pattern. only when the packet length become large(about 1400 Bytes), the error occur more frequent about (3-4 out of 20 packets),

i don't know how i can debug the problem, tnx in advanced for help :)

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

formatting link

Reply to
nba83

I can only make the most general suggestions. How are you generating the test packets - are you sure they are good. Can you check the signal integrity on either side of the PHY. Are the errors similar to those you got when the power supply was poor. Is the position of the errored byte at the start or end of the packet or just anywhere. Do you ever get more than one error per packet. Does it get worse or better with any boundary cases: ie does it never fail with a minimum length packet or fail lots more often with maximum length. Is there any sensitivity to packet contents. Is there any sensitivity to rate of packets.

MK

Reply to
MK

nd

t

),

Have you checked all your timing? Making setup/hold times for the Rx side of GigE can be tough with a Spartan. Been there, done that, you need to be very careful.

John P

Reply to
johnp

a=

no=

Bytes=

no i don't know how to do that? i don't know what are setup/hold times for Rx, and my Phy layer is 100MHz not Gig, I used RTL8201BL and i wrote a simple loopback program in which i connected RXDV to TXE and RXD to TXD at the corresponding TXCLK and RXCLK, do i need to do some timing for this simple program??

here is my code: always @ (posedge RTL_RXCLK) begin data

Reply to
nba83

Huh? I havent been reading this thread in details, but how are these clocks syncronized? Maybe they arent, hence your problem.

Reply to
Morten Leikvoll

clocks

i write it in two processes to ensure if the two clk are not syncronized the data won't read and transmited bad.

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

formatting link

Reply to
nba83

So you are trying to send some data grabbed in one clock domain into a different? You know that will fail? If the clocks are almost similar, it will work for periods when the clock phases are close. If txclk is derived from rxclk, you may get it to work, but first make a common domain.

Reply to
Morten Leikvoll

message

syncronized

tnx for your comment, so what should i do? i have tested the following code too, but still i have error in receiving packets.

assign RTL_TXE=RTL_RXDV; assign RTL_TXD=RTL_RXD;

tnx in advanced for help :) Neda Baheri

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

formatting link

Reply to
nba83

If your receiver gives you a clock, put that on a global clock, work with the data in this domain and also feed the transmitter with it. Be careful with timing. I would need your schematic diagram to tell more.

NP

Reply to
Morten Leikvoll

My problem got solved, had to do the timing analysis once again. Although XST wasn't reporting any timing failures, but I was on boundary, so once in a while I was getting the issue.

As far as your issue is concerned, what you are missing as pointed out by NP is that you have two clock domains. So, you need to sync these two clock domains. I think your phy is giving you both TXCLK and RXCLK at 25Mhz, for

100Mbps, correct me if i am wrong.

The best thing would be use a buffer at the incoming interface, write the data to the FIFO on RXCLK and after 4-5 writes, read the packet bytes at TXCLK.

Also, you do know how the ethernet works, right ? like in 100Mbps you have to deal with a nibble at a time, and in 1000Mbps, it's a byte.

Anyway, your issue of loopback will be solved by syncing the clock domains.

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

formatting link

Reply to
salimbaba

in

clock

for

have

with

careful

hi tnx for your suggestion, i am working on the fpga program as you suggested, but my problem still exist,i used chipscope to debug the problem, the data is received fine to fpga but it seemed that the data is not write and read back from dual port ram, here is the code. i don't know what's the problem and how should i proceed? thanks in advanced for help

i read the data received from lan in this process and write in DPRAM, generate a strob to transmit process to start sending data at the falling edge of RXDV, and capturing the end of packet transmition for reseting write address:

always @(posedge RTL_RXCLK) begin

/// Reading Data from RXD pin and save it in dpram if(RTL_RXDV) begin write_address2

Reply to
nba83

and one thing more, i also used the dual port ram from ISE instances , but out put is the same.

tnx in advanced for help

RAMB16_S4_S4 RAMB16_S4_S4_inst ( // .DOA(), // Port A 4-bit Data Output .DOB(Ram_Data_Out), // Port B 4-bit Data Output .ADDRA(write_address2), // Port A 12-bit Address Input .ADDRB(read_address2), // Port B 12-bit Address Input .CLKA(GlobalClk), // Port A Clock .CLKB(GlobalClk), // Port B Clock .DIA(Ram_Data_In), // Port A 4-bit Data Input //.DIB(DIB), // Port B 4-bit Data Input .ENA(1), // Port A RAM Enable Input .ENB(1), // Port B RAM Enable Input .SSRA(0), // Port A Synchronous Set/Reset Input .SSRB(0), // Port B Synchronous Set/Reset Input .WEA(Ram_Write_Enable), // Port A Write Enable Input .WEB(0) // Port B Write Enable Input );

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

formatting link

Reply to
nba83

First of all, although not related to your query but in general a good practice, you need to sync your signals in the FPGA. Like the signals RXD and RXDV although in sync with the RXCLK, you need to flop them in the system, then use it wherever you want to.

Now, few things:

1- why aren't you using the RXDV signal as a write signal to DPRAM and RXD as input?

2- Also, what you can do is, you can use a Coregen FIFO in your design instead of DPRAM. For DPRAM, you may require a controller, for FIFO you won't. So, just to test your logic, you can use FIFO instead. Then start reading when RXDV goes low.

suggested,

data

read

problem

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

formatting link

Reply to
salimbaba

Thank you for your useful comments :), my problem was solved . it was due to writing clk in dpram, this clk was 100mhz and I expected that the data was surely written in memory before the next rxclk which was 25MHZ, I changed writing clk to RXCLK and the problem was solved.

But a question, as it seemed to me that syncing signal are important(cause my problem was exactly due that) how should I do that??

I don't know how to sync RXD and RXDV? tnx in advanced for help Neda Baheri

RXD

falling

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

formatting link

Reply to
nba83

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.