cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
dguisinger
Observer
Observer
9,963 Views
Registered: ‎12-26-2009

Can't figure out the TEMAC Tri-Mode Wrapper Core on Virtex-5

Jump to solution

Does anyone have a good getting started guide for the TEMAC wrapper on the Virtex-5?

I'm using it with a Broadcom PHY and I feel like i'm going in circles.  The PHY indicates it sees the ethernet cable and it sees packets coming across.

 

I've hooked up the status signals to LEDs

 

The signals I'm currently showing are:

CLIENTRTXDVLD 0

CLIENTRXFRAMEDROP 1

CLIENTSYNCACQSTATUS 1

ANINTERRUPT 0 

 

 I don't know exactly how I was supposed to drop this core into a design a I didn't find the documentation very helpful; other then wrapping the core to prevent unused status pins from mapping to random IOBs and mapping my pins to the proper nets - I don't know if there was anything else I am supposed to do. 

 

Its pretty frustrating when you are trying to bring up a board and you can't tell if the core is even doing what its supposed to be doing. 

 

Any pointers? 

Thanks

Dan 

0 Kudos
1 Solution

Accepted Solutions
dguisinger
Observer
Observer
10,753 Views
Registered: ‎12-26-2009

Alright, I figured it out!  

I was correct in that the SGMII link was reporting back as valid and connected.  I opened a webcase and while it didn't directly solve it (it was mostly the same suggestions as above) an additional getting started document was provided:

http://www.xilinx.com/products/boards/ml505/ml505_92i/docs/ml505_sgmii_design_creation.pdf

 

I also ran across a document which had the definition of the dropped packet signal, which ended up not being what I thought it was.  I assumed the packet was invalid, instead it represents the packet does not match the device's MAC address.  That provided a huge amount of insight. 

 

Since the Flow Control for RX and TX was listed as enabled in the ML505 document, I went into the constraints and enabled those parameters.  I also noticed the example design had the default Unicast MAC address of all zeros.  I quickly changed that to the address listed in the ML505 document as well.

 

I then loaded the design, went into Windows, and used the arp -s ipaddress macaddress line from the guide.  After completing those steps, my ping to the device properly returned a ICMP packet with reversed MAC addresses.

 

Problem solved.  The ML505 document was actually the best description of how to get started with the core I had seen yet; though it too misses a step of assigning that MAC address.  

 

I thought I'd post my solution just in case anyone else runs in to this! 

 

View solution in original post

7 Replies
gszakacs
Professor
Professor
9,939 Views
Registered: ‎08-14-2007

You might try to build the example design that comes with the wrapper core.  That just

loops packets from the receiver back to transmitter with a swap in the MAC address.

You can use someting like WireShark on a P.C. to look for the echoed packets.

 

HTH,

Gabor

-- Gabor
0 Kudos
dguisinger
Observer
Observer
9,937 Views
Registered: ‎12-26-2009

Thanks Gabor,

Actually this is the example design.  Since the example leaves a lot of unmapped pins at the top level (status pins, etc), I wrapped the example design.  I also added a clock divider to create MDC since MDC on the example design is an input and on my design it has to be driven from the FPGA.

 

Unfortunately everything you are suggesting is what I'm already doing. 

 

Dan 

0 Kudos
gszakacs
Professor
Professor
9,933 Views
Registered: ‎08-14-2007

O.K.

 

When I used the wrapper I had a Marvell PHY with all settings strapped via resistors,

so I didn't include the host interface.  I did find that I needed to change a setting for

EMAC0_PHYINITAUTONEG_ENABLE and EMAC1_PHYINITAUTONEG_ENABLE

which defaulted to FALSE but needed to be TRUE to start up.  I used both halves

of the TEMAC in my design.

 

Regards,

Gabor

-- Gabor
0 Kudos
dguisinger
Observer
Observer
10,754 Views
Registered: ‎12-26-2009

Alright, I figured it out!  

I was correct in that the SGMII link was reporting back as valid and connected.  I opened a webcase and while it didn't directly solve it (it was mostly the same suggestions as above) an additional getting started document was provided:

http://www.xilinx.com/products/boards/ml505/ml505_92i/docs/ml505_sgmii_design_creation.pdf

 

I also ran across a document which had the definition of the dropped packet signal, which ended up not being what I thought it was.  I assumed the packet was invalid, instead it represents the packet does not match the device's MAC address.  That provided a huge amount of insight. 

 

Since the Flow Control for RX and TX was listed as enabled in the ML505 document, I went into the constraints and enabled those parameters.  I also noticed the example design had the default Unicast MAC address of all zeros.  I quickly changed that to the address listed in the ML505 document as well.

 

I then loaded the design, went into Windows, and used the arp -s ipaddress macaddress line from the guide.  After completing those steps, my ping to the device properly returned a ICMP packet with reversed MAC addresses.

 

Problem solved.  The ML505 document was actually the best description of how to get started with the core I had seen yet; though it too misses a step of assigning that MAC address.  

 

I thought I'd post my solution just in case anyone else runs in to this! 

 

View solution in original post

gszakacs
Professor
Professor
9,901 Views
Registered: ‎08-14-2007

That's great!  I forgot to mention that when I ran the example code (echo demo) I had

built the core without MAC address filtering enabled, so the default MAC address, which

I seem to remember was AA BB CC DD EE FF or some such, didn't come into play.

 

Regards,

Gabor

-- Gabor
0 Kudos
josipxilinix
Visitor
Visitor
7,949 Views
Registered: ‎01-16-2011

 dguisinger and all

 

Would you know is it possible to run the EMAC example design without MDIO, SGMII mode, no processors, stand alone application (*example_design, *locallink, FIFO modules included, but not MDIO) ?

 

I've been trying to get EMAC0 (not EMAC 1, is that correct, EMAC 0 is connected to Alaska), Alaska, SGMII mode working but without success. I am using XUPV5 (aka ML 509, xc5vlx110tff1136 device), RJ-45 an a laptop, ISE 12.4.

 

The only thing I see working is Rx LED in 10Mb full duplex configuration when using a ping. Even than DUPLEX LED is off. If I change link speed on my laptop to 100/1000, Alaska switches correctly however RX LED is on all the time (I also see NIC on my laptop sending some I guess negotiation or ARP packets constantly. Therefore Rx LED is on all the time.

 

I tried more or less everything I found on this forum. UCF is modified, AUTONEG is turned on, UNICAST address changed (I did not use MAC filtering). It looks as if there is no activity on any of Rx inputs as if Alaska is not in SGMII mode (I use SGMII juper configuration).

 

Is there anything else I am missing? Perhaps Alaska needs (meaning must) to be configured via MDIO to know it is in SGMII mode?

 

 

UCF updates:

 

CONFIG PART = xc5vlx110tff1136-1;

INST "*GTP_DUAL_1000X_inst?GTP_1000X?tile0_rocketio_wrapper_i?gtp_dual_i" LOC = "GTP_DUAL_X0Y4";

Net "MGTCLK_N" LOC = "P3";
Net "MGTCLK_P" LOC = "P4";

Net "TXP_0" LOC = "M2";
Net "TXN_0" LOC = "N2";
Net "RXP_0" LOC = "N1";
Net "RXN_0" LOC = "P1";

INST *?v5_emac EMAC0_PHYINITAUTONEG_ENABLE = TRUE;


NET "PHY_RESET_0" LOC = J14;

0 Kudos
josipxilinix
Visitor
Visitor
7,948 Views
Registered: ‎01-16-2011
I also know that EMAC0PHYSYNCACQSTATUS is on. That probably only tells that the internal 125MHz clocks are running.
0 Kudos