[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[linrad] Re: Linrad via Ethernet


Then, finding a creative way to load the data directly from the ADC into the Ethernet NIC will be key to how many cycles will be needed on the MCU. (E.g., setting the NIC in bulk write mode, toggling the ADC data onto the bus, and toggling the NIC to latch the bits; a la DMA controller style.)

There's a much easier way of doing it, if you don't mind ending up with a slightly hackish solution.

An Ethernet NIC[1] can be separated into a MAC and a PHY. The MAC handles the Ethernet protocol (preamble, collision backoff, checksum) and the communication with the processor. The PHY connects to the 'wire' (which might be UTP, fibre or others). The link between MAC and PHY is standardized per 802.3 in the Media Independent Interface, or MII. MII is extremely simple: there's a data path (typically 4-bit TX, 4-bit RX, both with clock) and a control path (think 3-line serial interface). Separate PHY chips are available from several vendors; DigiKey have them available in qty 1.

Now, if you can guarantee that the link is ALWAYS full-duplex 100base-TX, you can omit much of the complexity of the MAC. This condition is easy to satisfy; most cheap modern Ethernet switches always negotiate to full-duplex, and a direct (cross-)cable to a PC NIC is easily settable to anything you like. With such a 'private' link, you can basically transmit any time you like (as long as you stick to proper Ethernet frames). This is what I have in mind:

ADC (+ AD6620/GC4016) -> FIFO -> CPLD -> PHY -> cable

The FIFO buffers the ADC data until enough is available to fill an Ethernet frame; the CPLD acts as a mini-MAC, providing an Ethernet header and checksum.

Protocol-level implementations are, ranging from simple/ugly to complex/elegant:

1) Put all data in Ethernet broadcast frames, and use libpcap on the receiving PC to extract the data. Can be done in (estimated) 64-128 macrocell CPLD (almost the smallest you could find)

2) Put all data in UDP/IP multicast datagrams. I need to investigate this further, this might be the best 'middle ground' solution. Can be done in (estimated) 128 macrocell CPLD

3) Put all data in UDP/IP unicast datagrams. This requires programming of the MAC address of the target PC in some way (or the IP address, but then we need ARP to work). Can be done in (estimated) 128-256 macrocell CPLD.

4) Create a TCP/IP server to serve the data. Very pretty, but likely requires a FPGA due to the added complexity.

Note that options 1 and 2 (and 3, if ARP isn't used) only require a transmit path.

Why is this better than using a traditional processor + Ethernet card/chip ? First, the data paths are much simpler. Instead of having to shuffle ADC data through the CPU to the NIC (or devise hardware to do ADC->NIC DMA), the data path is simply a linear stream. This allows for higher data rates, too: PCs not older than, say, six years can easily receive all packets from a saturated Fast Ethernet-link, while most embedded CPUs would be hard pressed to produce that much data. Finally, it is easy to synchronize the entire chain from ADC to PHY to the same TCXO/OCXO, reducing the digital noise level coupled back to the ADC input.

I'm working on a design like this at the moment. I had originally planned to use an embedded CPU (the Atmel AT91RM9200, 200MHz with integrated Ethernet MAC) until I came up with this direct interface. If/when I get it to work I plan to release the layout/schematics.

Thoughts ? Ideas ? Suggestions ?


[1] List of acronyms used:
 802.3: The IEEE standard/committee defining Ethernet
 ADC: Analog/digital converter
 ALWAYS: not an acronym, just me using all caps for emphasis
 ARP: Address Resolution Protocol
      (used on Ethernet to get a MAC for a given IP address)
 CPLD: Complex Programmable Logic Device. A chunk of gates on a chip
       which can be interconnected through (reprogrammable) firmware
 CPU: Central Processing Unit
 DMA: Direct Memory Access. Transfer of data without involvement of the CPU
 FIFO: First In First Out. Buffer memory used to adapt input and output rates.
 FPGA: Complex Programmable Logic Device. A large chunk of gates on a chip
       which can be interconnected through (reprogrammable) firmware
 MAC: Media (/ Multiple ?) Access Controller
 MII: Media Independent Interface
 NIC: Network Interface Card (/ Controller ?)
 OCXO: Oven Controlled Crystal Oscillator
 PHY: PHYsical interface (to the actual 802.3 medium)
 RX:  Receive
 TCP: Transmission Control Protocol
      (a very common stream-based Internet protocol, as used by web servers)
 TCXO: Temperature Controlled Crystal Oscillator
 TX:  Transmit
 UDP: User Datagram Protocol
      (a packet-based Internet protocol, as used by Internet radio stations)
 UTP: Unshielded Twisted Pair
      (cable with 8 conductors in 4 pairs, each pair is twisted together
       to increase interference rejection. Commonly used in Ethernet)
[my first post ever with a list of acronyms...]
LART. 250 MIPS under one Watt. Free hardware design files.

This message is sent to you because you are subscribed to
 the mailing list <linrad@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to  <linrad-request@xxxxxxxxxxxxxxxxxxxxx>