FPGA and ethernet phy problem

S

salimbaba

Guest
Hi,
i am using spartan 3 xc3s4000 in my design and 2 national phys ar
integrated with it. The problem is that when i transmit from phy 1 to phy
,i receive the packet and i can view it on wireshark. When i transmit i
from phy2 to phy1 , wireshark display "receive ok" in statistics menu bu
it doesn't display any packet. and it doesn't report fcs error either.

btw i am using xilinx 12.1 for synthesis.

So,i switched to chipscope pro to debug my design,and i can see th
transmitting nibbles , which are correct. But i don't know why isn't the p
showing any packet.

Also, both are phys are just using 2 instances of same module. So, if th
logic works at one end, technically it should work at the other end a
well.

can anyone give me any pointers as to what should i do now? how to debu
it?
Because i have been stuck for 2 days now and my vision has narrowed down
lot and i am out of ideas now. Kindly!

Regards
SalimBaba

---------------------------------------
Posted through http://www.FPGARelated.com
 
On 10/27/2010 10:00 AM, salimbaba wrote:
Hi,
i am using spartan 3 xc3s4000 in my design and 2 national phys are
integrated with it. The problem is that when i transmit from phy 1 to phy 2
,i receive the packet and i can view it on wireshark. When i transmit it
from phy2 to phy1 , wireshark display "receive ok" in statistics menu but
it doesn't display any packet. and it doesn't report fcs error either.

btw i am using xilinx 12.1 for synthesis.

So,i switched to chipscope pro to debug my design,and i can see the
transmitting nibbles , which are correct. But i don't know why isn't the pc
showing any packet.

Also, both are phys are just using 2 instances of same module. So, if the
logic works at one end, technically it should work at the other end as
well.

can anyone give me any pointers as to what should i do now? how to debug
it?
Because i have been stuck for 2 days now and my vision has narrowed down a
lot and i am out of ideas now. Kindly!
Click to expand...
I'm not a super cool FPGA guy, but I can throw out a couple of suggestions:

1a: You have a plain old wiring error to one of the phys. Are transmit
and receive wired separately? If so, check the transmit wiring on phy2.

1b: Check trace impedance and any necessary delay matching, of course.

1c: And power supply decoupling, no floating pins, etc.

2: What flavor of Ethernet? How challenged is the chip for speed? If
it's right on the edge it may not like your choice of pins for one of
the phy's. A long time ago when I was involved in a PCI project the
only really successful PCI IP available for the FPGA we were using came
laid out and was locked down to specific pins. Yes, PCI isn't Ethernet,
and I don't know if it's an issue -- but it's something to check.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Do you need to implement control loops in software?
"Applied Control Theory for Embedded Systems" was written for you.
See details at http://www.wescottdesign.com/actfes/actfes.html
 
On Oct 27, 10:00 am, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
Hi,
i am using spartan 3 xc3s4000 in my design and 2 national phys are
integrated with it. The problem is that when i transmit from phy 1 to phy 2
,i receive the packet and i can view it on wireshark. When i transmit it
from phy2 to phy1 , wireshark display "receive ok" in statistics menu but
it doesn't display any packet. and it doesn't report fcs error either.

btw i am using xilinx 12.1 for synthesis.

So,i switched to chipscope pro to debug my design,and i can see the
transmitting nibbles , which are correct. But i don't know why isn't the pc
showing any packet.

Also, both are phys are just using 2 instances of same module. So, if the
logic works at one end, technically it should work at the other end as
well.

can anyone give me any pointers as to what should i do now? how to debug
it?
Because i have been stuck for 2 days now and my vision has narrowed down a
lot and i am out of ideas now. Kindly!

Regards
SalimBaba          

---------------------------------------        
Posted throughhttp://www.FPGARelated.com
Click to expand...
Have you checked your timing constraints? You could be lucky that one
PHY interconnect
makes timing and the other doesn't.

John Providenza
 
Have you checked your timing constraints? You could be lucky that one
PHY interconnect
makes timing and the other doesn't.

John Providenza
Click to expand...
Exactly john, i figured out today that it was a timing constraints issue
One phy was meeting them and the other one wasn't. But xilinx wasn'
reporting it so i guess i was operating on the boundary. But john its
funny world we live in, we placed some constraints and it started to work
Both ports working fine but then we added another thing in the design,
counter actually, and the design again stopped working on one end.Now, th
port was switched. So, we took out some signals in chipscope and th
problem again switched ports :p funny, right ? :p i don't know what'
happening, i mean if it's a timing issue and xilinx isn't saying tha
timing failed, then i guess it should work each time we run. what do u hav
to say on this ?

---------------------------------------
Posted through http://www.FPGARelated.com
 
On Oct 28, 12:53 pm, "salimbaba"
<a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
Have you checked your timing constraints?  You could be lucky that one
PHY interconnect
makes timing and the other doesn't.

John Providenza

Exactly john, i figured out today that it was a timing constraints issue.
One phy was meeting them and the other one wasn't. But xilinx wasn't
reporting it so i guess i was operating on the boundary. But john its a
funny world we live in, we placed some constraints and it started to work..
Both ports working fine but then we added another thing in the design, a
counter actually, and the design again stopped working on one end.Now, the
port was switched. So, we took out some signals in chipscope and the
problem again switched ports :p funny, right ? :p  i don't know what's
happening, i mean if it's a timing issue and xilinx isn't saying that
timing failed, then i guess it should work each time we run. what do u have
to say on this ?          

---------------------------------------        
Posted throughhttp://www.FPGARelated.com
Click to expand...
A suggestion - look at the timing report and make sure you have the
timing analyzer
report all unconstrained paths. I always try to eliminate them so I
know that I've
got a fully constrained design.

John Providenza
 
johnp <jprovidenza@yahoo.com> wrote:

On Oct 28, 12:53=A0pm, "salimbaba"
a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
Have you checked your timing constraints? =A0You could be lucky that one
PHY interconnect
makes timing and the other doesn't.

John Providenza

Exactly john, i figured out today that it was a timing constraints issue.
One phy was meeting them and the other one wasn't. But xilinx wasn't
reporting it so i guess i was operating on the boundary. But john its a
funny world we live in, we placed some constraints and it started to work=
.
Both ports working fine but then we added another thing in the design, a
counter actually, and the design again stopped working on one end.Now, th=
e
port was switched. So, we took out some signals in chipscope and the
problem again switched ports :p funny, right ? :p =A0i don't know what's
happening, i mean if it's a timing issue and xilinx isn't saying that
timing failed, then i guess it should work each time we run. what do u ha=
ve
to say on this ? =A0 =A0 =A0 =A0 =A0

--------------------------------------- =A0 =A0 =A0 =A0
Posted throughhttp://www.FPGARelated.com

A suggestion - look at the timing report and make sure you have the
timing analyzer
report all unconstrained paths. I always try to eliminate them so I
know that I've
got a fully constrained design.
Click to expand...
Don't try to eliminate them. Make sure to eliminate them! It is also
very important to constrain the IOB to flipflop and flipflop to IOB
paths. Those are easely forgotten but may cause the OP's problems.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
On Oct 29, 3:38 pm, n...@puntnl.niks (Nico Coesel) wrote:
johnp <jprovide...@yahoo.com> wrote:
On Oct 28, 12:53=A0pm, "salimbaba"
a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
Have you checked your timing constraints? =A0You could be lucky that one
PHY interconnect
makes timing and the other doesn't.

John Providenza

Exactly john, i figured out today that it was a timing constraints issue.
One phy was meeting them and the other one wasn't. But xilinx wasn't
reporting it so i guess i was operating on the boundary. But john its a
funny world we live in, we placed some constraints and it started to work> >.
Both ports working fine but then we added another thing in the design, a
counter actually, and the design again stopped working on one end.Now, th> >e
port was switched. So, we took out some signals in chipscope and the
problem again switched ports :p funny, right ? :p =A0i don't know what's
happening, i mean if it's a timing issue and xilinx isn't saying that
timing failed, then i guess it should work each time we run. what do u ha> >ve
to say on this ? =A0 =A0 =A0 =A0 =A0

--------------------------------------- =A0 =A0 =A0 =A0
Posted throughhttp://www.FPGARelated.com

A suggestion - look at the timing report and make sure you have the
timing analyzer
report all unconstrained paths.  I always try to eliminate them so I
know that I've
got a fully constrained design.

Don't try to eliminate them. Make sure to eliminate them! It is also
very important to constrain the IOB to flipflop and flipflop to IOB
paths. Those are easely forgotten but may cause the OP's problems.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Click to expand...
I had a Lattice design with a global clock spec, global input spec and
global output spec in addition to some more detailed specs... and
still the timing analyzer reported unconstrained paths. When I asked
the FAE about it he said you can never get rid of them all! If my
constraints hadn't been pretty relaxed I would have pushed harder to
get to the bottom of that.

This is one of my beefs with static timing analysis. It is only valid
if you have applied the constraints correctly. We can simulate and
verify our design, but how do you verify the timing constraints? I
think they should have a constraint reporting tool where you can pick
specific end points and ask what the controlling timing spec is.
Compare this to your intent and you have verification. The vendors
seem to think it is ok to not verify constraints.

Rick
 
rickman <gnuarm@gmail.com> wrote:

On Oct 29, 3:38=A0pm, n...@puntnl.niks (Nico Coesel) wrote:
johnp <jprovide...@yahoo.com> wrote:
On Oct 28, 12:53=3DA0pm, "salimbaba"
a1234573@n_o_s_p_a_m.n_o_s_p_a_m.owlpic.com> wrote:
Have you checked your timing constraints? =3DA0You could be lucky tha=
t one
PHY interconnect
makes timing and the other doesn't.

John Providenza

Exactly john, i figured out today that it was a timing constraints iss=
ue.
One phy was meeting them and the other one wasn't. But xilinx wasn't
reporting it so i guess i was operating on the boundary. But john its =
a
ha=3D
ve
to say on this ? =3DA0 =3DA0 =3DA0 =3DA0 =3DA0

--------------------------------------- =3DA0 =3DA0 =3DA0 =3DA0
Posted throughhttp://www.FPGARelated.com

A suggestion - look at the timing report and make sure you have the
timing analyzer
report all unconstrained paths. =A0I always try to eliminate them so I
know that I've
got a fully constrained design.

Don't try to eliminate them. Make sure to eliminate them! It is also
very important to constrain the IOB to flipflop and flipflop to IOB
paths. Those are easely forgotten but may cause the OP's problems.


I had a Lattice design with a global clock spec, global input spec and
global output spec in addition to some more detailed specs... and
still the timing analyzer reported unconstrained paths. When I asked
the FAE about it he said you can never get rid of them all! If my
Click to expand...
Thats weird. IMHO you should be able to specify all the timing paths
in a CPLD/FPGA design.

This is one of my beefs with static timing analysis. It is only valid
if you have applied the constraints correctly. We can simulate and
verify our design, but how do you verify the timing constraints? I
think they should have a constraint reporting tool where you can pick
specific end points and ask what the controlling timing spec is.
Click to expand...
IIRC the Xilinx tools can do this.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
 
You must log in or register to reply here.

Welcome to EDABoard.com

Sponsor

Back
Top