RE: Hari: Question regarding column versus word striping, R. Taborek response to S. Sabato
> -----Original Message-----
> From: widmer@xxxxxxxxxx [mailto:widmer@xxxxxxxxxx]
...
> 1) The framing and IPG specifics for a word striped interface is
> independent of the number of lanes.
> 2) The IPG can be zero for extended periods of time. At boundaries of
> frequency domains, there must be of course periodic Idles which can be
> removed. The granularity for insertion or removal is a single word,
> regardless of the number of lanes.
...
>
Mr. Widmer,
I'm reading these two points and they're bugging me.
I'm speaking from the "ASIC" side of the world, and on this
side of the world, the designs I have been involved with have
operated under the following assumptions/design rules
(please pardon me if they seem too tutorial):
a) That at some point, a received data stream makes a
transition between the recovered receive clock domain,
and a local clock domain running at -nominally- the
same rate.
b) Because these two clock domains are not running at
-exactly- the same rate, you need some sort of buffering
between the clock domains to smooth out the transition.
c) Eventually, because of the rate difference, you will
need insert something into, or delete something from,
this smoothing buffer to keep from losing data.
d) The size of your smoothing buffer is dictated by
several factors, but one key factor is the maximum run
length between "deleteable thingies". If my buffer is
smaller than the size dictated by the maximum run length,
I will lose data.
e) Losing data is a bad thing.
Addressing your item (1):
I've looked at Mr. Ritter's presentation from November 99.
It appears that a key assumption is being made that the
received stream that passes through the smoothing buffer
is exactly one word wide. This means you are assembling
the lanes back into the word stream while in the recovered
clock domain.
(see page 10 of Mr. Ritter's presentation ritter_1_1199.pdf)
I've been assuming up until now that I would keep each
lane separate while in the recovered clock domain, pass
each 'lane stream' through a smoothing buffer, and then
assemble the data stream in my local clock domain according
to my own architectural needs - which, by the way, may be
something other than a single word stream. (In general,
I have found it 'safer' to minimize the number of things
done within the recovered clock domain. I guess that's
just my personal experience.)
Since I had (in my mind) expected to run the separate lanes
through individual smoothing fifos, I had expected that I
would have a 'deleteable thingy' available in each lane at
the same time - such that I could cause a deletion at the
same time in all lanes, and therefore keep them aligned.
I think if you make the assumptions I made, then Mr. Taborek's
statements are not false - they are true in a different
'assumption space' than the one you used.
Addressing your item (2):
I'd hate to think we were setting out to have an arbitrarily
long time between 'deleteable thingies'. Because then I
would either have to have an arbitrarily large smoothing buffer,
or I would have to decide to violate my assumption (e) and hope
that I didn't have to throw away too many packets. I'd rather
not do that!-)
It occurs to me that I may have misunderstood something, so
please do correct any misconceptions I may have stated above.
thanks for your time! - js
jeff stai, QLogic corp.
3545 harbor blvd, costa mesa, ca 92626
714-668-5425vm, 714-668-5095fx
j_stai@xxxxxxx http://www.qlc.com/