[ethmac] CRC Calculation

["Christian R. Brecht" <Brecht@cbedv.com>]

Hi all! I forward this to the list!
From: Clive Bolton


Christian.....

I tried sending this to the site, again, but I seem to be missing something.
If you want, you can forward this on to the site for other people to read.

======================================
Christian:

I recently answered a question another reader had about CRCs, but I sent it
directly to him, and it wasn't posted on the site. This note is a composite
of a couple of emails I sent to him.....

I'm a reader of the opencores mailing list and I'm in the process of writing
a much simplified version of the core, for a 10/100/1gig point-to-point
application. I'm not interested in implementing the higher level of the
protocol or the retransmission aspects, just the low-level transmit and
receive. I have the code written in Altera's AHDL (similar to VHDL), which
gives me the flexibility I need to write good, fast, pipelined RTL code so I
can get it working in a low-end FPGA. The design has been implemented, and
simulated to run at the required speed (125MHz), but has not been put into
actual hardware. The design I'm working on requires some other sections, so
the full system won't be physically tested for a few months.

The details of the CRC process are a bit obscure. There is an amazing site
that gives you Verilog or VHDL code for CRC generation:

http://www.easics.be/webtools/crctool

Unfortunately, I'm not going to be able to help you very much on the math
end of things. I am trying to get a design working and frankly haven't been
thinking about the math too much. At one point, I understood how CRCs
worked, but now I just accept them and am willing to work with a
prefabricated solution. On the plus side, there are some pretty good sites
on the web, if you just search using Google. Basically, the XORs are
additions/subtractions, and the shifts are multiplies/divides

I used an 8-bit datapath for a few reasons. One is that the gigabit PHY
chips all seem to have 8-bit paths running at 125MHz. The second reason is
that the packet is processed in 8-bit chunks, starting from the SFD, so it
is, at least for me, easier to think about it in 8-bit chunks. This was
helpful in debugging and synchronizing the pipeline stages. [Note: although
it might be tempting to consider slowing down things by using a 16-bit data
path instead, it probably won't work, because I don't think there would be a
way to handle an odd number of words going into the CRC generator].

Here is a good site that gives an easy to understand tutorial on 10/100
Ethernet. 1gig is the same, except the inter-packet time is different and
the minimum data size is 512 bytes:

http://www.chipcenter.com/circuitcellar/march02/c0302ts2.htm

However, even if you have this, there are a few pieces missing. It took me a
bit of searching on the web, some reading, and a careful disassembly of the
opencore sourcecode, before I finally understood what was happening. Here's
what you have to do:

XMIT SIDE
¡P Initialize the CRC register to all 1's
¡P Calculate the CRC on the outgoing payload, starting at the Destination
and ending with the data. Send the 1's complement of the CRC, MSB first
RCV SIDE
¡P Initialize the CRC register to all 1's
¡P Calculate the CRC on the incoming payload, starting at the Destination
and ending with the CRC (you must include the CRC in the calculation).
¡P Compare the result to the "magic number:" CRC_MAGIC_NUMBER = H"C704DD7B"
That's it. It really isn't so bad. Even though its pretty easy to find the
CRC calculation, no one tells you about the initializing, inverting, and the
magic number.

Although I haven't gotten this to hardware yet, I do have the transmitter
and receiver hooked up as a test case and can send data through.

Good Luck.


- Clive

PS:  Interestingly enough, although I didn't use any of the code on the
Opencores website, seeing the design get done and reading the questions and
answers was surprisingly helpful.  It gave me the confidence that the design
was within reach, and helped me find good source information for
understanding the application. BTW: the main reason that I didn't use the
site's code was that I had to get the design running at 125MHz in a PLD,
which required some careful thought as to how to segment the system
pipeline.



Clive Bolton, Engineer
Bolton Engineering, Inc.
72 Stone Place
Melrose, MA  02176
(781) 662-1670 voice
(781) 662-1680 fax
http://www.altera.com/products/design_services/acap/consultants/acp-bolton.h
tml

<cbolton@world.std.com>



--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml