Electronics > FPGA

Arrow DECA MAX 10 board for $37

<< < (37/39) > >>

BrianHG:
The new complete BrianHG_DDR3_Controller v1.50 here:
https://www.eevblog.com/forum/fpga/brianhg_ddr3_controller-open-source-ddr3-controller/msg3606415/#msg3606415
And here:
https://github.com/BrianHGinc/BrianHG-DDR3-Controller

migry:
I hope you all enjoying using your dirt cheap DECA  :-+

I have used mine in a project to extract digital level video from an Atari STe, and then use the DECA to generate HDMI (since it has a nice easy HDMI transmitter chip to utilise).

The picture shows the video (4 bits each: R,G and B) buffer and level translator, for which I had a PCB manufactured by JLCPCB. I used the wrong footprint for the buffers  |O

On the DECA is a "hat". There is a 20 way IDC cable with headers which connects them. I couldn't get the built in audio to work so I added an external PCB/module.

Verilog software was developed while it was a still a mess of wires. But I was rewarded with a pixel perfect 50Hz Atari medium res display. Much better than the jail bar ridden mess which came out of the composite video. I do not have a RGB (15kHz) monitor or TV (BTW).

Initially scoping the signals, they were a horrendous mess. Lots of spikes everywhere. I output the received vsync and hsync on debug output pins, and they looked horrendous. I eventually figured it was all down to @@@@-poor high speed (high slew rate) signal mis-management. As an experiment, as seen in the photo, I added 1k resistors into the hsync and vsync lines out from the Atari and this fixed the syncs. The debug outputs from the FPGA were now clean.

I am now suffering from a new problem. I use the 32MHz clock, generated on the FPGA to sample the incoming signals. Apart from vsync and hsync is "display enable" or de. I use this to detect the start of active video. I am pretty sure that I am not sampling this signal cleanly using the 32MHz. It worked on the mess of wires since code would be compiled differently and delays would be different.

Oh BTW, the 32MHz clock generated by the DECA FPGA goes to the STe and is used as the video clock, so it is synchronous with the RGB and sync outputs back from the STe. This feature is not available on the standard Atari ST (note no 'e').

I simply want to use the input delay feature of the IO pins, to tweak de. I know that this is a bad one off solution, but I do not plan to publish the code and the project is a one off. I just need it to work. I need to tweak de, by adding a small delay so that it is not transitioning when sampled by the 32MHz clock. Over time the picture stabilises, then jitters again, then badly jitters, repeat and rinse. Adding finger capacitance changes the jitter, which makes me confident that the issue is simple a sampling point problem.

My question is, how do I use the MAX10 input buffer delay feature, and how do I code this in Verilog?

NOTE: I did some googling and found a solution for the Xilinx Spartan6, where you can specify directives to the compiler in comments (IOB).

I have read the PDF for the MAX10 I/O and I do see what looks like a programmable delay for the input signal on DDR pins. I tried to find some example Verilog code, but my google foo failed me once again.

BrianHG:

--- Quote from: migry on January 19, 2022, 10:33:04 pm ---I simply want to use the input delay feature of the IO pins, to tweak de. I know that this is a bad one off solution, but I do not plan to publish the code and the project is a one off. I just need it to work. I need to tweak de, by adding a small delay so that it is not transitioning when sampled by the 32MHz clock. Over time the picture stabilises, then jitters again, then badly jitters, repeat and rinse. Adding finger capacitance changes the jitter, which makes me confident that the issue is simple a sampling point problem.

--- End quote ---

Get rid of the capacitors...  Input delay buffers operate in to +/-50 picosecond range, up to +/- a few nanoseconds.  Way too small and useless for 32MHz.  This was designed to correct for pin-pin and PCB routing delays for buses above 300MHz way into the 900MHz range.

Here is what you should do:  Take in 32MHz.  Multiply by 8 on the MAX10 PLL for an internal 256 MHz.  Now, sample the input at 256MHz and have your HDL code select 1 of the 8 phases to sample from to get that 'sweet' 32 MHz sampling spot.

You can have a user set selection which phase to use, or if you want smart HDL, you can work out the sweet spot on the fly by looking for when the inputs transition and when the data has a 2-3 position clean stable value.  (I used to sample the Amiga's DENISE 12bit video output and different revisions of the chip has different ns delay skews on the data output bus VS it's 14.31818 MHz source clock  A smart self timing alignment is the best way to go whereas in the old days, we used to use a re-clocking PLL with a trimpot to phase adjust our data capture clock to zero in on that sweet data sampling spot.)

If you truly want to go all out, you can also use DDR input buffers for your input giving you an equivilant 512MHz sampling rate with 1 of 16 phase positions to select your source data from.

And, don't forget about using 'Signal-Tap' within Quartus where you can get your 256/512MHz logic analyzer of the input data + your HDL code's registers allowing you to capture/see what's actually happening on your inputs and HDL in real-time.


I doubt you would need to, but if the ST's output is crap beyond belief, you may select a different 1 or 8 sampling position phase for each input, though, this is an extreme case of fixing a problem which is generated elsewhere.

An example is if the Atari ST has a different logic IC generating the video sync output compared to the 12 bit RGB data and you have no choice but to correct for a different skew delay where in an analog RGB monitor, this skew would have no effect.

RoGeorge:
Nice project!  :-+

I didn't used my DECA recently, though there is a pile of projects for it in the bucket list.

Analog TV signals are using 75 ohms impedance.  If that Atari output is for a standard video monitor, then you need to use 75 ohms impedance coax cables (preferably same length for vertical and horizontal sync).  These 75 ohms coaxial cables (can be as well video cables, often RCA terminated coax cables, like the ones for old VCRs) must be terminated by a 75 ohms resistor at the other end of the cable, in parallel with the input of the FPGA.  Without impedance matching, the signals will reflect back and forth in the cable, creating horrible spikes, echoes and waveform degradation.

I don't recall if the ADC inputs in the DECA board already have 50 ohms low impedance input, I suspect they are not.  In case they do have 50 ohms, then a series resistor of 25 ohms is needed at the FPGA side of the cable.

Series 1k could be a workaround, but that is expected to degrade high frequencies, so more jitter and less detailed edges for pulses.  A proper 75 ohms impedance matching and 75 ohms coaxial cables should work better.



TV signal synchronization can be very tricky when the signal source has an independent clock.  I did once a machine to overlay video subtitles, which immediately showed the same clock and syncro problems you are are talking.  Back then I simply synchronized the clock of subtitling computer by pausing the clock (it was a ZX Spectrum, not Atari) so to make the computer clock "driven" by the analog video signal coming from a VCR.

Not sure if your Atari setup allows this trick.  If not, whatever you do, there will be skew between the clocks, maybe buffering a full frame might fix it.  I have no idea how sensitive the HDMI standard is against time jitter.

Also, analog TV were very tolerant regarding lines jitter, or frames jitter/frequency, and they were locking well with the source signal in a much broader range than the specs of broadcasting TV standards.  Therefore many computers back then were far for compliant, so I wouldn't be surprised if some of the jitter comes from the Atari hardware itself, but let's hope it is not that.



I'm sure many will chip in with new tricks and ideas for many pages to come, video conversion is a tricky problem, this new project of yours deserves its own topic. 

BrianHG:

--- Quote from: RoGeorge on January 20, 2022, 12:23:27 am ---Analog TV signals are using 75 ohms impedance.  If that Atari output is for a standard video monitor, then you need to use 75 ohms impedance coax cables (preferably same length for vertical and horizontal sync).  These 75 ohms coaxial cables (can be as well video cables, often RCA terminated coax cables, like the ones for old VCRs) must be terminated by a 75 ohms resistor at the other end of the cable, in parallel with the input of the FPGA.  Without impedance matching, the signals will reflect back and forth in the cable, creating horrible spikes, echoes and waveform degradation.

--- End quote ---
It sounds like he is generating the video clock for the STe and sampling the binary data from the ST's display chip.  Otherwise, he would still get the jail bars and not have any jitter issues.

IE, if he makes the video clock, there cannot be any jitter on the HDMI output.
I have made enough video output on the DECA, now at 1080p, 720p, 480p, 960p, and a few other modes, no jitter at all.  Maybe he isn't driving the HDMI output IC properly?
I never had to use any fancy delays.

Look at the ribbon cables on his PCB where the silkscreen says red/green/blue, it has 4 wires on each ribbon, ie 12 bit digital color.

There are also 3 wires labeled sync and DE.  My guess is just like the Amiga (IE: the sync signals toggle on the rising clock while the digital video out toggle on the falling clock unless it is the ECS DENISE with the 28.63636MHz video out mode where the output timing has all new timing problems), the output timing of the sync VS the RGB color data has a fine but definite skew.  Using my trick of running the FPGA inputs at 8x frequency and sweet-spot selecting the RGB data and sync/de inputs from the ST will allow a perfect clean jitter free experience at each 8x sample position will proved a programmable tunable +/- ~4ns step size delay line.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

There was an error while thanking
Thanking...
Go to full version