Re: CRC issues with Stratix II

Altera_Forum · ‎03-10-2008

Hello all,

I'm working on a project that is requiring the generation and checking of CRC values for gigabit ethernet communication on a board equipped with a Stratix II GX transceiver. As such, I am making use of the Altera CRC Compiler v7.2 megafunction. I believe that my transceiver is currently configured properly, as I have been able to capture packets transmitted to my development board from my workstation and verified through Wireshark that the packet captured matches that which was transmitted.

What appear to be configured improperly are the CRC generation and checking modules. I have a test packet that was captured at the output of the Stratix receiver (and as such has not had the CRC stripped off) and have been using this packet to attempt to properly recreate the CRC. I have made little progress in this endeavor, though, and was wondering if anyone has successfully completed a similar task.

I suspect that my problem might be with one of the following pieces of information:

I currently have the CRC compiler configured with the "Process low-numbered bit in each symbol first" option selected. I believe this is necessary because the IEEE specification for Ethernet states that the preamble section should consist of 7 octets of 0xAA followed by the start frame sequence 0xAB. When receiving data from the Stratix II, though, I am observing 7 octets of 0x55 followed by 0xD5, which are 0xAA and 0xAB in bit-reversed order. For this reason, I also selected the "Bit-swap checksum" option for the output side of the function. The final option I am not completely sure of is the initial value- for now, I am initializing the CRC to -1 (all F's).

I do not think it to be the cause of the problem, but I also have the input set at a datapath of 8 bits, 1 symbol per word, and inputs registered as Avalon-ST inputs. The CRC code selected is CRC-32, which has a polynomial of x^32 + x^26 + x^23 + x^22 + x^16 + x^12 + x^11 + x^10 + x^8 + x^7 + x^5 + x^4 + x^2 + x^1 + 1. The function is optimized for area, has an offset of 0 for the number of leading bits, and does not negate the checksum at output. Also, the "Register all outputs" option is selected. The startofpacket, endofpacket, and datavalid signals are all controlled such that the CRC is generated starting at the first byte of the address field and ending at the last byte of the data field.

For reference, the original packet captured is as follows:

0 : BC;

1 : 50;

2 : FB;

3 : 55;

4 : 55;

5 : 55;

6 : 55;

7 : 55;

8 : 55;

9 : 55;

10 : D5;

11 : FF;

12 : FF;

13 : FF;

14 : FF;

15 : FF;

16 : FF;

17 : 00;

18 : 30;

19 : 1B;

20 : 44;

21 : 2C;

22 : 98;

23 : 08;

24 : 00;

25 : 45;

26 : 00;

27 : 00;

28 : 1D;

29 : FB;

30 : D3;

31 : 00;

32 : 00;

33 : 80;

34 : 11;

35 : 21;

36 : 52;

37 : 0A;

38 : 08;

39 : 04;

40 : 13;

41 : A3;

42 : FF;

43 : FF;

44 : FF;

45 : FF;

46 : 07;

47 : 9B;

48 : 27;

49 : 10;

50 : 00;

51 : 09;

52 : 6D;

53 : 86;

54 : 46;

55 : 00;

56 : 00;

57 : 00;

58 : 00;

59 : 00;

60 : 00;

61 : 00;

62 : 00;

63 : 00;

64 : 00;

65 : 00;

66 : 00;

67 : 00;

68 : 00;

69 : 00;

70 : 00;

71 : 00;

72 : 1F;

73 : FB;

74 : F7;

75 : A1;

76 : FD;

77 : F7;

78 : BC;

79 : 50;

80 : BC;

81 : 50;

The CRC in this case is found between 72 and 75: 0x1FFBF7A1. When generating the CRC via the megafunction, I am getting a value of 0xB55AC8F9.

Has anyone had success in creating a CRC for 8 bit wide Ethernet data using the CRC Compiler megafunction? If so, any ideas about what I might be doing wrong?

Altera_Forum · ‎03-11-2008

I haven't worked with the megafunction directly, but have done a CRC on my own. It had to match the simulation of another CRC generator, and was one of the worst projects I've worked on, as far as not approaching it correctly. The largest problem is that what you get out is either correct, or completely wrong, with nothing in between to give you an idea of what's working and what isn't. So if I had an error in my XOR tree(which I did), all the byte flipping, byte swapping(I was feeding 2 bytes at a time), inverting, power-up changing became a distraction. In your case, I assume it is correct, but I would add some basic control signals to manually flip the byte order and/or invert it coming in. On the output side I would bring out all four possibilities(untouched, flipped, inverted, flipped and inverted). Then run the same packet through multiple times in a simulation, and with your control signals trying every combination of going in. (I've seen a couple CRCs and, including mine, they all powered up to 1, so start with that, but if none of this works, try the inverse.) I know this sounds like a really dumb way to do it, but if you'll spend/waste a lot more time trying to figure out how the CRC works or intelligently figure out "what is wrong", when you're just trying to get it to work.