[ethmac] Jam, Pad, Flow control, VLAN

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

Hi,

# Jam size:
It's true that a repeater should extend frame fragments (usally happend at
collisions) up to 96 bit , including preamble [9.6.4, IEEE 802.3, 1998 Edition].
So it's a good suggestion from Illan to use two different states (Jam96, Jam32)
in transmit processor. We should use Jam96 for 64BT and then call Jam32 to
continue this operation. So we would save one flipflop for the counter.

# Jam/Pad content:
If we prefer a "0000"-padding, why not simply add a module which consists of
four ANDs: TxValidData(n) = TxData(n) AND TxValid. So input of CRC generator and
transmit MUX is allways zero when no valid transmit data is available. And
that's what happends when we need to pad a to short frame. Because I think it's
not good to use "0000" for jamming, we could use the preamble-pattern ("0101")
instead.

# Flow control:
In respect to my last mail, here one additional info. If I say HOST-INTERFACE
then I don't think of a CPU. The HOST-SIDE-INTERFACE for me is the next hardware
module after the MAC. This could be anything, like FIFO, PCI, microcontroller
...
So if the FIFO control detects a full RxBuffer it asserts RxOverflow and MAC
itself does FlowControl by sending a correspondig frame. Okay? The CPU (maybe
your host) has nothing to do with it! Okay?

# VLAN:
Also in respect to my last mail! It's true that it makes no sense to use VLAN
for flow control frames. But I was not sure about it. So thanks four your info!


Regards
Maik Boden