Re: Hari Byte vs. Word striping
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.
* 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.)
* 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@xxxxxxxx | |
Milpitas, CA 95035 http://www.lsilogic.com |_____|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~