Re: [ethmac] about the MAC design

[nbase <nbase@nbase.com>]

11-Aug-00

   Hi,

RX -
     

1.
Why having 3 clock in your system ?

I would think that TxClk can be also your chip clock and this way you save
one syncronization and make the design simpler.

2.
Why do you want to operate the chip in faster clock ? since the data don't
come any faster what will in contribute except making the design harder
from timing aspect etc ?

3.
I would think twice about this issue.

4.
what the different between counting byte and nibbles ??? both start after
the Preamble/SFD ??

Also the DA/SA is actually 48 bits so byte make sense just as nibble word
or what ever, the more over the crc will be simpler, and few other
"machines". true that the len counter is one bit extra but you can ommite
the lsb when looking on it and now the length in byte and the lsb actually
tell you about align if you want.

7.
well 3 states mean 2 FF , if you use this for the align simple have idle
and nibble and toggle between them , and of course always start new packet
by going from idle to nibble and at the end of the packet look where you are.

8.
well you should think so, as while quite a long time pass from the last
time I looked on the standard and "played" with MAC I'm sure there is a
place where it mention that you should support dribble nibble.

9.
I have a feeling you send to a fifo so the question is once the packet
already started to be written to the fifo how do you discard it incase of
an error, let say you see a CRC error at the end, how do you rewind or make
the fifo go back ?

10.
wrong, you can simple send the crc field also into the crc checker and get
the "magic number" instead of doing compare which is also fine but make
"design a bit more complex".

11.
when rxdv in the input go low the frame end and in this point you the crc
tell you if the data is good or bad.
the crc have nothing to do with start or end of the frame, it only check to
see that the data was not corrupt.

in respect to byte align again word with nibble and you save yourself this
issue of align the data , also the equation will be a little mote simple
and less logic.

13.
what are you sorry about ? 
I was merly sayuing that if you don't have hash/cam I see no point in this
address recognition module.

15.
do you mean you support only full duplex ? as col and crs are needed for
exmpale for the partition detection, whcih effect RX as well as TX.


flow Control
1.
well you don't need to recive the flow control frame as you can simple send
a pre define parameters and all data can be simple zero and you will need
to add small crc (which is extremly similar to the crc in RX) so very few
logic need to be use.
but again I belive if you give it a second though you will see it is more
simple that what you are affrid off but hay it's your project so ...

have a ncie day

   Illan



At 10:46 PM 08/10/2000 +0100, you wrote:
>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
>
>