Re: [ethmac] block definition

[nbase <nbase@nbase.com>]

3-Aug-00

   All Hi,

		the problem is not RTL codeing as while it also take sometime to code and
check for syntax etc there is one major thing we need to do  and that is - 

Define properly and fully what this MAC should do in phase 1 as well as
define in full what each block should do.

We than need as this suppose to be a group work to decide what each do as
well as someone need to design a test bench which will verify the validity
of the code from functional point of view.

Also maybe we want to code it in Vhdl as well as in Verilog so we need to
do it for both languages base of couse on SAME definition.

Than we might want to target it to some FPGA and this might need some
constrain files or few modification.

but as I mention we FIRST need to complete the definition.

have a nice day

   Illan




At 06:46 PM 08/02/2000 -0700, you wrote:
>I would just like to say that EthMAC is certainly a core that we would like
>to see in first opencores's silicon chip (openrisc, 2x ethmac, 2x UART,
>SDRAM controler and some other peripherals/glue). I just hope it will be
>ready. There is no real deadline but it would be nice to have a RTL in a
>month or so. If you need something from opencores (like additional web/cvs
>accounts send email to webmaster).
>
>regards, Damjan
>
>> 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.
>> >
>> >
>>
>>
>
>