crc on only data or including the address

Hello everyone,
I am trying to transfer data between on board ethernet PHY and the PC.
For that i am implementing ethernet packet generator in the fpga. The
MII interface on the fpga has transmit data bus of width 4 bits. So i
am sending 64 bytes  of frame from the fpga with the most significand
bit transmitted first.

As you all know ethernet frame consists of

preamble,startframe,destination ad,source ad,length/type,data,crc

Is this what each block consists of

preamble - 7 bytes - x"5";

startframe - 1 byte -x"5d";

destination - 6 bytes - PC mac address

source -    6 bytes -- any choice of fpga mac.(any value)

length/type - 2 bytes -- "0000_0000_0100_0000"

data -      --38 bytes -- any value

crc -         4 bytes


2) Is CRC implemented on only data or on whole frame?

3) Can anyone guide me on how  crc  is computed?

4) If CRC is wrong, will the PHY still transmit the data onto the PC.

I would request you to please answer my questions as soon as possible.

thanks
ashwin

ashwin wrote:

> 2) Is CRC implemented on only data or on whole frame?

The fcs field is calculated for the whole frame on transmit.
It is checked using the whole frame + fcs on receive.

> 3) Can anyone guide me on how  crc  is computed?

Here's how it is checked
http://groups.google.com/groups?q=vhdl+crc_shift

> 4) If CRC is wrong, will the PHY still transmit the data onto the PC.

If it didn't you would never see a bad fcs.

> I would request you to please answer my questions as soon as possible.

I'm typing as fast as I can, however,
that question has increased the response time slightly.

          -- Mike Treseler

Ashwin, I suppose English is not your native language. Otherwise you
would know that "request" is a very strong word, kind of like
"command", used only by a superior (or an unfriendly institution).
Adding "would" and "please" does not eliminate the air of arrogance...
Of course, you did it out of lack of knowledge.
Peter

Ashwin, I suppose English is not your native language. Otherwise you
would know that "request" is a very strong word, kind of like
"command", used only by a superior (or an unfriendly institution).
Adding "would" and "please" does not eliminate the air of arrogance...
Of course, you did it out of lack of knowledge.
Peter

Mike Treseler wrote:
> ashwin wrote:
> 
>> 2) Is CRC implemented on only data or on whole frame?
> 
> 
> The fcs field is calculated for the whole frame on transmit.
> It is checked using the whole frame + fcs on receive.
> 

Slight precision : I don't think the preamble and sof are used for the
fcs. Or am I wrong ?

> 
>> 4) If CRC is wrong, will the PHY still transmit the data onto the PC.
> 
> 
> If it didn't you would never see a bad fcs.

Well, the corruption could happen on the wire ;)

But still, the PHY don't care. For it to not transmit invalid frames
would require it to buffer the whole frame internally before sending ...


	Sylvain

ashwin wrote:

 >hi Mike,
 > Thanks for sending a reply for few questions on ethernet. I just
 >wanted to confirm with you that , even though crc computation is wrong,
 >we should be able to see the data capture in the PC right?

There are many reasons you might not see data on
your pc, but I don't think the fcs value is your problem.

 > Doesnt the Ethernet PHY reject the data if the CRC is wrong?

A router might throw away a bad packet
but a phy is not that smart. FCS generation
and validation is done in the Media Access Controller.

 > Because i am  unable to detect the data coming out from the
 > ethernet PHY on the fpga board.

Get out a scope and see if anything is wiggling.

 > I would like to discuss more on a particular data sheet on DP83847
 > ETHERNET PHY.

Read the data sheet again and do a little debugging first.
But post your questions here. I don't check that mail
account regularly.

      -- Mike Treseler

Hi, ashwin.

>2) Is CRC implemented on only data or on whole frame?

>3) Can anyone guide me on how  crc  is computed?
as far as I know, CRC is applied from destination field to data field.
exclude the opening flag, preamble, etc. but include the addresses.

>4) If CRC is wrong, will the PHY still transmit the data onto the PC.
If I'm not mistaken, CRC is calculated by dividing the whole number by
certain polynomial, which is different for each kind of CRC (there are
CRC-32, CRC-16, etc). As you have 4 bytes FCS field, I guess it use
CRC-32, and the polynomial is:

g(x)=x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x1+1.

the remainder of the division is considered as CRC. the checksum has to
be unique for each data.

please refer to Ross Williams' article for better explanation.. or the
book of Stalling (Data communication).. or just hit the google! you'll
find plenty of them.

if CRC is false, the frame is assumed to be corrupted. thus the sender
have to send it again.  error control, that's what CRC's for.


-ivan-

On 26 Oct 2005 16:12:34 -0700, "ashwin" <achiluka@gmail.com> wrote:
>Hello everyone,
>I am trying to transfer data between on board ethernet PHY and the PC.
>For that i am implementing ethernet packet generator in the fpga. The
>MII interface on the fpga has transmit data bus of width 4 bits. So i
>am sending 64 bytes  of frame from the fpga with the most significand
>bit transmitted first.

My understanding is that the data is shifted out LSB first, which would
require you to send the low order 4 bits first.


>As you all know ethernet frame consists of
>
>preamble,startframe,destination ad,source ad,length/type,data,crc
>
>Is this what each block consists of
>
>preamble - 7 bytes - x"5";

you mean x"55"

>
>startframe - 1 byte -x"5d";

Given my belief that data is sent LSB first, this would be x"d5"

>destination - 6 bytes - PC mac address
>
>source -    6 bytes -- any choice of fpga mac.(any value)
>
>length/type - 2 bytes -- "0000_0000_0100_0000"
>
>data -      --38 bytes -- any value
>
>crc -         4 bytes

Actually, what is sent is the FCS, which is bit reversed
version of the CRC.

>2) Is CRC implemented on only data or on whole frame?

CRC starts with the destination address

>3) Can anyone guide me on how  crc  is computed?

From the spec:

3.2.8 Frame Check Sequence (FCS) field

A cyclic redundancy check (CRC) is used by the transmit and 
receive algorithms to generate a CRC value for the FCS 
field. The frame check sequence (FCS) field contains a
4-octet (32-bit) cyclic redundancy check (CRC) value. This 
value is computed as a function of the contents of the 
source address, destination address, length, LLC data and 
pad (that is, all fields except the preamble, SFD, FCS, and 
extension). The encoding is defined by the following 
generating polynomial.

G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 +
       x8 + x7 + x5 + x4 + x2 + x + 1 

Mathematically, the CRC value corresponding to a given frame 
is defined by the following procedure:

a) The first 32 bits of the frame are complemented.

b) The n bits of the frame are then considered to be the
   coefficients of a polynomial M(x) of degree n.1.
   (The first bit of the Destination Address field
   corresponds to the x(n.1) term and the last bit of
   the data field corresponds to the x0 term.)

c) M(x) is multiplied by x32 and divided by G(x), producing
   a remainder R(x) of degree .31.

d) The coefficients of R(x) are considered to be a 32-bit
   sequence.

e) The bit sequence is complemented and the result is the
   CRC. The 32 bits of the CRC value are placed in the
   frame check sequence field so that the x31 term is the
   leftmost bit of the first octet, and the x0 term is the
   right most bit of the last octet. (The bits of the CRC
   are thus transmitted in the order x31, x30, ... x1, x0.)



You will notice the amazing fact that unlike the rest of
the frame that is sent LSB first, the FCS is sent MSB first.


>4) If CRC is wrong, will the PHY still transmit the data onto the PC.

Yes. The PHY does not care, and since it doesn't see the FCS
until the end of a packet, how would it know not to send the
earlier stuff  :-)

>I would request you to please answer my questions as soon as possible.

Sure.

Bet the following helps too. Here is a REAL packet!!!

55
55
55
55
55
55
55
d5
0d
0d
0d
0d
0d
0d
0c
0c
0c
0c
0c
0c
88
08
00
01
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
77
e5
5c
0b
f8


The calculated CRC is    58 c5 2f e0
so the calculated FCS is e5 5c 0b f8

Let me work the first byte for you:
58 complemented is A7 == 10100111
Then reverse the bit sequence == 11100101
which is E5, which is then the first byte of the FCS
that is sent out, LSB first, which means it goes out as
1, 0, 1, 0, 0, 1, 1, 1.   Thus meeting the requirement
that the first transmitted bit of the FCS is from the
MSB of the CRC. The standard specifies what must happen,
but not how. Since I didnt want to have a shifter for the
FCS that was different from the rest of the packet, I
instead supply the FCS to the shifter in reverse byte order
(MSByte first), and by bit reversing the byte, the shifter
can shift out LSBit first and achieve the requirement of
the FCS effectively shifting out MSBit first.

>thanks
>ashwin

Have fun, I certainly did.

Philip

Philip Freidin wrote:

> You will notice the amazing fact that unlike the rest of
> the frame that is sent LSB first, the FCS is sent MSB first.

This numbering likely comes from
the schematic in Appendix C (pg 77)
of the same document:

"The Ethernet" ver. 1.0 Sept 30, 1980
   by digital|intel|xerox.

It looks to me like the author
got the circuit working first and
wrote the spec based on that.

This appendix contains some critical
hardware details missing from the formal
specification:
1. The feedback shift register should be
initialized to all ones for every
frame, and the fact that this is
logically equivalent to curious
inversions in the formal specification.

2. The input to the circuit starts at the "x0" end.

3. The magic remainder value left in the x register
    for a good frame check is:
    x(0 downto 31) = x"debb_20e3"
    Or as it is more commonly seen in memory
    x(31 downto 0) =  x"c704_dd7b"

        -- Mike Treseler