Page Title

How to handle CRC errors

CRC32 is extremely good at detecting errors. If the CRC error flag is not
asserted at the end of a packet, you can be very certain that the packet has
been received correctly. But what do you do if the CRC error flag goes up ?
Here are the choices.

1. Retry. Request to have the faulty packet resent. This is effectively what
TCP/IP does. This strategy makes sense if the packet contains a business
transaction or executable code. If the packet can contain critical data, then
retry is the proper choice.

2. Ignore the error. If the packet contains a JPEG file, it probably won't
matter if some bits are mangled. Packets which contain casual data can
probably be used regardless of CRC errors. Packet data without command or
control bytes can be handled this way.

3. Interpolation or concealment. Packets which are part of a data stream, e.g.
video, audio, cannot be resent since that would cause more damage than the
bad packet. The better option is to interpolate from or reuse previous good
packet data. Real time data from sensors can be handled by method 2 or 3.

4. Reset and restart the system/subsystem. This choice seems drastic but is
appropriate where the system can be restarted quickly and where correct
system operation is critical. Real time systems which must stay in sync and
provide correct ouputs may resort to system resets upon detection of any
error. This is a very specialized class of systems.

So CRC error handling depends on the nature of the packets and
characteristics of the packet processing system.

Defining Your Own Protocol

One of the great advantages of using a ChipEnet MAC core is the ease of
defining your own protocol. The MAC core and the Socket interface combine
to deliver blocks of bits between the FPGA and the PC host. The meaning of
these bits can be anything. Registers, memories, and state machines can be
directly controlled from code running on the PC. If a reliable connection, a la
TCP, is desired, a simplified sequence number handshake can be
implemented. Interrupts and flags can be implemented remotely.

Importance of Low Gate/LUT Count in an IP core

FPGA resources such as LUTs or BLOCK RAMs are expensive. Unlike an asic
where the internal gates and rams can be arbitrarily configured, limited only
by a die size which is frequently determined by the IO count, a FPGA has a
fixed number and configuration of LUTs and rams. Depending on the match
between the FPGA and the architecture, there may not be enough of one
resource and a surplus of another resource. Given the higher prices of FPGAs
compared to asics, it is important to conserve the usage of these fixed LUTs
and rams. Thus having a small footprint IP core is essential.

The second consideration is that the higher the number of LUTs and rams
used in a FPGA design, the longer the compile/place/route time. An iteration
for a large FPGA can be significant. Again, smaller IP cores mean faster
iterations.

SM100-128 - 128 byte Fifos 100 Mb/s Ethernet MAC
Number of occupied Slices:                       374
Total Number 4 input LUTs:                      592
Total equivalent gate count for design: 13,855

SM100-2K    - 2K byte Fifos 100 Mb/s Ethernet MAC
Number of occupied Slices:                          289
Total Number 4 input LUTs:                         440
Number of RAMB16s:                                       2
Total equivalent gate count for design:    4,721

SM1000-128 - 128 byte Fifos 1000 Mb/s Ethernet MAC
Number of occupied Slices:                           349
Total Number 4 input LUTs:                          574
Total equivalent gate count for design:   13,694

SM1000-2K    - 2K byte Fifos 1000 Mb/s Ethernet MAC
Number of occupied Slices:                          266
Total Number 4 input LUTs:                         410
Number of FIFO16/RAMB16s:                           2
Total equivalent gate count for design:    4,680

Ethernet as Chip Interface ???

Chip to chip interfaces are usually fixed direct wiring. A collection of data,
control and mode signals. As long as the requirements and needs are known
and never changes, the traditional way of connecting chips is optimal. This
can be compared to programming in assembly language without using
standardized APIs or libraries. Very efficient in size and speed but almost
impossible to change.

For designs where the requirements are not fixed or uncertain, or where the
designs need to support future upgrade, or where the designs need to
interface to a variety of other designs/devices, an Ethernet MAC offers a very
simple, flexible, fast and widely supported interface. A chip with an Ethernet
MAC can be connected to any other chip with a compatible Ethernet MAC.
PHYs are not necessary for intra-board connections. Design reuse is made
easier.

As an interface, an Ethernet MAC offers full duplex, source synchronous
point to point connections. This is the ideal topology for a high speed
interface. Especially if LVDS or PECL drivers are used, clock frequencies of
over 1GHz can be readily achieved with an asic implementation. Higher
bandwidth is the result compared to a wide data bus with multiple drops.

Debugging is also easier because a simple program running on a PC can
directly talk to the FPGA. Verify correct packet data in software first and then
connect the FPGA to another FPGA.

An Ethernet MAC can also reduce the interface pin count. A direct wired
interface with 32 or 64 data bits can easily consume 100 or more pins, thus
forcing the use of large flip chip packages. In contrast, an Ethernet MAC only
use as little as 12 pins. A reduction in pin count means lower chip
cost, faster board design and much, much easier debugging( ever tried
connecting a logic analyzer to a 64 bit data bus on a flip chip package ? )

Self Contained Diagnostic Module

In order to easily verify the operation of a ChipEnet MAC core in your FPGA
system, a self contained diagnostic module is included with every design
package. This diagnostic module connects to the FPGA interface portion of
the MAC and allows ping and auto generated packets. Packets written to the
MAC can be returned automatically. The diagnostic module can also
automatically generate packets.

The optional use of this diagnostic module allows quick verification that the
ChipEnet MAC core is working correctly in your FPGA system and the
associated PCB wiring to the RJ45 connector is correct.

To use, just compile the included top level design file and then program your
FPGA. Connect a Cat5 cable between a PC and your FPGA system and you're
done.

The diagnostic module + MAC core is now ready to communicate with the
supplied demonstration program running on a PC. Source code is included.

PHY & RJ45

The PHY is a chip external to the FPGA that is needed to drive the cat 5 cable.
National DP83847 is an example of a 100Mb/s PHY chip that can be used with
the ChipEnet 100Mb MAC IP cores. The National web site also contains PCB
layout guide and extensive design documentation. Other similar PHYs may
also be used.

Pulse Engineering J0026D01B is a RJ45 connector with integrated magnetics
and leds. It is very simple to use. Other RJ45 connectors may also be used.

If you are using the MAC to connect on board chips only, i.e. no cable
driving, then a PHY is not actually needed. The MACs can be directly
connected to each other. Although if the wiring is long or goes across a
backplane, LVDS drivers and receivers may be needed.

Here is a simple example schematic showing the use of the National DP83847
100Mb.s PHY chip + Pulse RJ45 connector with a FPGA.

For 1000Mb/s designs, National DP83865 PHY can be used with Pulse
Engineering JK0654218Z RJ45 connector. Here's a example schematic
showing the usage of the National PHY and the RJ45 connector.