Cascaded SN75LVCP422 re-drivers

Greg,

From what I can tell you should be able to cascade the LVCP422.  We do not "retime" the data and only apply the ISI equalizer to rebuild the signal.  Random jitter will accumulate at each link.  In looking at the Pericom switch, it appears to be just a FET switch with no equalization or retime either.  That mux is real loss and doesn't really fit into the ISI equalizer compensation.  With 3 re-drivers stages, this would infer 6 Pericom devices?  That sounds like a lot of loss and board trace for a simple re-driver to compensate for without retiming.

Do you have the ability to get some of the Pericom switches enough to attempt to do some preliminary testing?  I think that is the only way we well have a good indication if this is going to work.  Also, what is the final sink device?  Is it a fixed known device or is it any off the shelf device? 

Ken

Ken,

Thanks for the reply, some more information for you.

Pericom suggests that there PI2DBS412 is ~= 5-6" of FR4 trace (with proper layout) and recommends no more than 2 redrivers.  I'm assuming due to accumulated jitter. 

It appears as though I could use a TI PCIE mux, TS2PCIE412, as a drop in alternative to the PI2DBS412?  Pericom makes a 1:4 PCIE mux, but it is not available.  I couldn't find anything better than a 1:2 mux/switch with enough bandwidth in TI's product line(?).

If I go with 1:2 MUX's, I've got (worst case path)

Input(short cable from OMAPL138)->MUX->redriver->Mux->Mux->redriver->mux->mux->~4" FR4->SATA SSD (fixed known, no cable).

Theoretically that makes an equivalent distance of ~14" between re-drivers and followed by another (worst case) 16" to the SSD.  I could also try moving one mux stage in front of the first re-driver to reduce the length of the last stage.

The 'closest' to a test I've been able to do is through two PI2DBS412's (using an off the shelf SATA switch) and ~ 1m of cable, no redriver, and this which works fine, but doesn't tell me anything more than I can go through 2 muxs.

So long as we still think this is 'possible', we'll do a test board, but if we're told that we're crazy we'll look at alternative options.

Greg

Ken,

After some back and forth, we decided to drop 4 drives from the array, which gets rid of an extra mux stage, and also move the first re-driver to after the 2nd mux stage.  We know in testing that our drives work through 2 mux stages with no redriver.

This gives

mux->mux->re-driver->mux->mux-redriver->4-10" FR4->SATA SSD

I'm more confident in this than the previous plan.  Unfortunately I won't be able to measure the signal integrity at the last stage since we don't have test equipment that can measure SATA speeds.  Our current non-ideal 'test method' involves testing several drives that we know, through testing, work at various levels of signal integrity and adding increasingly longer SATA cables to gauge our margin at any given test condition (temperature, etc).

Greg

Hi,

Are there any new regarding this design option?

We are designing a new product with similar SATA sub-system functionality.

This looks like: HOST <-> SWITCHES (SN65LVCP404) <-> REDRIVERS (SN75LVCP422) <-> discs

I do not see any obvious show stoppers to this approach.  The only item that might be of concern is the OOB support from the LVCP404.