Project: HDMI/DVI out for STFM

[exxos]

Exxos are you running a stock power supply in your test machine? I have a stock PSU, I think Troed has a modern replacement. My 5v level is actually about 4.7v. Dunno if it could be connected but couldn't hurt to rule it out...

I have my own brand PSU & a re-cappd SR98.. both will be outputting 5V, but don't which one I used.. Will try and test both when I get home later, but won't be until around 10pm.

[ijor]

One thing I'm not following, is if there is a drive problem on D9, why would it work on some boards but not other?

Well, I don't know for sure of course. It doesn't seem to depend on the chipset. It doesn't seem to be a timing issue. It could be a functional issue, such as a bug in the Verilog code. But doesn't seem very likely that a bug would affect some computers and not others.

So I was thinking it might be perhaps a powering issue. Voltage level, ground noise, etc, this could change depending on the computer, right?

Note that I didn't mean it could be a drive problem on D9, but a drive problem on the FDIR signal. FDIR is the signal that controls the bidirectional level shifter.

I don't know about FPGA , but on pld chips they have input only pins which can catch you out sometimes.

Yes, the FPGA also has input only pins. But the compiler would not allow you to put output or bidirectional signals on input only pins.

[exxos]

I have been thinking along the lines that the stm if failing more than the stfm could be a power issue.

[Gunstick]

You didn't specify how you are reading the bus capacitance. If you are just reading from unpopulated RAM space, then this doesn't depend on Shifter at all.

It's the classic setting of the screen start address outside of physical RAM. Usually you see noise, but in fact that noise is the bus activity. If you do that in a fullscreen, the noise is just a static pattern because all activity is synchronized.

[czietz]

Just another (probably crazy) idea: On a different plug-in board that I recently worked on, there was a big problem with ground bounce. Modern, very fast CMOS output drivers can inject a short but intense burst of current into ground while switching logic levels. Combined with the inevitable inductance of the ground traces and pin/socket connections, a momentary shift of the ground level of the plug-in board (respective to the Atari mainboard ground) happens.

In case of the board that I mentioned, this ground bounce was several volts! This caused an input signal that was supposed to be "high" (5V referenced to the Atari mainboard ground) to be only 1 - 2 V referenced to the plug-in board ground. Thus, this was registered by the circuit on the plug-in board as the signal seemingly glitching "low", causing malfunctions that were inexplicable at first.

One can even reason that this behavior depends on the Atari mainboard, because different revisions will have different ground tracing, different layout of the decoupling caps, etc.

Which ground was used for the scope traces posted in this thread? Do the traces look different if another ground point is used?

[ijor]

It's the classic setting of the screen start address outside of physical RAM. Usually you see noise, but in fact that noise is the bus activity. If you do that in a fullscreen, the noise is just a static pattern because all activity is synchronized.

Ok, that effect doesn't depend on Shifter. It's something between MMU and the system board.

In this particular case, we are seeing a similar behavior but when it shouldn't happen.

[ijor]

Just another (probably crazy) idea: On a different plug-in board that I recently worked on, there was a big problem with ground bounce. Modern, very fast CMOS output drivers can inject a short but intense burst of current into ground while switching logic levels. Combined with the inevitable inductance of the ground traces and pin/socket connections, a momentary shift of the ground level of the plug-in board (respective to the Atari mainboard ground) happens.

In case of the board that I mentioned, this ground bounce was several volts! This caused an input signal that was supposed to be "high" (5V referenced to the Atari mainboard ground) to be only 1 - 2 V referenced to the plug-in board ground. Thus, this was registered by the circuit on the plug-in board as the signal seemingly glitching "low", causing malfunctions that were inexplicable at first.

I don't know if it's crazy, but it sounds a lot like this is exactly what might be happening here. FDIR looks high from the system ground, but might be low from the daughter board !

Smonson, besides possible board level fixes, there are parameters that you can adjust at the FPGA. You might need to configure a slower slew rate, and/or perhaps a not so strong driving power. You can configure these parameters per pin on the assignment editor.

It might be also worth to consider in adding some delays. With the current configuration, and even if everything works ok, there is some bus contention until the transceiver switches direction. It is very short, so might be not significant. Just noting for completion.

[exxos]

ST's do have a very bad system ground which I have run into many times. Though Icky says there is the same issue on the STF remake board, that has a solid dedicated gnd layer and vcc layer. Not saying thats makes it bullet proof, but should at least show some improvement over a ST/F for example.

As also said, it could be a gnd bounce across the FPGA boards themselves.

[ijor]

On a second thought ... this should be just a short glitch, right? Say, a few nanoseconds? Then eventually FDIR has to rise before the cycle ends. So it doesn't match exactly the behavior ... Still, gnd bounce might produce all sort of ill effects I guess.

Edit: In any case, it might be important to connect the scope ground to the daughter board ground. At least when probing the signals at the FPGA side.

Edit 2: A few nanosecs, not a full microsec !

[czietz]

On a second thought ... this should be just a short glitch, right? Say, a few nanoseconds?

Yes, the ground bounce glitch is short. In the case that I was remembering it was an asynchronous input to the FPGA that would sometimes but not always cause a reaction even if it was only low for nanoseconds.