Re: D1.1 Clause 49 State Machine comments, part 2.
Hi Pat,
Now I understand that you are trying to achieve 4-bit hamming distance.
Although it will discard a valid packet ending with a no error T followed by
a 2-bit error that makes a C or S to D, it makes sense on Receive side.
I still can't understand why do you need this stuff on transmit side:
Because tx_raw is coming from XGMII side, either from local MAC or another
64b/66b receive R PCS, it will not have this kind of 2-bit error make D to C,
or
T to D etc. I think there is no need to have this stuff on transmit side.
Regards,
--Alex
pat_thaler@xxxxxxxxxxx wrote:
> Alex,
>
> The answer to your first set of questions was covered in the July proposal.
> To get hamming distance on the end delimiter of the packet, you need to
> check that both the block with the T and the block after it are appropriate.
> Otherwise, a two bit error could change a data block to a control block
> with one of the T type codes. If an error changed a data block into a
> false T, then the next block would have been a D or a T. It takes another
> at least two bit error to turn that block into an S or a C so we have a
> 4 bit hamming distance.
>
> On S, we get the equivalent check by only allowing a transition to S when
> the last block was T or C. If an S occurs after a D, S or E, then we
> transtion
> to E.
>
> None of this is new. The notation for it was different in the state diagrams
> from the proposal. Instead of checking next, they showed a delay of the
> output
> and sent the E when they received a D or T after a T. I changed to this
> because
> it is more consistant with the way that the check of the next code was done
> after T in 1 Gig and I felt it was easier to understand.
>
> I changed Z to C because XGMII calls these control not Z so it didn't seem
> right for a PCS to start calling XGMII characters by a name like Z. Also,
> it doesn't matter that the encoding of a character is different on one
> medium from the encoding on another. The character still retains its
> meaning.
> For instance, the character /E/ is represented by a control bit plus 8 bits
> containing 0xFE on XGMII, by 10 bits containing K30.7 (which is 011110 1000
> or 100001 0111) on XAUI and X PCS, and by 7 bits containing 0x1e on R PCS;
> but on all of them it is /E/. The control character, meaning the information
> it is carrying, doesn't change but its representation changes. Therefore,
> it still has its name.
>
> Pat
>
> -----Original Message-----
> From: Alex Deng [mailto:adeng@xxxxxxxxx]
> Sent: Thursday, November 02, 2000 2:35 PM
> To: pat_thaler@xxxxxxxxxxx
> Cc: stds-802-3-hssg@xxxxxxxx; Alex Deng; Sharat Prasad
> Subject: D1.1 Clause 49 State Machine comments, part 2.
>
> Hi Pat,
>
> One more question:
>
> Figure 49-11 --Transmit state machine:
>
> Could you please explain a little bit about
> when (T_TYPE(tx_raw)=T, why do you need to see if (T_TYPE_NEXT=(E+D+T))?
> If you need to do this stuff to T, then I think you should do the same stuff
> to
> S, that means:
> when(T_TYPE(tx_raw)=S, you need to see if (T_TYPE_NEXT=(E+S+T)), right?
>
> The similar question apply to Figure 49-12--Receive state machine.
>
> By the way, Figure 49-5 --64b/66b Block Formats:
> The Input Data side, I think it's better to use "Z0,...Z7", not "C0,...C7",
> just
> like what in your
> July's presentation, because C0 in Input Data side and C0 in Block Payload
> side
> are different,
> but "D0,...D7" are same.
>
> Regards,
>
> --Alex Deng