Re: D2.0 49.2.11.1.1 Constants E
Hi Pat,
If we allow the transaction from TX_E to TX_S, the problem
indicated by Alex won't exist. Or you need to redefine E.
I can't think of any condition for MAC or XGMII to send /E/
between packets. Assume that the MAC on top the PCS mis-behaves.
Trash or not, PCS should still treat both cases (in Alex's mail) the same
way.
I have another question in your Receive State Machine,
The data coming in from media look like
.....
DDTC/EEEE (T)
CCCC/CCCC (C)
it will be passed up to XGMII and XGMII won't trash this packet.
But if the data coming in look like
....
DDTC/CCCC (T)
ECCC/CCCC (E)
what XGMII will see is
.....
EEEE/EEEE
EEEE/EEEE
And this packet will be trashed. Is it what PCS intend to do?
Regards,
Louis
Alex Deng wrote:
> Hi Pat,
>
> I still think your definition of "E" is not accurate.
>
> If I followed your definition of "E", just as I said last time,
> if a packet I got from XGMII/XAUI is something like:
> ECCC/CCCC
> CCCC/SDDD ( or SDDD/DDDD)
> DDDD/DDDD
> ....
> TCCC/CCCC
> will be transmitted like: E (Frame) -->E --> D ....-->T.
> On the receiver side, this packet will be trashed.
>
> But other packets like:
> CEEE/EEEE (or CCCC/EEEE or CECC/EECC ...)
> EEEE/SDDD (or SDDD/DDDD or CEEE/SDDD ...)
> DDDD/DDDD
> ....
> TCCC/CCCC
>
> will be transmitted like: C (Frame) -->S-->D...-->T.
> On the receiver side, these packets will not be trashed.
>
> That means this protocol is not consistent.
>
> Thanks,
>
> --Alex
>
> Alex Deng wrote:
>
> > Hi Pat,
> >
> > If this is the case, that means if a packet transmited like
> > ECCC/CCCC ---->E
> > CCCC/SDDD ---->E
> > ...
> > will be trashed,
> >
> > but a packet transmite like
> > CEEE/EEEE ----> C
> > SDDD/DDDD ----> S
> > ...
> > will not.
> >
> > Thanks,
> >
> > --Alex
> >
> > pat_thaler@xxxxxxxxxxx wrote:
> >
> > > Alex,
> > >
> > > I don't ever generate an ECCC/SDDD unless that is what I got from the
> > > XGMII/XGXS. We don't have a Hamming distance need to propogate an error from
> > > the XGMII/XGXS column before an S into the packet and the 10GBASE-X based
> > > Phys won't don't discard such a packet. Therefore, it is fine as it stands.
> > > An ECCC/SDDD is an S. A frame with 8 control characters and the first
> > > character is an E so that the receiver will recognize an E frame sent by the
> > > transmitter as an E frame. All 8 characters will be E in that case, but it
> > > seemed burdensome to check for 8 Es and the first character being an E is
> > > enough.
> > >
> > > If you do not agree, submit a comment.
> > >
> > > Pat
> > >
> > > -----Original Message-----
> > > From: Alex Deng [mailto:adeng@xxxxxxxxx]
> > > Sent: Tuesday, December 05, 2000 4:08 PM
> > > To: THALER,PAT (A-Roseville,ex1)
> > > Cc: stds-802-3-hssg@xxxxxxxx; Alex Deng
> > > Subject: Re: D2.0 Figure 49-7
> > >
> > > Hi Pat,
> > >
> > > Another question:
> > >
> > > Page 297, 49.2.11.1.1 Constants
> > > Following your definition, looks like ECCC/SDDD is a S,
> > > but it should be a E, right?
> > >
> > > Thanks,
> > >
> > > --Alex
> > >
> > > "THALER,PAT (A-Roseville,ex1)" wrote:
> > >
> > > > Alex,
> > > >
> > > > Looks like I made a cut and past error. The type field for CCCC/ODDD
> > > should
> > > > be 0x2d. Since we are in task force ballot, a comment needs to be
> > > submitted
> > > > to correct this. Will you put a comment in on it? If not, I will.
> > > >
> > > > Pat
> > > >
> > > > -----Original Message-----
> > > > From: Alex Deng [mailto:adeng@xxxxxxxxx]
> > > > Sent: Tuesday, December 05, 2000 2:28 PM
> > > > To: THALER,PAT (A-Roseville,ex1)
> > > > Cc: stds-802-3-hssg@xxxxxxxx; Alex Deng
> > > > Subject: D2.0 Figure 49-7
> > > >
> > > > Hi Pat,
> > > >
> > > > In Figure 49-7 -64b/66b Frame Formats:
> > > > The "Type Field" of the first and second row are the same "0x1e".
> > > > What's the type field for C0C1C2C3/O4D5D6D7 ?
> > > >
> > > > Thanks,
> > > >
> > > > --Alex