Re: Hari Byte vs. Word striping
Mike,
There's nothing like a working chip to prove assertions. I'm not sure how close
you are to having a working Hari chip, but I hope to see a few of these later in
the year 2000. Until then, I believe that you're simply extrapolating existing 1
or 2 Gbps single-lane SerDes designs to parallel high-speed Hari designs. Your
power numbers are clearly reasonable expectations, but they are high. If you
can't meet these figures they'll be higher still. If Hari is to be cost
effective as a chip-to-chip interconnect, then I heartily agree with the
statement Shawn Rogers made in his recent response to your note:
"It (power) is also not likely to come down with migration to more advanced CMOS
process technologies without completely new architectures (i.e. migrating serial
path logic into parallel path logic)."
Bottom line is that new architectures of this type are required for cost
effective system designs at 10 Gbps. Traditional single lane 1/2 Gbps SerDes
designs which depend on Word Striping as a crutch will have difficulty
competing. New architectures which migrate serial path logic into parallel path
logic are compatible with either Byte/Column or Word-Striping. However, at this
point, the largest advantage of Word-Striping, compatibility with traditional
SerDes designs, goes away.
Let's get those chips built :-)
In your picture below, you are introducing many issues which are not part of the
Hari definition. Please feel to propose these to the P802.3ae, but don't confuse
them with the existing Hari proposals. Specifically, these issues are:
1) Skip or Insert/Remove protocol entails the processing of columns of Rs or
/K28.0/ for all protocols including 10 GbE, 10 GFC and InfiniBand in a protocol
independent fashion. The Skip description below is not compliant with the Hari
Skip function.
2) Trunking or aggregation is not supported by Hari since this function
significantly complicates the Hari definition. Most notable is the Hari
requirement that all 4 lanes be clocked synchronously. Trunking or aggregation
is typically associated with streams which are do not have common clocks. Hari
does not, and should not, support asynchronous streams. (especially is low-power
and low complexity is a requirement).
Best Regards,
Rich
--
Mike Jenkins wrote:
>
> Rich,
>
> In your recent response to Mark Ritter, a frequent refrain was:
>
> > Please prove your assertion by a means acceptable to this
> > standards body such as product, prototype, illustration, etc.
>
> This strikes me as a good idea, so I will attempt to detail a word
> striped embodiment, invoking existing designs as proof of concept.
> The diagram and description below show each word-striped HARI lane
> below as identical to existing functions in Fibre Channel designs.
> We have done many of these designs. As you have said, most of the
> power and die area is in the serdes. One lane is less than 2 mm**2
> of die area and less than 500 mW in 0.25 um CMOS, making a full
> word-striped HARI interface < 8 mm**2 and < 2 Watts. Future
> optimization to share resources, etc., would drive these numbers
> lower.
>
> I would be happy to clarify any issues with the description below.
> But, I would also very much appreciate a similar level of detail
> regarding byte striping. From the beginning, the uncertainty around
> implementation of byte striping has bothered me. The only independent
> estimate of the implementation difficulty of byte striping solicited
> by the HARI group came to the same conclusion, spawning this running
> debate. So, please provide whatever equivalent details there may be
> for byte striping, especially in the deskew function. Otherwise, to
> quote you again, "your claims by emphatic assertion are just that."
>
> Regards,
> Mike
>
> _________LANE 3_______________________________
> | _________LANE 2_____________________________|_
> | | _________LANE 1_____________________________|_ __
> > | | _________LANE 0_____________________________|_ ======>| \
> | > | | __________ __________ __________ | ====>|MUX\==>
> | | > | | | | | | | | ==>| /
> | | | >->| DESER. |==>| FIFO |==>| DECODE |==>=======>|__/
> | | | | |__________| |__________| |__________| | __
> < | | | | <======| \
> | < | | __________ _ __________ | <====|DE \<==
> |_| < | | | / | | | | <==|MUX/
> |_| <--|SERIALIZER|<======| |<======| ENCODE |<========<=|__/
> |_| |__________| \_| |__________| |
> |______________________________________________|
>
>
> * The functions within each lane are identical to existing Fibre
> Channel designs and similar to Gigabit Ethernet designs.
>
> * Clocks within each lane are 156 MHz or slower.
This is very misleading. Clocks in the SerDes operate at the bit rate of 1.5625
GHz, 10 times faster than stated.
> * The mux in the ENCODE/SERIALIZER path permits the FIFO output to
> be retransmitted through the serializer for diagnostics or use as
> a retimer function.
>
> * DECODE & ENCODE blocks can be bypassed, depending on application.
>
> * MUX & DEMUX are optional, depending on data path width in the ASIC.
>
> * Control logic across four lanes determines when to add/delete a
> "skip" word in one FIFO for speed matching. For delete operation,
> the normally rotating MUX address skips that lane. For an add
> operation, the MUX address dwells on that lane for two words.
> (This logic is identical to existing control logic for speed
> matching buffers with the four FIFOs viewed as one address space.
> The logic size is trivial.)
See above.
> * If a protocol requires "trunking" (or "aggregation") wherein four
> separate data streams are transmitted, the add/delete operations
> are even simpler -- the MUX address always rotates one count per
> word and add/delete is autonomous within each lane (exactly as in
> 1Gb/s Fibre Channel designs). In this case, the four lanes can be
> (and usually would be) asynchronous.
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Mike Jenkins Phone: 408.433.7901 _____
> LSI Logic Corp, ms/G715 Fax: 408.433.7461 LSI|LOGIC| (R)
> 1525 McCarthy Blvd. mailto:Jenkins@xxxxxxx | |
> Milpitas, CA 95035 http://www.lsilogic.com |_____|
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------------------------------------------------------
Richard Taborek Sr. Tel: 408-330-0488 or 408-370-9233
Chief Technology Officer Cell: 408-832-3957
nSerial Corporation Email: rtaborek@xxxxxxxxxxxxx
2500-5 Augustine Dr. Alt email: rtaborek@xxxxxxxxxx
Santa Clara, CA 95054