Re: [ethmac] doing the development of a NIC

[nbase <nbase@nbase.com>]

9-Aug-00

   Hi, 

        Few comment and answer to your quesitons :

Rx
--------
1. 
it look like you don't sync the rx mii data , do you plan to work with 2
clock in your system ? I would think a small fifo (theoretic 5 depth is
enough but 8 will be only a bit more and will be easier)

2.
What is the input MII_RXstrobe ? who suppose to give it to you ? the phy
don't issue such signal.

3.
where is MII_CRS ? 

4. 
Why do you "insist" on moving from nibble to byte on the front side (MII
side) and not only at the end side ?
why not staying in nibble all the way up to the output where you can
collect the nibble to byte/word or what ever width you want.

5.
singlecase is usually refer as unicast . 

6.
I think you should add a complete forward explanation from side to side so
it will be cleared and it will also help you I belive to see if you missed
something.

7.
without getting to implemintation it seem to me that to find alignment
should be done with 1 FF, and no need for 2 as it is either aligh or not.

8.
more over with this align are you going to discard packet that is not align
???

9.
I assume you are not plan to store and forward of the whole packet it mean
that the writing to the host will be done during the receive of the packet.
if so the write should have some sort of rewind (either addredd or mark
pulse) as you will know about the error only at the end of the packet when
some of the packet already been written to the host.

10.
you mention in the shift register that is used to find the crc in one
clock, I must admite I can't see why this shift register help you, it seem
to me that the shift register have nothing to help with the crc which is
done (if not it should) on the fly.

11.
also looking on your crc check I'm not entierly sure what you do but
basicly crc checker take the data AND the crc field as well and just clock
by clock process them through 32 FF with many xor's and after processing
the crc field a constant number should be the result (magic number).

in general after reset the 32FF are set to all 1 than every time a clock
arrive and the data is valid (in general it will be sequentail without
holes) the crc 32 FF compute something like :
FF(Q) = FF(D) XOR DATAIN
and on the last data when rxdv go down you check the crc and reload the
32FF with all 1.

12.
what is the RxStrobe suppose to do in the address recognition ? 

13.
Since it is more likely that if you will have single mac address it will be
a group and not a single you migt want to have a mask bits as well just as
in IP so you will need to check only certain bits, but in general it seem
to me as either you suppost some amount of address using for example CAM or
maybe HASH etc or simple drop this unicase.

14.
back to description there is nothing about the Rx state machine so hard to
comment about it .

15.
I suggest you look on post I send not long ago with what I belive to be the
needed block for a simple MAC as at least one you missed and it is the
partition. (looking now on the email I send the block I define for the
RX_COL where also the partition is monitor miss some input, like crs)
also if I recall correct this should be the easiest machine as the standart
define the exact state machine so you can simple define a state machine
with same name of state and simple code the drawing.

Tx
--------
???


LoopBack
--------
1.
in general loopback is very good thing and you might want to do it in both
side  as it help debug the chip without the board influance.
however you need to remmber that Tx and Rx clock are not syncronized so you
might need some sort of syncronization.


flow Control
------------
1.
Just of curiusity why do you thing the flow control is so complicated ?
basicly when Rx receive a flow control packet it save the time filed from
the frame and once the packet found to be legal (crc etc) you stop
trasmiting and in the same time you slowly decrement the counter (notice
that the time fiels is in slot time which is 128 clk each, so maybe two
counter will be a nice solution, even tho you can simple load the number to
larger counter where you load to the msb and the lsb simple load 0 so you
get time filed x 128).
as soon as the counter reach 0 you let the tx trasmite again.

if you get a new flow control and again it is valid frame you reload the
counter regardless of its previus value and that's about all in the receive.

in the trasmite there are basicly two solution, one the host give you a
signal to send flow control and a time field or even simpler the host tell
you to send flow control as well as on/off bit and you simple send a a flow
control packet with timer files all 0 or all 1.

Lastly to your questions:
1. 
as you see above I belie it is not complicated but ... 

2. 
I can't recall seing a post about hashing but maybe I enter the list after
the post or simple missed it but in general hashing can be done base on
lot's of algoritem stating in the LSB of the DA assuming all your people in
the company have same MSB bits or doing all kind of shift and xor, and
sometime also using SA.
one thing tho what have the CRC have to do with the DA and the hash ? or
maybe I misunderstood your question.

the whole point bhind hashing is that when you map vector of n bit to m bit
when n>m it mean that few vecor of n will have same location in m.
this usually cause the cam/hash table to write on the next address (m+1)
and this mean that when you look you will hit the address only on the
second search meaning time waste, therefore the hash objective is to spread
the n address you have so when mapping them to the m places you have there
will be only one place for each and all those place will be different.

3. 
I'm not sure what you mean in the DIX Eth question but in general you will
cehck the length for all packets as all ethernet packet need to "obay" the
min/max length.

and yes you can look on rxdv to tell when the packet start/end. also in
many cases you will also want to look on the crs.

have a nice day

   Illan

At 10:08 PM 08/09/2000 +0100, you wrote:
>Hi there,
>
>currently I'm working on a simple Ethernet MAC. I need it for a special
>microcontroller application. If you are interessed in, please have a
>look at my homepage. There I offer some pages about the Ethernet MAC I'm
>still developing.
>
>  http://www.inf.tu-dresden.de/~mb25/ethmac
>
>I listen to this mailing list since a few month and have some questions:
>
>(1) In the IEEE 802.3 standard I read the flow control is only an option
>and no must. I think it's not to easy to build. Why don't You leave this
>module for later improvement?
>
>(2) Are You sure that the nine least significant bits of the destination
>addresses CRC are used for multicast hashing? I didn't found something
>about this in the standard.
>
>(3) Why want You to check the length field of the incoming frame? If you
>recept an DIX Ethernet frame (like all IP implementations use) it will
>contain 0x0800. Also the flow control frames You allways talk about use
>this field. I think only the RxDV signal can be used to detect the end
>of a frame. Right?
>
>If You need some information about the IEEE 802.3 standard, I've got one
>for the job I mentioned. I would be lucky to help You !!!
>
>
>Thanks and best regards
>Maik Boden
>
>