[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ethmac] magic number, compatibility problem?!
Hi,
First can you send me the file you belive I worte ? as I can;t say I recall I wrote any file except for some info I send from time to time and was wonder in such case what part of info you reffere to.
as for the all zero Vs magic number your example is wrong but it is true that IF you decide NOT AS THE STANDART to append the CRC when you generate it as it is and not bit swap and inverted the reciving side when he pass all the data with the CRC will get zero.
this maybe the part that confused you.
as IF you append the crc bit swap and inverted than you will ALWAYS get the same MAGIC Number.
hope this make it more clear, and clear up there is NO COMPETABILITY issue there is few way to write CRC machine but only one result.
The Zero (once again NOT STANDART) just to give more full view was consider at start but since stuck at zero is known hardware problem and would result in good crc it was decided to do the swap and invert and use this magic number.
I still would like to see what code you refer as it look lilke it have my name but I don;t know what it is.
have a nice day
Illan
-----Original Message-----
From: jcwh@sina.com [mailto:jcwh@sina.com]
Sent: Monday, February 18, 2002 6:57 PM
To: ethmac@opencores.org
Subject: RE: [ethmac] magic number, compatibility problem?!
thanks anyway!
but maybe i didn't describe the problem cleayly.
someone said(i forget where and in which situation):
in rx module.
if you simply pass all your received(inculding 32bit crc) through FCS,
in this way:
"
assign Data_Crc[0] = MRxD[0];
assign Data_Crc[1] = MRxD[1];
assign Data_Crc[2] = MRxD[2];
assign Data_Crc[3] = MRxD[3];
"
you will get ZERO(not magic number).
but if you pass your received in a special way:
"
assign Data_Crc[0] = MRxD[3];
assign Data_Crc[1] = MRxD[2];
assign Data_Crc[2] = MRxD[1];
assign Data_Crc[3] = MRxD[0];
"
you get magic number.
in the tx module. Illan write this:
"
assign Data_Crc[0] = StateData[0]? TxData[3] : StateData[1]? TxData
[7] : 1'b0;
assign Data_Crc[1] = StateData[0]? TxData[2] : StateData[1]? TxData
[6] : 1'b0;
assign Data_Crc[2] = StateData[0]? TxData[1] : StateData[1]? TxData
[5] : 1'b0;
assign Data_Crc[3] = StateData[0]? TxData[0] : StateData[1]? TxData
[4] : 1'b0;
"
please note the index of Data_Crc and TxData
Data_Crc[0] <-> TxData[3]
Data_Crc[1] <-> TxData[2]
Data_Crc[2] <-> TxData[1]
Data_Crc[3] <-> TxData[0]
Does Illan want to get a magic number when receiving the frame with
CRC resulted in this way?
i don't know in the normal ethernet controller(designed by Realtek, NS,
3com, intel, etc.),
in the tx module. which way they chosed,
this way;
Data_Crc[0] <-> TxData[3]
Data_Crc[1] <-> TxData[2]
Data_Crc[2] <-> TxData[1]
Data_Crc[3] <-> TxData[0]
,or another way?
this is where i wonder will result a compatibility problem.
----- Original Message -----
From: "Kevin Kay" <kevin.kay@e... >
To: <ethmac@o... >
Date: Sun, 10 Feb 2002 19:09:08 -0500
Subject: RE: [ethmac] magic number, compatibility problem?!
>
>
> Correct, I did not know the original poster's situation, so I left
> all
> options open. If the data contained within the frame is IP data,
> you would
> probably not forward it.
>
> However, there are many other situations in which you may forward a
> frame
> which contains a CRC error. For example, if you were transmitting
> specialized data within your frames (non-IP data) that was
> protected by an
> error correction scheme (like Reed-Solomon) instead of just an
> error
> detection scheme (like IP), you may still be able to correct and
> extract
> your data with confidence despite the frame CRC error. It just
> depends on
> the situation.
>
> Obviously, a network such as this would not be running across the
> internet
> and would have specialized applications.
>
> I hope this clears up what I was thinking.
>
> Regards,
> Kevin
>
>
> -----Original Message-----
> From: owner-ethmac@o...
> [/cgi-bin/post.cgi?cmd=new&to=owner-ethmac%20at%20opencores%
20dot%20org&msg=/ml-archive/ethmac/msg00022.shtml
> Behalf Of Illan Glasner
> Sent: Sunday, February 10, 2002 3:10 PM
> To: ethmac@o...
> Subject: RE: [ethmac] magic number, compatibility problem?!
>
>
>
>
> Hi,
>
> Usualy the only case you will forward a packet that have bad
> crc is
> for debug porpuse as otherwise since you can;t tell what went wrong
> the
> result might be quite harmfull.
>
> have a nice day
>
> Illan
>
>
> -----Original Message-----
> From: Kevin Kay
> [/cgi-bin/post.cgi?cmd=new&to=kevin%20dot%20kay%20at%
20espipd%20dot%20com&msg=/ml-archive/ethmac/msg00022.shtml]
> Sent: Saturday, February 09, 2002 6:47 AM
> To: ethmac@o...
> Subject: RE: [ethmac] magic number, compatibility problem?!
>
>
> The magic number is a result of the CRC algorithm used. It really
> doesn't
> directly come from the 802.3 specification (rather, it comes about
> indirectly). The 802.3 spec. calls for the use of a specific
> CRC-32
> algorithm and specifies the polynomial (which is obviously
> specified as the
> FCS for the frame). An indirect consequence of this CRC
> specification is
> the magic number which is related to this polynomial. Thus, since
> all 802.3
> MACs will/should be using the same CRC polynomial, they will all
> essentially
> be using the same magic number.
>
> The magic number is simply a pattern that will result when an
> error-free
> incoming frame (*including the FCS*) is pushed through the CRC
> generator. A
> correct incoming frame with the correct FCS will always generate
> this magic
> number when pushed through this CRC algorithm. The magic number
> approach
> makes it much easier for checking for a correct frame since you
> don't have
> to compare to each individual FCS for each frame. You simply push
> the
> incoming frame and the FCS through the CRC generator and then look
> for the
> magic number. If it's there, you're good to go, if not, then you
> either
> drop the packet due to CRC error, pass the packet on with the
> error, or
> assume the data is OK and pass it on with a new and correct CRC. I
> can't
> say which would be right for your situation, and some of the above
> decisions
> are probably better than others.
>
> Hope this helps.
>
> Kevin
>
> -----Original Message-----
> From: owner-ethmac@o...
> [/cgi-bin/post.cgi?cmd=new&to=owner-ethmac%20at%20opencores%
20dot%20org&msg=/ml-archive/ethmac/msg00022.shtml
> Behalf Of jcwh@s...
> Sent: Saturday, February 09, 2002 2:26 AM
> To: ethmac@o...
> Subject: [ethmac] magic number, compatibility problem?!
>
>
> the magic number is really interesting,
>
> but the 802.3 doesn't mentioned this queer "magic number".
>
> Will this result a compatibility problem with other ethernet
> controller?
>
--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml