Hi Eric,

Thanks a lot for all the insights!

I will have a look into the data-only-display possibility. I think I remember using standard modelines only, but I'm not sure anymore!

As for the pixel clock: I did go down to the lowest I could possibly go on my video card, scaling down the resolution and pixel clock as low as I could. Still the same symptom: the V-sync output on the TFP was just seemingly randomly switching roughly once every few seconds.

Interestingly, at very low frequencies, the signal to the actual receiver (monitor) did arrive but was heavily distorted.

You are right about the DVI splitter: it would definitely have been a more robust solution. I did find those before doing this PCB, but for some reason chose not to buy those. Maybe it was because they never seem to be available as 1-to-2 splitters but always more, resulting in a huge expensive chip. Or maybe it was because the DVI link I am looking at finally "sniffing" has a pixel clock that is very high, which most splitters don't support.

So why I chose the ADV is this: it has no input termination built in (or I should say: it's built in, but on a separate supply voltage so I was hoping to disable it by not connecting that voltage). That way the inputs would become high-impedance. So actually I was using it as an impedance-transforming buffer. My hope was that by keeping the tracks from the DVI cable to the ADV extremely short, and putting the device very close to the sending or receiving side, the ADV would be getting the same voltages as the actual receiver but without loading the signals much. Keeping everything short would then have to prevent huge distortions due to reflection at the ADV's input port.

I did some basic transmission line simulation to estimate just how short these tracks should be, and it looked like it should have worked, but reality doesn't agree!

However, even with no second receiver at all, and the termination of the ADV connected, the device still didn't work.

In any case, I find it very demotivating that I can't just put my scope probe on these signals to see what's going on... ;)

Ah, yes... It sounds like you know your signalling-stuff... I didn't see that the ADV's termination could be removed. I'd think that'd work. It also occurs to me, now that you mention it, that, of course, with 3D you're probably running at some pretty high pixel/refresh-rates. Yeah, that'd be difficult to lower without flicker, if the display can even handle it.

You're really pushing the envelope with this project! I don't blame you for being demotivated by not being able to 'scope. That's happening to me as well.

I did some DDR2 signal-analysis (simulation) for a summer... Man, the results were... intimidating. I think it was originally planned, by my higher-ups, that that would've been just a small portion of the overall summer's projects... Instead, it basically was *the* project. They had all the software, planned on buying a $50,000+ active/differential-input oscilloscope, all the design-ability... (tiny perfectly-length/impedance-matched traces, 16 layers with multiple power/ground planes, etc...) The idea was to figure out a rough idea for what'd be necessary to keep the signals in-spec for the PCB design, while leaving a little room for minor electrical-changes as determined necessary (changing resistors, etc). The results were, basically: we'd need a *perfect* simulation set-up, and a physical build that would match this ideal identically (right?). Every via, every burried via nearby (even not part of the circuit), every tiny difference in trace-length... even attempting to match lengths by "snake" traces had a tremendous effect on the signal integrity. Nevermind changing drive-strengths, and various attempts at alternative termination-schemes... 1% tolerance resistors wasn't nearly enough... and even characterizing those resistors' internal characteristics was necessary...

Of course, the *specs* are usually quite a bit more conservative than the actual hardware-requirements (intentionally), but this was a mission-critical project, there was no room for allowing out-of-spec...

Regardless, I imagine the bit-rate is significantly *lower* for DDR2 than for 120Hz refresh serial video-data at a high resolution!

On the plus side, if your software solution works-out, it sure would be easier and cheaper to reproduce :)

Bummer all that effort didn't work... Sounds like you know a bit about these things (mention, elsewhere, about characteristic impedances, signal simulation, etc). So this may all be obvious...

Had you experimented with slower signals (lower resolutions/pixel clocks), etc? The lack of a V-Sync signal *might* be due to a "Data-Enable Only" display, which *might* be indicated to the computer via the EDID. Which is possible to change. (I don't recall mention of that as an option in EDIDv1.3, but quite plausibly it exists now).

Degradation, OTOH... lower that pixel-clock! I managed to squeeze 60+ Hz out of a display spec'd for 60Hz at 108MHz by bumping the pixel-clock down to 100MHz and shortening the various blanking-times.... same issue, degredation at high pixel-clocks. Was amazed only 8MHz, 8% was enough to cause such a difference.

I guess it still defers a bit from a drop-in solution.

Also, it occurs to me, that ADV3003 looks to be just a one-in to one-out buffer...? So, you must be running two receivers off a single transmitter, somewhere... right? Either the ADV is before the TFP, in which case both the TFP and the monitor are attached to the ADV's retransmitter, or the ADV and TFP are both connected to the computer's transmitter...? This could be problematic, it would seem all these devices' receiving-sides have termination built-in... and these transmitters are likely only designed for the load of a single termination-point... What about replacing that ADV with a DVI-Splitter, instead? As I recall, they exist in chip-form.