Thanks,
Ven.
Hi Ven,
If you require compatibility with IPv4, then look at the algorithms
specified in RFC 791. (Note that IPv6 doesn't have a header hecksum -
it is assumed that the layer 2 checking is adequate.)
If you don't have any requirement for compatibility, then I suggest
putting the checksum at the end of the packet, rather than at the
beginning. This makes it a lot easier to generate in hardware from
"streaming" data. (If the checksum is at the beginning of the packet,
you need to be able to hold the entire packet in memory before you can
start transmitting it. A curse on the protocol designers who only
think in terms of software implementations.)
HDLC/PPP, etc (RFC 2615, ISO 3309, ITU-T Q.921, etc.) describe packet
formats that have a CRC at the end of the packet, and may be more
applicable to your needs.
http://www.ietf.org for the RFCs
Regards,
Allan.
And ignore the RFC that explains how to do it in hardware.
That one explains how to make a 1's-complement adder, which automatically
performs the end-carry at each stage. However:
- It's only one clock faster than using a 2's-complement adder, registering
the carry out, and using that as the next carry-in. That's one clock per
PACKET, not per word or anything.
- It's a much larger circuit.
- It forces you to get the addition algorithm right, rather than just coding
a plus sign and letting the synthesis tool figure it out.
- It completely defeats your FPGA's fast carry chains used for optimizing
2's-complement addition, and for this reason, may run at a MUCH lower
clock rate.
--
Hi Allan,
I am required to stick the checksum in that particular location in
the IPv4 format and not at the end of packet. And that is an issue to
me. So, if you could link to some source code or similar
implementations, that'd be great.
Thanks.
Ven.
Ven,
One doesn't give away source code (against company policy, etc.)
Are you having trouble understanding RFC 791?
The relevant text of http://www.ietf.org/rfc/rfc0791.txt is:
"The checksum algorithm is:
The checksum field is the 16 bit one's complement of the one's
complement sum of all 16 bit words in the header. For purposes of
computing the checksum, the value of the checksum field is zero."
That's all there is to it. Any implementation would be tied in with
details of your bus format, etc. You're going to have to write this
one yourself.
Allan.
The TCP / UDP checksum is somewhat tricky and needs psudo header sum
calculation and addition of that in main checksum.
See if you can do a checksum on IP fragmented packets for TCp and UDP
in hardware. It will require a lot much care. Hope I helped you
Regards
Yang Li
yang...@yahoo.co.uk
allan_herrim...@agilent.com (Allan Herriman) wrote in message news:<3b493ef3...@netnews.agilent.com>...