1. Home
  2. Field-Programmable Gate Arrays
  3. Using ethernet on a Xilnx board (Help appreciated)

Using ethernet on a Xilnx board (Help appreciated)

First of all let me apologize for any thing of things I"m ignorant about here. Up until very recenty my programming experience was limited to higher level programming language: Python, PHP, Perl, hell at this point I'd consider C high level.

Anyway.

I'm trying to use a Xilinx XUPV2P board to send data over ethernet. The board uses the intel LXT972alc to control the PHY and provide a MII interface.

What I attempted to do was to build a valid packet, assert enable on the pin labeled TX_ENABLE and feed that packet nibble by nibble to the intel chip.

The packet itself is UDP datagram using IP. I put in the preamble, ethernet header, IP header, UDP header, data and checksum. I used the Ethernet broadcast address.

To try to test his out I thought I would plug my computer and the board into a router. I have a C program that I wrote which picks up and prints UDP packets sent to the appropriate port. I put the IP address of my computer as when plugged into the router and tried to send the packets there. However, no data seems to be getting through. Furthermore, the absence of link up lights on both the router and the board seem to indicate that the bord is not able to link to the router.

For reference I programmed this in Verilog (which I learned about 2 weeks ago).

If anyone could provide me with advice I would much appreciate.

Thanks,

---AchatesAVC

Reply to
AchatesAVC
Loading thread data ...

If it turns out that the Ethernet components are not working, I will consider buying the board from you (assuming nothing else is broken).

The V2P has 2 onboard PPC405. Have you tried using an embedded core? Network stacks are not trivial components.

Reply to
MikeWhy

You should have said so first.

I don't know about the PHY you use, but usually after reset, an Ethernet PHY needs to be talked to softly using the MII protocol, which you then use to setup autonegociation, bring the link up, after which the LED will light on your router and you will be able to query the PHY to discover the actual link capabilities (duplex, speed, etc) and send and receive data. The PHY will also raise interrupts, which you should process, when the link state changes : disconnection, reconnection, etc.

From what you say it seems you forgot to do this. In this case the PHY will simply stay in power down mode and frustrate you.

You will need to have a look at the Linux kernel sources for an example, use the 2.4, the code is simpler than in 2.6, pick a NIC driver and grok.

Ah, and yeah, you'll need somse sort of CPU to go through that initialization routine.

Reply to
PFC

Thanks much for the replies.

Would it just make more sense to get an IP core for this if I need the whole thing to be reliable?

-AchatesAVC

Reply to
AchatesAVC

Hm, well, if you want to do some more involved ethernet transfer (anything besides really basic stuff) yes you'll want an Ethernet MAC and some software to configure it and control it. If you just want to send raw data you can get away with configuring the PHY using the CPU and then sending pre-canned frames just like you've been doing.

Xilinx has one in EDK, also one is on OpenCores.

In my design I used a LAN9117 MAC+PHY chip from SMSC. I warmly recommend this chip to anyone, it is easy to use and will handle 100 Mbps full duplex without dropping packets. However you MUST NOT put it on a shared bus with, for instance, the RAM, because its bus is slow, and at full bandwidth it is busy a large percentage of the time. This is absolutely not a problem, unless it kills your memory bandwidth by the simple fact of sitting on the same bus !

Also the CPU interface is very simple, it's really a no-nonsense chip (unlike the LAN91c111 which is a PITA).

Of course it eats more IO than a PHY, but it eats less slices than a MAC in the FPGA... (and it works)

Reply to
PFC

Actually I use Microblaze, but I was thinking if he doesn't need a CPU he could use PicoBlaze, then I remembered he uses a chip with a PPC core...

Reply to
PFC

PFC wrote: (snip)

(snip)

Depending on the definition of CPU. It could presumably be done by a state machine which may or may not follow one's definition of CPU.

-- glen

Reply to
glen herrmannsfeldt

At a first guess this seems like the PHY is still in reset. Doublecheck that you have setup the reset signal correctly in your design. (UCF file and polarity respectively.)

If that seems ok you can try to talk to the PHY via the MII as another poster suggested.

/Andreas

Reply to
Andreas Ehliar

he

Does anybody out here know where to find a ethernet MAC implementation for Picoblaze? It would make a very lightweight eth. implementation, which would suit my Spartan3E starter kit board perfectly. Microblaze is a bit too resource-hungry for my project.

Bart

Reply to
bommels

Hey,

Have a look at

formatting link
they have IP cores which will allow you to use the ethernet interfaces very easilly.

Regards,

Pat

"AchatesAVC" a écrit dans le message de news: snipped-for-privacy@59g2000hsb.googlegroups.com...

Reply to
Pat Magnet

Pat, I am learning Verilog as well, my guess is that you may not handle correcly NLP/FLP stuff, that's the reason the interface seems down.

Take a look here:

formatting link

"Keeping the link alive Even if no packets are sent on a 10BASE-T cable, a pulse has to be sent periodically (called the "Normal Link Pulse" or "NLP"). It is used to keep the connection "alive". A pulse needs to be sent every 16ms or so.

The NLP can also be replaced by a "Fast Link Pulse" (FLP) burst, during a process called "auto-negotiation". The FLP carries information about the capabilities of the sender, so that the hardware at both end of a cable can negotiate the link parameters, like the speed and the half/full duplex status."

Giuseppe Marullo

snipped-for-privacy@iname.com

Reply to
Giuseppe Marullo

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.