Re: Clause 46: Start of frame reception
Danielle,
Danielle Lemay wrote:
>
> Ben,
>
> If a MAC receives this frame and only /S/ is required for reception,
> where is the frame supposed to start ?
>
> Lane 0 1 2 3
> /S/ P P P
> P P /SFD/ D
> D D D D
> D D D /SFD/
> D D D D
> ...
It depends upon your implementation. If your implementation
is designed to really know nothing about lanes, then your RS
only checks that /S/ comes in lane 0 then sends everything else
to the MAC. The MAC will parse the data as it arrives, find the
first SFD and start the packet on the first D.
If your implementation cares about lane alignment, then
your RS is allowed to ignore the data on lanes 1 & 2 and
discards all bytes up to the second SFD.
The case you've described above is arguably a no win case.
The preamble should never have been shortened by a single
byte so it should never occur in the first place. An SFD
that falls where your first SFD does is likely a bit error
somewhere converting the 0x55 to a 0xD5. Also, if the
second byte in lane 3 is not an SFD, it is probably also
due to a bit error. The second SFD in your example is
probably part of the SA but now you're thinking it is
the SFD so you'll likely get a CRC error on the packet.
The bottom line is that this scenario is, in all likelihood,
a bad packet that will not be correctly received. However,
the first 2 paragraphs above describe how you're supposed
to handle it.
Regards,
Ben
>
> thanks,
> Danielle
>
> > -----Original Message-----
> > From: Ben Brown [mailto:bbrown@xxxxxxxx]
> > Sent: Friday, May 11, 2001 6:58 AM
> > To: Danielle Lemay
> > Cc: stds-802-3-hssg@xxxxxxxx
> > Subject: Re: Clause 46: Start of frame reception
> >
> >
> >
> >
> > Danielle,
> >
> > I think you have it backwards:
> >
> > Danielle Lemay wrote:
> > >
> > > Hi,
> > >
> > > What are the rules for receiving the start of a frame?
> > >
> > > On transmission, the following rules apply:
> > >
> > > a) /S/ must appear in lane 0
> > > b) /SFD/ must appear in lane 3
> > > c) Only Preamble may appear between /S/ and /SFD/
> > > d) Preamble may be of any length
> >
> > All but rule c are applicable to the RECEIVE side of the RS
> > (Clause 46). The RS doesn't check the content of the preamble
> > other than to verify that there is an /S/ in lane 0. It is
> > allowed to discard packets that don't have the SFD on lane 3
> > but even this is not necessary. The MAC is defined as 1 bit
> > wide so it knows and cares nothing about lanes.
> >
> > On transmission, a MAC will transmit exactly 7 bytes of preamble
> > and 1 byte of SFD. The RS converts the first byte of preamble
> > to /S/ and aligns the /S/ to lane 0 by modifying the IPG
> > according to the rules of the Deficit Idle Counter (DIC). The
> > RS never modifies the length nor the content of the preamble
> > other than the first byte. For that matter, there is nothing
> > currently in the standard that allows for the preamble length
> > or content to be modified by any sublayer. However, the receive
> > RS must be able to receive a preamble of a modified length with
> > modified content should it receive one. (Go figure :)
> >
> > >
> > > Clause 46 suggests that only (a) is necessary to receive a frame.
> > > Is that the intention ?
> >
> > Yes, rule a is the only necessary rule. Rule b is allowed but
> > not necessary.
> >
> > Regards,
> > Ben
> >
> > >
> > > thanks,
> > > Danielle
> > >
> > > *******************************************
> > > Danielle Lemay
> > > Design Engineer, Nishan Systems
> > > dlemay@xxxxxxxxxxxxxxxxx
> > > 408-519-3985
> >
> >
> > --
> > -----------------------------------------
> > Benjamin Brown
> > AMCC
> > 2 Commerce Park West
> > Suite 104
> > Bedford NH 03110
> > 603-641-9837 - Work
> > 603-491-0296 - Cell
> > 603-626-7455 - Fax
> > 603-798-4115 - Home Office
> > bbrown@xxxxxxxx
> > -----------------------------------------
> >
--
-----------------------------------------
Benjamin Brown
AMCC
2 Commerce Park West
Suite 104
Bedford NH 03110
603-641-9837 - Work
603-491-0296 - Cell
603-626-7455 - Fax
603-798-4115 - Home Office
bbrown@xxxxxxxx
-----------------------------------------