Re: Interface reality check
At 11:21 AM 4/14/00, Bharadwaj S Amrutur wrote:
>For example, instead of transporting the fixed
>8-bit hex pattern for \T, the 64/66 coder merely indicates which byte if
>any of
>the 8byte
>frame, holds the \T non-data octet. This requires only 4bits (actually log2(9)
>bits).
>Similarly for Sp, instead of transporting the corresponding fixed 8-bit
>pattern,
>the coder indicates which of the two byte locations the Sp octet is present.
>This
>requires 2-bits (actually log2(3) bits ). You can combine the above: 8
>possible
>locations for T, 2 for Sp and one where none of these two are present.
>This can be represented in 4 bits.
>
>Similarly, since only 12 non-data octets , Z, are supported, the full
>8-bit hex
>
>pattern of Z is not transported, but is compressed into a 6-bit pattern.
>(Actually
>8 are mapped directly into 6-bit entities, and the remainig four which
>correspond
>to headers of ordered sets are treated a bit differently)
>
>Hope I have reduced entropy a bit.
>
>Regards,
>Birdy
Birdy,
Have you changed the 64B/66B proposal? If so, can you send the details
to the reflector? In the March update from Rick Walker
http://grouper.ieee.org/groups/802/3/ae/public/mar00/walker_1_0300.pdf
The control codes (z) are mapped into 7-bit line-codes (see page 6.) Is
the above description of a 6-bit pattern a typo or are there some major
changes to the proposal in the works?
Thank you in advance,
--Don
--------------------------------------------------------------
Don Alderrou mailto:dona@nserial.com
nSerial Corporation Tel: 408-845-6105
2500-5 Augustine Dr. Fax: 408-845-6114
Santa Clara, CA 95054 http://www.nserial.com/