Hello everyone,

   I am sending an ethernet  packet(64 bytes) from the fpga to the PC
in order to test the ETHERNET PHY chip onboard.
   The interface from the fpga to the ethernet PHY for the data is 4
bits.

 My PC mac address is 00-01-80-3F-6C-E6

a)So should i send the LSBs first like
in this order, 6,E,C,6,F,3,0,8,1,0,0,0 or the MSBs first


b) I have installed ethereal software on my PC and i am unable to
detect the ethernet  packet in it.
     1) I am pretty sure my CRC is wrong for whatever data i have, so
can ethereal still detect even when crc is wrong?

     2)i used the scope , and i am able to see some data going from
fpga to the ethernet PHY. But the nothing gets detected in the PC. What
could be the reason?

      One of the member in this group recommended not to see the data
coming out of the ETHERNET  phy , since its at 125 mhz and its not
being detect correctly using a scope.


3)Can anyone compute the crc check for whole ethernet packet for which
my destination addres is as above? Data doesnt matter,it can be any
value.?Source address also doesnt matter, since it is fpga mac address.

4) Can anyone guide me on hardware implementation of crc using
 vhdl

There are more CRCs in a ethernet packet:

1. PHY level. The very last 4 bytes. In linux ifconfig  will show you
the number of packet errors on a  NIC. Ethereal won't detect it because
the network driver throws away the packet if it's bad. Some driver
won't even generate interrupt for bad packets, in that you cannot see
the error unless you recompile the driver and enable interrupts for bad
packets.

2. CRCs in IP headers. ethereal will detect it.

Zoltan

ashwin wrote:

>       One of the member in this group recommended not to see the data
> coming out of the ETHERNET  phy , since its at 125 mhz and its not
> being detect correctly using a scope.

Yes. Look on the data side, not the line side.
Scrambling will make an idle link look the
same as a busy one.

       -- Mike Treseler

I run tethereal for all my packet analysis. Two options to use:
tethereal -x -i eth0 (or whatever your interface is) - complete data
dump
tethereal -V -i eth0 (or ...) - protocol level dump

I believe tethereal will give you invalid FCS (CRC) packets.

A sample ethernet packet from 08:00:46:63:ca:e3 with destination
00:13:20:0a:25:db is here. The first byte on the wire is given first -
so transmit the MAC address bytes from left to right. Bits 0-3 go first
on the wire, 4-7 afterwards

0000  08 00 46 63 ca e3 00 13 20 0a 25 db 08 00 45 10   ..Fc....
.%...E.
0010  00 74 3e b4 40 00 40 06 c5 53 0a 01 11 40 0a 01
.t>.@.@..S...@..
0020  11 2b 00 16 81 0d 97 0e cc 65 84 46 8d 49 80 18
.+.......e.F.I..
0030  0a a8 36 d3 00 00 01 01 08 0a 5c 54 28 18 00 6f
..6.......\T(..o
0040  69 8d 70 8b af ba 95 1e 29 bc 92 53 9d ca d8 e9
i.p.....)..S....
0050  e7 46 81 bf eb 16 6d 86 11 f0 63 a1 59 77 4a 75
.F....m...c.YwJu
0060  e9 da cf 8d e5 b1 d2 3a 0d 04 ad 8c 41 88 c5 cb
.......:....A...
0070  13 d4 1b c1 b3 30 43 d2 d9 62 c9 0e 08 31 1d 64
.....0C..b...1.d
0080  43 9b                                             C.

It is probably best to start out broadcasting packets for your tests -
send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
Also it is worth writing ethernet rx before tx - make sure you can
receive packets with the correct FCS from the wire, and then you can
get your tx to work with your known working rx code.

Anyway, a packet to your destination address from MAC address
01:23:45:67:89:a0 with total packet length including MAC addresses and
FCS, with other content 00, is...

00 01 80 3f 6c e6 01 23
45 67 89 a0 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 75 78 03 93

Hello Gavin,
 Thanks for sending an ethernet packet which includes my destination
address.
 Does the last 4 bytes represent CRC of all the data.
 You didnt inlude the length/type, 2 bytes , which comes after source
address. I guess we need to compute the crc for that also.

Please check and advice

thanks
ashwin



Gavin wrote:
> I run tethereal for all my packet analysis. Two options to use:
> tethereal -x -i eth0 (or whatever your interface is) - complete data
> dump
> tethereal -V -i eth0 (or ...) - protocol level dump
>
> I believe tethereal will give you invalid FCS (CRC) packets.
>
> A sample ethernet packet from 08:00:46:63:ca:e3 with destination
> 00:13:20:0a:25:db is here. The first byte on the wire is given first -
> so transmit the MAC address bytes from left to right. Bits 0-3 go first
> on the wire, 4-7 afterwards
>
> 0000  08 00 46 63 ca e3 00 13 20 0a 25 db 08 00 45 10   ..Fc....
> .%...E.
> 0010  00 74 3e b4 40 00 40 06 c5 53 0a 01 11 40 0a 01
> .t>.@.@..S...@..
> 0020  11 2b 00 16 81 0d 97 0e cc 65 84 46 8d 49 80 18
> .+.......e.F.I..
> 0030  0a a8 36 d3 00 00 01 01 08 0a 5c 54 28 18 00 6f
> ..6.......\T(..o
> 0040  69 8d 70 8b af ba 95 1e 29 bc 92 53 9d ca d8 e9
> i.p.....)..S....
> 0050  e7 46 81 bf eb 16 6d 86 11 f0 63 a1 59 77 4a 75
> .F....m...c.YwJu
> 0060  e9 da cf 8d e5 b1 d2 3a 0d 04 ad 8c 41 88 c5 cb
> .......:....A...
> 0070  13 d4 1b c1 b3 30 43 d2 d9 62 c9 0e 08 31 1d 64
> .....0C..b...1.d
> 0080  43 9b                                             C.
>
> It is probably best to start out broadcasting packets for your tests -
> send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
> Also it is worth writing ethernet rx before tx - make sure you can
> receive packets with the correct FCS from the wire, and then you can
> get your tx to work with your known working rx code.
>
> Anyway, a packet to your destination address from MAC address
> 01:23:45:67:89:a0 with total packet length including MAC addresses and
> FCS, with other content 00, is...
>
> 00 01 80 3f 6c e6 01 23
> 45 67 89 a0 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00
> 00 00 00 00 75 78 03 93

>2. CRCs in IP headers. ethereal will detect it.

That's not the hardware level CRC at the end of the packet.
It's not even a CRC, just a 1's complement add.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

> a)So should i send the LSBs first like

Do they still make Ethernet gear that runs on coax?  If you
can find some of that the bit order will be pretty obvious.

> 3)Can anyone compute the crc check for whole ethernet packet for which
> my destination addres is as above? Data doesnt matter,it can be any
> value.?Source address also doesnt matter, since it is fpga mac address.

Send a packet from your PC.  Grab the bits with a scope.
Then you can make your CRC agree with one that is known to work.


-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

Ethereal will happily receive the above packet - it will tell you all
sorts of errors about it, though... Don't worry about the length etc
until you can get a blank packet correct. If you can do that, then you
should have the FCS code all working, and you are at a different debug
level.
The last 4 bytes are FCS.

Gavin wrote:
> It is probably best to start out broadcasting packets for your tests -
> send to ff:ff:ff:ff:ff:ff, that way they should get received whatever.
> Also it is worth writing ethernet rx before tx - make sure you can
> receive packets with the correct FCS from the wire, and then you can
> get your tx to work with your known working rx code.

I'd second that - the lazy way to work this out is to instrument the 
image on the rx side (ie using something like chipscope), transmit some 
packets on the network, and see if it matches what you expect.  It can 
be easy to to get caught out.  You can then write a simple state machine 
to dump the data you saw on the rx side out the tx side.

The rx side is easier to get working first, since you can:
a) Get your crc code right first by checking crcs on recieved packets 
(quite likely to be correct)
b) You can then simulate a loopback situation to check that your rx crc 
code and tx crc code match
c) It forces you to recheck your assumptions on nybble/byte ordering, 
since if what you expected was different from what you recieved from the 
packet, then you're probably wrong :)

Also, if your crc code is incorrect, it's easier if you have a 'golden' 
source, as you can then run simulations or a c program using a known 
good piece of code (from a bsd kernel or something like that) to see 
where you went wrong.  It helps to localise the error if you are using a 
  known good source.

My 2c,
Jeremy

Hello,

I developed a wee Gigabit MAC but with quite a different setup, Virtex 2 Pro 
(with my MAC + Internal MGT - 16 bit wide @ 62.5MHz) + Copper SFPs (with 
embedded Marvell 88E1111 in SGMII mode) <=> PC

I did use Ethereal, and noticed that crc errored packets were filtered out, 
not sure if it was the SFP, the PHY in the PC or the PC driver, I'm positive 
that packets were not getting to Ethereal at all. I also noticed that 
packets smaller than 64 bytes were also filtered out and I am pretty sure it 
was the Driver in my PC.

For testing I used a ping frame...

--=============================================--
--IP DA (192.168.0.85 : c0.a8.00.55)
--IP SA (192.168.0.33 : c0.a8.00.21)
--Header Length & IPv4 = x"4500"
--IP Datagram = x"0800"
--SA = 12.34.56.78.9a.bc (it doesn't really matter)
--DA = 00.0d.88.b5.88.71 (change it to yours, it doesn't really matter in 
promiscous mode)
--=============================================--

constant C_GBE_DATA : word32_array(18 downto 0) :=
(
X"68697071",
X"64656667",
X"77616263",
X"73747576",
X"6f707172",
X"6b6c6d6e",
X"6768696a",
X"63646566",
X"04006162",
X"485c0100",
X"00550800",
X"0021c0a8",
X"96b3c0a8",
X"00002001",
X"003c8247",
X"08004500",
X"56789abc",
X"88711234",
X"000d88b5"
);

Bytes go out like: 00 - 0d - d8 - b5 - 88 - 71 ...

FCS for the packet above => X"257eaf61"

On thing I recommend is using loopback if your PHY supports it, and also the 
internal CRC if the PHY provides one (just for testing) before trying to 
send packets to your PC.

Regards,
-- 
Ignacio Ulises Hernandez
" I'm not normally a praying man, but if you're up there, please save me, 
Superman!" - Homer Simpson ;O)




"ashwin" <a...@gmail.com> wrote in message 
news:1...@g44g2000cwa.googlegroups.com...
> Hello everyone,
>
>   I am sending an ethernet  packet(64 bytes) from the fpga to the PC
> in order to test the ETHERNET PHY chip onboard.
>   The interface from the fpga to the ethernet PHY for the data is 4
> bits.
>
> My PC mac address is 00-01-80-3F-6C-E6
>
> a)So should i send the LSBs first like
> in this order, 6,E,C,6,F,3,0,8,1,0,0,0 or the MSBs first
>
>
> b) I have installed ethereal software on my PC and i am unable to
> detect the ethernet  packet in it.
>     1) I am pretty sure my CRC is wrong for whatever data i have, so
> can ethereal still detect even when crc is wrong?
>
>     2)i used the scope , and i am able to see some data going from
> fpga to the ethernet PHY. But the nothing gets detected in the PC. What
> could be the reason?
>
>      One of the member in this group recommended not to see the data
> coming out of the ETHERNET  phy , since its at 125 mhz and its not
> being detect correctly using a scope.
>
>
> 3)Can anyone compute the crc check for whole ethernet packet for which
> my destination addres is as above? Data doesnt matter,it can be any
> value.?Source address also doesnt matter, since it is fpga mac address.
>
> 4) Can anyone guide me on hardware implementation of crc using
> vhdl
>