RE: [ethmac] magic number, compatibility problem?!

[jcwh@sina.com]

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