Compensating for bus driver delay in a synchronous design

[Yansi]

Hello,

firstly I would like to apologize the title of the thread may be imprecise, I do not know a better name for this.

So what's the deal? Suppose I have a synchronous design in a PLD and I would like to interface some external peripherals with it.  But there is a bus driver IC in between the PLD and the peripheral circuitry.  For (a typical) example a SN74ALVC164245 to convert 3 to 5V levels and back.

But there is a problem: The bus driver has a significant signal propagation delay. At say 160MHz, the CLK period is 6.25ns. The propagation delay of the bus driver is almost comparable to the clock period. What could be done about it?

For a synchronous system to work, I need the tPH + tSU to be less than tCLK.  tSU is typically small, say 1ns, so I need the bus driver plus the tPD from the PLD to fall within those 5.25ns. That seems impossible, as for example a typical ALVC logic gates are rated for a tPD of up to 6ns max. alone!

How should one solve this?

(sidenote: Trying to design a 16bit synchronous interface, ie 16 bidirectional bits plus CLK signal.  16bits passes through the ALVC16245, but what to do with the CLK signal and the delay?).

Thank you for pointing me to a correct direction.

[rstofer]

Pass the clock through the same delay?  Then you have to account for the round trip delay and, of course, there will be another 2 clock delays synchronizing the returning signals.

[nctnico]

Hmmm, 5V levels and 160MHz? That doesn't seem like a good idea to me. If the receiving end is TTL compatible you should be able to drive it with 3.3V directly.

[T3sl4co1l]

160MHz is in the range where you should be looking at LVDS + serdes.  Clock skew over any length of bus can be equally disastrous.

And yeah, max t_PD is basically a useless figure.  You have to honor it for a proper worst case design, but that may not be practical.  It's worst at high temperature and low voltage, which if you're not encountering, you can ignore.  But that doesn't help much as far as what you should be using.  If you can adjust timing and test margin at assembly time, that would be best.  But that's a sucky solution, too.

Also, what PLD runs that fast?  Do you mean FPGA..?  If so, you should probably use the LVDS or serdes functionality built in, or change to one that has it; makes this sort of thing much easier.

Tim

[NorthGuy]

If you use source-synchronous clocking then your main concern is the skew between lines within your bus drives. TI doesn't post any skew data, thus you cannot predict if it's going to work or not. Unless, of course, you characterise the skew by yourself.

Driving directly, as nctnico suggested, eliminates the skew introduced by the bus driver, thus may be the best bet for you.

If you do want a bus driver, use sn74lvc16t245. It's newer and faster.

[asmi]

160MHz is in the range where you should be looking at LVDS + serdes.  Clock skew over any length of bus can be equally disastrous.

It's actually not that fast for any more-or-less modern FPGA. Heck even DDR3 mostly use single-ended signals, even if they are referenced to Vcc/2 and don't have large swings. 5 V is rather extreme swing, but I've seen enough of 3.3 V buses that run at that frequency or even faster. Common example is HDMI TX or RX chips, which have parallel bus running at 150-160 MHz.