ChipEnet.com - Real Time Ethernet Switch Fabric
Application Notes
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
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.
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.
Be Like Cisco, Design 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
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.
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 ? )
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
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.
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
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.
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
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.
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
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.