[ethmac] block definition

[nbase <nbase@nbase.com>]

2-Aug-00

   All Hi,

		It seem to me as we are somewhat stuck and not moving and assuming that
who ever in this newsgroup really what to make this mac I suggest to start
in defining the block we need in the Rx and Tx machine and once we agree on
them and define the I/O of those module we can continue.

I more over suggest that we first start with a "pure" mac 10/100 and only
than add features like rmii interface in the front, support 1000 support
dma, cpu interface, monitoring for debug vlan remove and new crc
calculation, etc etc, so for a start we shall assume we have mii interface
of 2.5/25M with 4 bit data.

Rx Machine :
------------
1. RX FIFO
purpose: 
syncronize the mii data coming in rx clock to the chip clock (which is also
the tx clock)
inputs:
rxd   - mii rx data [3:0]
rxdv  - mii rx data valid
rxclk - mii rx clock
outputs:
rxd_s - rx data [3:0] syncronize to chip clock
rxdv_s- rx data valid syncronize to chip clock
clk   - chip clock

2. RX SR
purpose:
this shift register is simple shift register that will be used to delay the
data coming from the RX FIFO for syncronizing the sof/eof signals as well
as later on will enable us to remove vlan and few other manipulation we
might want to do. for start it wil be 1 stage only.
input:
rxd_s - rx data [3:0] syncronize to chip clock
rxdv_s- rx data valid syncronize to chip clock
clk   - chip clock
rstn	- chip reset
output:
rxd_sr - rx data [3:0] after the shift register
rxdv_sr- rx data valid after the shift register

3. RX FRAME
purpose:
look on the information coming from the RX FIFO and determine when the
packet start/end (the shift register length also influance when the sof/eof
will occur)
inputs:
rxdv_s - rx data valid syncronize to chip clock
clk	- chip clock
rstn	- chip reset
output:
rxsof_p - rx start of frame go high with the first data nibble 
rxeof_p - rx end of frame go high with the last data nibble 

* _p mean it is a one clock pulse.

3. RX LENGTH
purpose:
check the length of the packet to see that is a legal packet length (if I
recall correct the legal size are 64-1518 byte)
inputs:
clk	- chip clock
rstn	- chip reset
rxsof_p - rx start of frame go high with the first data nibble 
rxeof_p - rx end of frame go high with the last data nibble 
output:
rxlen	- length of the packet [11:0] (if packet is longer than 2047 nibble
the counter will still show nibble)

4. RX CRC CHECK
purpose:
check the crc of the rx packet to check it's integrety. 
inputs:
clk	- chip clock
rstn	- chip reset
rxd_sr - rx data [3:0] after the shift register
rxdv_sr- rx data valid after the shift register
rxeof_p - rx end of frame go high with the last data nibble 
output:
crc_status - clock after the rxeop_p this signal will tell if the crc is
good(1) or bad(0)

5. RX COL
purpose:
to check the col signal during recive as well as to monitor partition senario.
input:
clk	- chip clock
rstn	- chip reset
fdx	- full duplex (1) half duplex (0)
col	- collision from mii interface
output:
partition - line in partition(1)
col_num   - number of consecutive collision [3:0]

6. RX REG
purpose:
to store all the packet information coming from different modules to be
used later  by cpu etc. also if the packet is flow control (fc) it check
the counter value. for the moment since we don't have cpu this module it is
not fully define and might need to add/remove signal as well as async
interface is most likely will be needed to be added.
input:
clk	- chip clock
rstn	- chip reset
rxd_sr - rx data [3:0] after the shift register
rxdv_sr- rx data valid after the shift register
rxeof_p    - rx end of frame go high with the last data nibble 
crc_status - clock after the rxeop_p this signal will tell if the crc is
good(1) or bad(0)
rxlen	- length of the packet [11:0] (if packet is longer than 2047 nibble
the counter will still show nibble)
partition - line in partition(1)
col_num   - number of consecutive collision [3:0]
output:
fdx	- full duplex (1) half duplex (0)
fc_flag- when high (1) the tx need to stop transmiting

Tx Machine:
------------
1. BACKOFF
purpose:
depend on the col counter it randomize a number to be used by the ipg
machine to decide the gap between the packets.
input:
clk	- chip clock
rstn	- chip reset
col_num  - number of consecutive collision [3:0]
partition - line in partition(1)
output:
rnd_num - random number [9:0]

2. TX PROCESSOR
purpose:
this is the main engine of the tx it get a rquest to send data and
according to the ipg status and other input send the data including the
preambale and sfd or flow control or jam etc.
input:
clk	- chip clock
rstn	- chip reset
ipg	- gap between the packet
txd_in - data to be transmited [3:0]
txen_in- tx enable to be transmited [3:0]
fc_flag- when high (1) the tx need to stop transmiting
output:
txd	- tx data [3:0]
txen	- tx enable

3. IPG
purpose:
to determine the ipg size between to be used by the TX Prossesor 
input:
clk	- chip clock
rstn	- chip reset
rnd_num- random number [9:0]
output:
ipg	- gap between the packet

General Module:
----------------
1. RESET
purpose:
supprose glitch coming from the reset pin as well as syncronize the reset
for use by FF woring in main clk as well as in rxclk
inputs:
pin_reset - reset coming from the pin after the input buffer
clk	- chip clock
rxclk	- mii rx clock
outputs:
rstn	  - reset syncronize to chip clock
rstn_srx - reset syncronize to mii rx clock

I suggest the above to be the base for which we can continue discuss and
devolope, as there are many more thing we mioght want to modify as well as
add.

have a nice day

   Illan



At 12:10 PM 07/28/2000 -0500, you wrote:
>See 802.3 4.2.3.2.5:
> "At the end of enforcing a collision (jamming), the CSMA/CD sublayer delays
> before attempting to retransmit the frame. The delay is an integer multiple
> of slot time. The number of slot times to delay before the nth
> retransmission attempt is chosen as a uniformly distributed random
> integer r in the range:  0 <= r < 2^k where k = min (n,10)."
>
>After 16 attempts at transmission, all resulting in collisions, the packet
>should be dropped.  (Slot time is 512 bit times, BTW).
>
> - WJ
>
>-----Original Message-----
>in any case in respect to collision and backoff algoritum the spec specify
>(I hope I recall it correct, and if not do corret me) that you will
>randomize a number between 0-2^k where K is the number of consecutive
>collision and K go up to 10 so after the fisrt collision the random number
>can be 0 or 1 after the second consecutive colision the random number can
>be 0,1,2,3 and so on. and after the 16 consecutive collision the station
>can discard the packet.
>
>