RE: [ethmac] Ethernet Standard Related queries.

[Illan Glasner <IGlasner@mrv.com>]

Hi,

   I don;t know either what 4 byte field for the len/field however if you
are talking about Vlan keep in mind that there are some talk and
implementation with double vlan tag so if you plan to designs something
generay that can handle vlan you might also want to look for this.

I don;t know much about it as this is quite proprietry and as far I I recall
it is mainly to add solution similar to what mpls can do but I'm not 100%
sure about it as well as personaly I "belive" in mpls, so never implemented
such thing.

another "drawback" as for vlan is that it is patent of Nortal and so using
it will require you to pay royalty to them or be prepare that they might sue
you, just another reason in mu opinion why not to let vlan progress any
more.

have a nice day

   Illan


-----Original Message-----
From: Sanjeev Sablok [mailto:sablok@agere.com]
Sent: Sunday, December 08, 2002 8:16 PM
To: ethmac@opencores.org
Cc: Mohan Krishna
Subject: Re: [ethmac] Ethernet Standard Related queries.


Mohan,

 Which document is talking, that the length/type field is 4 octets ?.
I think they may be talking about,  4 octet of QTAG prefix which
should be inserted between SA and length/type field for a Tagged frame.
If not, can u tell me the name of the document. I just want to see that.
   Regarding the DA & SA fields, they are of 6 octets. Since no conformant
implementation of IEEE 802.3  uses 2-octet addresses. Therefore
IEEE had excluded 2-octet addresses from the standard. Guys what do u think?
Sanjeev Sablok


Mohan Krishna wrote:

> Hi All.,
>    Thanks for clarifying my doubt on Preamble & SFD.
>
>    I have  a few questions regarding the ETHERNET standard:
>
> 1. Some documents specify the "Destination Address & Source Address " as 2
or 6Octets.What is the
> correct length of  D.A & S.A fields?
> 2. Also the LENGTH/TYPE field is specified as 2octets in some documents
and 4 octets in other
> document.
>     I assume its always 2 octets. Correct me if I am wrong.
>
> Also I would like to know whether the copy available for download in the
IEEE website (IEEE Std
> 802.3-2002® (Revision of IEEE Std 802.3®, 2000 Edition)
> is the latest one for reference.
>
> Thanks in Advance.
>
> Regards.
> Mohan
>
> Illan Glasner wrote:
>
> > Yes you are tho' keep in mind the the SFD is not 1011 but rather
10101011 as
> > many time since in FE we work in nibble boundry it is common to define
pre
> > as 1010 and sfd as 1011 and in such case you need at least one pre
before
> > the sfd.
> >
> > have a nice day
> >
> >    Illan
> >
> > -----Original Message-----
> > From: Karthik D [mailto:karthikd@myw.ltindia.com]
> > Sent: Friday, December 06, 2002 6:14 AM
> > To: ethmac@opencores.org
> > Cc: mkrishna@tataelxsi.co.in
> > Subject: Re: [ethmac] necessity of preamble during reception
> >
> > ** Proprietary **
> > ** High Priority **
> >
> > "RX_DV (Receive Data Valid) is driven by the PHY to indicate that the
PHY is
> > presenting recovered and decoded nibbles on the RXD bundle and that the
data
> > on RXD is synchronous to RX_CLK. RX_DV shall transition synchronously
with
> > respect to the RX_CLK. RX_DV shall remain asserted continuously from the
> > first recovered nibble of the frame through the final recovered nibble
and
> > shall be negated prior to the first RX_CLK that follows the final
nibble. In
> > order for a received frame to be correctly interpreted
> > by the Reconciliation sublayer and the MAC sublayer, RX_DV must
encompass
> > the frame, starting no later than the Start Frame Delimiter (SFD) and
> > excluding any End-of-Frame delimiter"
> >
> > This tells that we need to look for valid SFD rather than Preamble to
> > receive the frame.
> >
> > Hope i am correct...
> >
> > Karthik D.
> >
> > >>> mkrishna@tataelxsi.co.in 12/06/02 05:45PM >>>
> > hi all,
> >
> > I have simple doubt.During reception of a frame is it required that all
> > the preamble(i.e 6 octets) has to be received or is it suffucicient that
> > a valid SFD is received before the frame can be processed.
> >
> > Thanks in advance
> > Mohan
> >
> > --
> > To unsubscribe from ethmac mailing list please visit
> > http://www.opencores.org/mailinglists.shtml
> >
> > --
> > To unsubscribe from ethmac mailing list please visit
> > http://www.opencores.org/mailinglists.shtml
> > --
> > To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml
>
> --

--
To unsubscribe from ethmac mailing list please visit
http://www.opencores.org/mailinglists.shtml
--
To unsubscribe from ethmac mailing list please visit http://www.opencores.org/mailinglists.shtml