[ethmac] TxMAC, VLAN, FlowControl

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

Hi,

# DeferCounter:
Well I agreed about understanding what DeferCounter does. In respect to a
standard-conform EthMAC it has nothing usefull because timeout is specified as
result of reaching the retransmission attempt limit. We should remove this
module to prevent further missunderstandings!

# Jam size:
Sorry, I can't find any information about extending a frame up to 96BT. The
standard only requires sending a unspecified pattern of 32BT which is different
from the CRC sequence of the partitial transmitted frame.

# Content of Jam and Pad:
The content of this fields is unspecified in the standard so that any value is
correct here.

# FCS - Multiplex vs. Shift
If we don't need special pattern for Jam and Pad, we could also shift the CRC
through the register of the CRC-Generator. This would make design a little bit
smaller, because the shift register is simple to build and we could use a MUX
like this:

 00: data_in (also used for Pad and Jam)
 01: crc_in
 10: preamle "0101"
 11: sfd     "1101"

By the way: I suggest to pass 4-bit-wide data (nibbles) through the MAC.

# Transmitting an odd number of nibbles:
This fact normaly causes an error on receiver side. But if we extend a short
frame and add the correct FCS then the receiver will not detect this error.
Because frame check sequence and frame length are okay! So the question is:
Should we suppress the CRC in this case and send a different pattern instead?

# VLAN tag:
What's about FlowConrol frames? Is the VLAN tag also added to such ones? Or are
MAC-Control-Frames of any type left out from VLANs because the corresponding
MACs are connectet point-to-point?

# Flow Control:
In respect to the standard stopping TxMAC by a simple counter in RxMAC is wrong
because sending flow control frames should be possible at every time. What else
should an allready stopped MAC do when it also gets out of memory and it is not
able to send a flow control frame to the MAC who stopped it. So I suggest to
leave flow control beside the MACs:

 M  -> | RX | -> |  Flow   |        Host
 I               |         | <->
 I  <- | TX | <- | Control |      Interface

We could add a signal like RxOverflow to the host interface. Asserting this
signal causes the NIC to send a (pause_time=65535)-frame and the other way
around deasserting this signal causes a (pause_time=0)-frame. So it would be
possible to handle whole flow control in hardware. Any suggestions?


Regards
Maik Boden