Logic simplification with new definition of TYPE bytes
Hi Dan,
Dan Alderrou writes:
> I have some questions about he 64B66B code definitions which are
> explained in the below Email I've had with Rich Taborek. We work
> together at nSerial and he asked me to contact you directly.
>
> I agree with Rich and think the frame format for the 0X3C TYPE
> is reversed from the others. Could you read the below Email
> between Rich and I and comment.
> > Rich Taborek writes:
> > Please go ahead and give Rick Walker a call and/or send him a note.
> > I'd also suggest getting together with him if you both decide that
> > it's easier to work things out face-to-face. He's located in Agilent
> > Technology Labs on Deer Park Rd off Page Mill Rd.. He's generally
> > very eager to get input on his proposal. Just tell him that you're
> > working with me. You're already beyond my level of expertise in
> > implementing the mappings so please fee free to make any decisions on
> > your own.
> > > Attached is a MS Word file which shows the 3C TYPE structure
> > > change to give a less complicated data path. In it, you see the
> > > three rows which define the 3-1 byte muxes. All of the other rows
> > > (Code definitions) line up the data bytes and the control "bytes"
> > > to the same boundaries.
> > >
> > > Only seven bytes of 3-1 muxes are required since the 0X71 TYPE and
> > > the 0XFF TYPE only have seven bytes of data.
I agree with your analysis, Don. We are just now getting around to
doing a gate level implementation with the goal of folding back any
design insight into simplifying the code definition.
I had originally swapped the Z fields for the "3C" frame type due to
some misguided "intuition" about making the implementation simpler.
Now that I've looked at the muxing structure, I've moved the fields around
exactly as you've suggested.
Here is our current TYPE byte mapping table:
Hari Input sync TYPE Frame Structure
---------- ---- ---- ------
DDDD/DDDD "01" n/a D0 D1 D2 D3 D4 D5 D6 D7
ZZZZ/ZZZZ "10" 0x1e Z0 Z1 Z2 Z3 Z4 Z5 Z6 Z6 Z7
ZZZZ/SDDD "10" 0x33 Z0 Z1 Z2 Z3 X:4 D5 D6 D7 D8
SDDD/DDDD "10" 0x78 D1 D2 D3 D4 D5 D6 D7 D8
TZZZ/ZZZZ "10" 0x87 X:7 Z1 Z2 Z3 Z4 Z5 Z6 Z7
DTZZ/ZZZZ "10" 0x99 D0 X:6 Z2 Z3 Z4 Z5 Z6 Z7
DDTZ/ZZZZ "10" 0xaa D0 D1 X:5 Z3 Z4 Z5 Z6 Z7
DDDT/ZZZZ "10" 0xb4 D0 D1 D2 X:4 Z4 Z5 Z6 Z7
DDDD/TZZZ "10" 0xcc D0 D1 D2 D3 X:3 Z5 Z6 Z7
DDDD/DTZZ "10" 0xd2 D0 D1 D2 D3 D4 X:2 Z5 Z7
DDDD/DDTZ "10" 0xe1 D0 D1 D2 D3 D4 D5 X:1 Z7
DDDD/DDDT "10" 0xff D0 D1 D2 D3 D4 D5 D6
Notes:
Time reads from left to right as on an oscilloscope.
Z fields are 7 bits,
D fields are 8 bits
X:N denotes an unused N-bit field
We currently are defining the fields to be serialized left to right,
and within each field from MSB to LSB. This will eventually
need be checked with the detailed Ethernet and HARI specs to make sure
that we are sending the bits in the same order that CRC32 is defined.
Otherwise, our analysis of error-multiplication on the CRC may be
invalidated.
You'll notice that the TYPE bytes have been modified. The bits are all
the same, but I've re-ordered the bits within each byte so that they are
easier to remember. This should only cause you to need to move a few
wires in your design :-).
TYPE byte table
---------------
HEX Binary HARI structure
--- ---------- ------------
00 0000 0000 reserved
1e 0001 1110 ZZZZ/ZZZZ
2d 0010 1101 reserved
33 0011 0011 ZZZZ/SDDD
4b 0100 1011 reserved
55 0101 0101 reserved
66 0110 0110 reserved
78 0111 1000 SDDD/DDDD
87 1000 0111 TZZZ/ZZZZ
99 1001 1001 DTZZ/ZZZZ
aa 1010 1010 DDTZ/ZZZZ
b4 1011 0100 DDDT/ZZZZ
cc 1100 1100 DDDD/TZZZ
d2 1101 0010 DDDD/DTZZ
e1 1110 0001 DDDD/DDTZ
ff 1111 1111 DDDD/DDDT
^^^^
||||
|\\\-----> These bits encode the number of data bytes
\ \\-----> in the frame payload
\ \----->
\
\-----> This bit distinguishes T-type frames from S,Z
type frames.
So in this ordering of the bits, the first bit of the TYPE byte
indicate whether the frame is an EOP (T-type) or non T-type of frame.
The next three MSBs count the number of data bytes in the T-type frame.
The remaining 4 LSBs are either exactly duplicated from the first 4 MSBs
or duplicated after being complemented, depending on parity value of the
first 4 MSBs:
So:
0000 has even parity, type byte == 0000 0000
0001 has odd parity, type byte == 0001 1110
....
The logic for generating and verifying valid TYPE bytes should
be obvious and simple due to this construction.
This small change makes the TYPE bytes much easier to remember, while
guaranteeing a 4-bit minimum Hamming distance within the set.
Please let me know if you see any other opportunities to simplify
the code implementation.
Best regards,
--
Rick Walker
--------
> > >At 06:04 PM 2/14/00, Don Alderrou wrote:
> > >>Hey Rich,
> > >>
> > >>I don't understand Rick Walker about the HW complexity associated
> > >>with the way he is pulling-out the seven-bit control codes and
> > >>the eight-bit data. The TYPE bits of 3C (0011 1100) which
> > >>correspond to the Hari structure of ZZZZ/SDDD seems backwards as
> > >>you say and it also causes more complexity in the data path. His
> > >>coding for the control logic seems correct and should not change.
> > >>
> > > >>The way it is currently defined, the RX data path to select/move
> > > >>the 7-bit control "bytes" and the eight-bit data before the
> > > >>8B10B encode will have six bytes of 4-1 muxes and two bytes of
> > > >>3-1 muxes. If the data bits were arranged like you mention and
> > > >>I've shown below, the data path would just need seven bytes of
> > > >>3-1 muxes and one byte of 2-1 muxes before the 8B10B encode.
> > > >>These extra muxes can also be thought of as the "nibble swap"
> > > >>described below which would also not be needed if the encoding
> > > >>was changed.
> > > >>
> > > >>You should ask Rick to change the code definition from
> > > >> 3c 0011 1100 ZZZZ/SDDD
> > > >>to this.
> > > >> 3c 0011 1100 SDDD/ZZZZ
> > > >>This would make the control seven-bit "bytes" Z0:7, Z1:7, Z2:7,
> > > >>Z3:7, and data bytes D5:8, D6:8, D7:8 *line up* in the same bit
> > > >>positions as the other codes. Specifically, look at the
> > > >>position of the bytes in the "Pure Data Frame" and the "Pure
> > > >>Control Frame." All of the other Frames have the bits lined-up
> > > >>with them except for the TYPE 3C frame.
> > > >>
> > > >>Another way to think about this is to look at the data path as
> > > >>eight eight-bit registers. Looking at Rick's presentation
> > > >>starting on slide 5 with the Code definition, the first "Pure
> > > >>Data Frame" needs D0:8 put in the first byte, D1:8 to the second
> > > >>byte and so forth. Since the "Pure Control Frame" has the first
> > > >>control byte, Z0:7 at the second "byte" location, it needs to be
> > > >>muxed (2-1) into the first location and so forth for the other
> > > >>"eight bytes." Looking at the "Mixed Data/Control Frames", the
> > > >>first data byte, D0:8 is always in the second byte location, but
> > > >>it is pure data and not a control "byte," so this requires seven
> > > >>of the 2-1 muxes to change into 3-1 muxes. Now since the TYPE
> > > >>3C has the 5th data byte, D5:8 in the second position and the
> > > >>first control "byte" in the 5h location, six of the 3-1 muxes
> > > >>are required to change into 4-1 muxes and the last byte of 2-1
> > > >>muxes change into a byte of 3-1 muxes.
> > > >>
> > > >>Sorry this was so long. If you look at the Dallas presentation
> > > >>and re-read the above, it should make sense. Let me know if
> > > >>Rick is at the FC meeting and I'll send/fax you a diagram.
> > > >>Otherwise you can forward this to Rick Walker and I can discuss
> > > >>it with him directly.
> > > >>
> > > >>--Don