[ethmac] about the MAC design

[Maik Boden <maik.boden@gmx.net>]

Hi,

some explanations to the EthMAC on my website:

  http://www.inf.tu-dresden.de/~mb25/ethmac (last update 10 Aug 2000)

> 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)
I use one chip clock only. The MII Loopback module synchronizes the incoming MII
RxData in RxClk to Clk and also synchronizes the outgoing MII TxData from Clk to
TxClk. The COL and the CRS signals are synchronized to Clk too. So all MACs
operate on Clk. This allows direct connection of RxMAC and TxMAC on loopback
mode without any further synchronization.

> 2.
> What is the input MII_RXstrobe ? who suppose to give it to you ? the phy
> don't issue such signal.
The MII_RxStrobe signals that a new nibble is in the RxFIFO. Because Your chip
clock would be faster that Rx/TxClk not in every clock cycle a nibble can
computed.

> 3.
> where is MII_CRS ?
You dont need MII_Crs in the RxMAC. Because it shows any MAC activity - Rx and
Tx! You can't use this for detecting an incoming frame only on half duplex mode.
In full duplex mode this signal is not specified by the standard and so I think
it's better to leave it out.

> 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.
All fields are byte-align. The DA, SA, LEN, DATA, CRC. How would You get to know
when the next field start if Your counter is not sychronized to the first byte
of the frame and You do not count in bytes ?

> 5.
> singlecase is usually refer as unicast .
Yes, You are right. I will correct this.

> 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.
I will do so!

> 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.
Sorry, I don't understand this question. Where do I use 2 FF? Or do You
missunderstood the meaning of QUARTET and OCTET. This I use to enable for byte
processing which is done on only one of two clock cycles. One clock cycle You
have to wait because You need two nibbles for each byte. The state IDLE is used
to clear the MAC as fast as possible. When the whole packet has been recepted
the bytes allways stored in the SREG can processed on full speed.

> 8.
> more over with this align are you going to discard packet that is not align
> ???
I use the National DP83815 MacPhyter as reference. There they do something like
this. And it also sounds well because if You receive an odd number of octets the
frame have to be wrong. Or do You think there can be a single nibble after the
CRC sequence? I don't think so.

> 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.
That's right. I plan an on-the-fly operation. But the host You think of may be
not the one I mean. The hostinterface could be also a FIFO buffer. So the host
can get the data from it on-the-fly or after the RxComplete signals is available
an it can check for errors. For my application I got not enough memory (maybe
4..8kb all in all !!!) to do so.

> 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.
Remember: The last four bytes of the frame are representing the CRC sequence
which is added on delivery and were not included by computing the CRC sequence
on Tx. So on Rx You need to compare the CRC of all header and data bytes with
the last four bytes of the frame (the CRC sequence). In this case You need to
store at least four bytes in a register because You need it for comparision.
Right?
 
> 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).
Additional to the basic CRC computing I do frame end detection and CRC
comparision to check if the received frame is OK.
 
> 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.
Please have a look at (10). I dont think You can compute the CRC until RxDV goes
down. And because I work on byte-alignment only each second clock cycle will
offer a new input.
 
> 12.
> what is the RxStrobe suppose to do in the address recognition ?
Once again - byte-alignment. I have to ensure that the state machine operates
only when a new byte has been recepted. This is an ENABLE for the FSM-FFs.
 
> 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.
??? (sorry)
 
> 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.
I check the COL signal on reception. Please look at the Receive State Machine.
The control for full duplex is done by MII Loopback Control. In this case COL is
allways set to 0. Again the DP83815 - they also do not count the number of
collisions. Any (even one) collision is a reason the discard the frame. Only on
Tx You can think about aborting the frame transmission if to many attempts are
needed. In case of Rx I do not understand You at all, sorry!

> Tx
> --------
> ???
There I'm working on. This is coming soon (I think next week) ...
 
> 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.
Please look at (1). I think it will anwser Your question.
 
> flow Control
> ------------
> 1.
Simple said: I think if You want to do flow control You even need to recept and
transmit frames. This is the task of RxMAC and TxMAC. For flow control I think
it's better to use this modules as service providers and do MAC control on a
upper layer like it is defined in the IEEE 802.3 standard. I think only about
the problem of mixing to complete different things: the reception/transmission
of a frame and it's processing.


Regards
Maik Boden