RE: [ethmac] TxMAC, VLAN, FlowControl

["NewsGroup" <nbase@nbase.com>]

Hi,

># 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.

no need to be sorry :-) , I will try to find the point that show this but if
my memorey serve me right it have to do with repeter issues and not "pure
MAC" issues and if you are going to be connected MAYBE to repeters than you
SHOULD "obay" this rule. otherwise a station might not see the collision.


>
># 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.

if you decide to do it this way just a small suggestion as the CRC equation
are long and they are the "bottle neck" of this part you can improve the
performance a bit by instaed of using case use first if (00) and in the else
use case or simple continue with if else as the sfd/pre are really not the
problem.


># 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?

This is not entirly correct and have to do also with the phy you use, and
what was the extra nibble you send as (at least in the original std) you
should have support dribble nibble (like in 10M original which was bit by
bit you should support dribble bit which could be extra 1 bit, 2 bit etc up
to 7 bit.

however in the more general aspect you can decide what ever you want as it
is the "master" problem as he send to the MAC an illigal packet, so you can
simple send "bad crc" or even better rais the tx_err signal.

one thing I do wonder is that the "master" in most cases you will have are
cpu and if so they always send data in byte so there will be no extra
nibble.


># 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?

There is no sense to send Vlan with flow-cotrol packet as the Vlan is used
to filter to whom the packet will get to while the flow control simple is
used to "ask" the other side to stop sending as you are out of buffers.


># 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?

WHY , I must have missed something , but I see no reason to let the host
have extra work when the MAC can do it so easily, more over the problem
arrise due to the MAC-RX been full.

the only exception is if you don't have in the MAC buffer at all and in this
case IF the host can't tell you in advance that he his going to run out of
buffer the TX flow control should be done by the host.

but in any case the RX flow control should for sure be done in the MAC as
why not checking the packet and stoping the TX for the exact time of the
timer.

the host have enough to do why not "helping him" ?

have a nice day

   Illan