Re: More comments (clauses 49 & 46)
Louis Lin wrote:
> Hi Rich,
>
> I understand that the 8B/10B PCS in 1GE check beyond EOP of receiving
> packet to declare a a good packet. But it also doesn't deassert RX_DV
> until the IDLE check is completed. To RS, that's an error logically before
> EOP.
>
> I see your point to drop packets with /E/ on the /T/ column when 8B/10B
> is presented. If this is what we are going to do, what should 64B/66B PCS
> do when it sees /E/ on the /T/ column? the column size is 8 bytes here.
> So it could be
>
> DDDDDDDD
> TIIIIIIE
>
> Do we drop this packet? When 64B/66B PCS is on the same chip with
> MAC, I believe most designs will use 64 bits interface between MAC and
> PCS. You might not see the XGMII interface in this case.
>
> Thanks,
>
> Louis
>
> Rich Taborek wrote:
>
> > Louis,
> >
> > Trashing a packet when an error comes logically after the EOP is not
> > new. It is a characteristic of the 8b/10b transmission code which
> > supports error control including the detection of propagated running
> > disparity errors. 8b/10b is used by 1000BASE-X as well as proposed for
> > 10GE use.
> >
> > With respect to the error probability, I don't have the exact number
> > either. However, it is clear that either or both CRC and transmission
> > errors exist in very close proximity to the end of a packet. As I said
> > before, I'd rather err on the side of caution in order to REDUCE the
> > possibility of an undetected packet error.
> >
> > The 8b/10b EOP delimiter checking I'm proposed here is virtually
> > identical to that employed by 1GE. This delimiter checking was mandated
> > by Task Force motion in Tampa.
> >
> > Are you suggesting an alternate proposal based on the false trashing of
> > packets due to error conditions in very close proximity to the end of a
> > packet? If so, you'll have to present a detailed analysis of the false
> > error rate.
> >
> > Best Regards,
> > Rich
> >
> > --
> >
> > louis lin wrote:
> > >
> > > Hi Rich,
> > >
> > > I agree on that we need to keep the undetected packet error rate as low as
> > > possible. Before you guys decide to trash a packet when RS sees an error
> > > logically comes after the EOP( which is new ) , we need to know in what
> > > conditions this will happen as a result of packet data error? When it happens,
> > > what's the chance that those packets will pass CRC check?
> > >
> > > I don't have the exactly number here. But I believe the chance to pass
> > > error packets if we decide not to trash those packets is much lower than
> > > the chance to drop good packets if we decide to trash those packets, in this
> > > particular case. Unless we know that the /E/ coming after /T/ can only happen
> > > when there is an error in the packet data.
> > >
> > > Regards,
> > >
> > > Louis
> > >
> > > Rich Taborek wrote:
> > >
> > > > Louis,
> > > >
> > > > I don't agree. I believe that the MAC must trash the packet regardless
> > > > of good CRC because the MAC has no clue as to whether or not an 8b/10b
> > > > or 64b/66b or combination or multiples of the above are present. I
> > > > maintain that in all cases, it's NOT OK for the RS to treat it as a good
> > > > packet in order to keep the undetected packet error rate down. Note that
> > > > we're splitting hairs here since for 8b/10b in most cases, both 8b/10b
> > > > and the MAC's CRC check will call the packet bad.
> > > >
> > > > Best Regards,
> > > > Rich
> > > >
> > > > --
> > > >
> > > > Louis Lin wrote:
> > > > >
> > > > > Hi Rich,
> > > > >
> > > > > In your case of
> > > > >
> > > > > lane 0: DD
> > > > > lane 1: DT
> > > > > lane 2: DI
> > > > > lane 3: DE
> > > > >
> > > > > or all the case of /E/ been seen in the same column as /T/ but after /T/.
> > > > >
> > > > > If it's from 64/66B PCS, I don't think we need to declare it as a
> > > > > bad packet. If it's from 8B/10B PCS and the /E/ is a result of the
> > > > > data. I think the FCS checker in the MAC will trash the packet.
> > > > > In either case, it's ok for RS to treat it as a good packet.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Louis
> >
> > -------------------------------------------------------
> > Richard Taborek Sr. Phone: 408-845-6102
> > Chief Technology Officer Cell: 408-832-3957
> > nSerial Corporation Fax: 408-845-6114
> > 2500-5 Augustine Dr. mailto:rtaborek@xxxxxxxxxxx
> > Santa Clara, CA 95054 http://www.nSerial.com