Tang Nano 1K (Gowin FPGA) VGA output - artefacts, sync problem

[up8051]

Hello,
I built a module that emulates a DMD display from a pinball machine on a VGA monitor.
Device is based on Tang Nano 1K FPGA Module (GOWIN FPGA GW1N-1LV).
VGA ouput:
-16-bit RGB565 color(palette) depth,  (only 4 colors displayed simultaneously)
- high-speed R-2R resistor ladder DAC  (270/536Ohm)
- High-speed buffers (74ALVC245)
- 3 mode 800x600, 1024x768, 1152 X 864.

Everything works fine until I use colors that are different on all 16-bits (14/15-bit with some combinations), for example WHITE (0xFFFF) and BLACK (0x0000).
In such a situation, artifacts and problems with horizontal synchonization begin to appear on the screen.
If I select 0xFFDF and 0x0000 = OK, 0xFFFE and 0x0000 = OK,  0xF7FF  and 0x0000 = artefacts.

Current FPGA I/O pin configuration:   LVTTL33, SlewRate - Slow, Drive =4 mA (lowest possible)
With default configuration LVCMOS33, SlewRate-Fast, Drive=8mA the situation was much worse.

The problem occurs with all VGA resolutions.

I suppose the problem might be related to the power supply (spikes while switching multiple outputs simultaneously).
I powered output buffers  powered from an additional stabilizer - No improvement
Converting 5V power from USB to laboratory power supply -  No improvement
Additional capacitors at the stabilizers (I/O banks)  -  No improvement
Serial termination resistors (100 Ohm) between FPGA and output Buffer(ALVC245) - small improvment (Static image ok, but breaking synchronization with dynamic images).

Artifacts only appear on lines with full bit change.
[ Specified attachment is not available ]

Schematic of Tang Nano Modue:
https://dl.sipeed.com/TANG/Nano/HDK/Tang-NANO-2704(Schematic).pdf
R-2R Dac and driveres analogous to:
https://digilent.com/reference/_media/reference/pmod/pmodvga/pmodvga_sch.pdf

After all attempts, the greatest improvement is when I change the I/O pin configuration -  decrease pin Drive to 4 mA, lowest possible.

What else could I check and improve ?
Modifications on the Tang Nano module are difficult due to the very small SMD components .

Regards
JarekC

[hamster_nz]

My completely hypothetical reason is crosstalk between the colour channels and the sync channels.

Do you have picture of your DAC? Is it just flying wires & through-hole parts on a breadboard? Or are you using the PMOD?

[up8051]

This is probably not the problem here.
Sync signal are buffered by separate chip with separate power supply.
I also changed the cables between the module and the monitor .

I did an experiment and I delayed half the RGB signals by 2.7ns (IODELAY primitive DELAY=90*30ps) and it seems to have helped.
But it is 30% of pixel clock period (108MHz) and discoloration may be visible .

[hamster_nz]

Oh, you have buffers in the middle? What part number?

If you have a spare PCB (everybody gets 5 or 10...) , maybe try building up a board but not populating and then bypassing the buffer footprint.

[up8051]

74ALVC245
All boards that I have are fully populated.

But if I bypass buffers all current for DAC line will be sourced from FPGA I/O pins, which will further increase the load on the bank I/O power supply.

[BrianHG]

The 74ALVC245 need to be 74ALVCT245s powered from 5v and you need to parallel the outputs to something like 4 each to drive the HS & VS.  Also, the series resistor shouldn't be more than 10ohm.

I've seen this before and the problem is connected to this one: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2769264/#msg2769264

One test is using a weller or hot air gun to warm up your 245, see if that effects the picture.

#2, Also, if you are driving a digital display and your sync generator/output code is poorly designed, meaning you are using combinational logic to drive those sync outputs, you will have spikes/glitches in the middle of the picture output with different video mode settings.  Do not do this as it is bad HDL design practice.  If this is the root cause of your problem, fix your code.

All your other IO settings are meaningless for this video application and if they do have an effect, then it does point to your problem being #2.

[asmi]

I think you have SI problems. Take a look at the signal with the scope - but make sure you're going it right. Also measure relative timing of adjacent traces to see if you have any trace length-related issues.
Or just get rid of VGA and use DVI/HDMI - either directly if your FPGA can handle it, or via some sort of HDMI/DVI transmitter (like TFP410).

[up8051]

The 74ALVC245 need to be 74ALVCT245s powered from 5v

There are no such chips as 74ALVCT245.
74ALVC245 can source 24mA per pin, we only need 0.7V (at the DAC output) so why changing to 5V supply.

The problem exists ONLY if switching ALL 16-bit for 1 to 0 (of from 0 to 1) simultaneously.
In other situations screen is stable and clear.
VHDL the code is fully synchronous with pipelining (after place&route there no negative path slack, reported max clock about 115MHz)

I think the problem is the power supply on the TangNano module (power glitches) . However, due to the black solder mask, it is not visible what width the tracks are and what they are guided.

In my opinion, the confirmation of this is that the problem disappears when we reduce the number of switched bits or delay the switching of some of them.

[BrianHG]

The 74ALVC245 need to be 74ALVCT245s powered from 5v

74ALVC245 can source 24mA per pin,

Driving a short circuit to GND or VCC.
Anyways, you seem to have a SSN problem a noisy GND between buffer ICs and FPGA.
A slower / lower current device like the old fashioned 74HC245/AC/HCT/ACT might help, but with a slightly slower output.  They do not ring their power supply as heavily at 5v supply compared to the ALVC series where each device will hit with current spikes way beyond 100ma at the rails if all outputs simultaneously switch.

[asmi]

I think the problem is the power supply on the TangNano module (power glitches) . However, due to the black solder mask, it is not visible what width the tracks are and what they are guided.

In my opinion, the confirmation of this is that the problem disappears when we reduce the number of switched bits or delay the switching of some of them.

This is not how it works. When FPGA switches it's outputs, it pulls a current from decoupling caps, not power supply, because the latter is too far away, and is too slow - no power source can adequately respond to a pulsing load at 100 MHz or avobe. SSN is a crosstalk, so check your routing and ensure all of your data traces have unbroken ground plane underneath which is close enough to provide for adequate impedance, and traces are far enough from each other(2H at least, where H is a distance between traces and a reference plane). If routing it correct, then it could be inadequate decoupling, but typically FPGA devboards are overbuilt when it comes to decoupling because it's not known in advance what kind of design is going to be running on it, so this is the last factor I would look at after I exclude all other possible causes.

[vstrakh]

I'm using Seeedstudio's "5 inch TFT display for tang nano".
I do have 16-bit all-ones to all-zeros switching at 28 MHz pixel clock (800x480 @ 50 Hz) in the onboard FPC connector with no issues whatsoever, so the fpga power should have nothing to do with it.

Sure that display has synchronous interface and some analog noise might be hidden, but it couldn't hide strong effects that can cause the loss of the sync.
The flat cable to the TFT has no ground plane directly between the edge of the cable and up until the lcd controller's power circuitry (like maybe ~2 cm), and I can't tell if there is a ground plane under the traces between fpga and FPC connector. I see all the traces between fpga and FPC on top and bottom sides, but that doesn't tell if pcb is 2 or 4 layers.

[up8051]

I have two additional problems :

1.
I cannot program the embfFlash memory with the programmer  version 1.9.8 build 8004
I always get error:

Info:   Status Code: 0x00015421
Error:   Finished, NOT wakes up
Info:   User Code: 0x00000000

RAM is programmed without problems.

I can program without problem by very old programmer version   "Programmer 2 Beta.100330

The cable settings (2MHz) are the same for both programmers.

2.
Sometimes, when the chip is powered up, the FPGA does not start.
I have to disconnect the power and turn it on again.

Any advice?

Regards
JarekC

[vstrakh]

The cable settings (2MHz) are the same for both programmers.

Set it to 2.5MHz.
Apparently 2MHz is not universally compatible, I had issues with it too.

[up8051]

I tried 2.5MHz but without succes.

[up8051]

I installed newest version 1.9.8.01 build 10027 but the same problem.

[paf]

There are various Tang Nano versions:

• Tang Nano
• Tang Nano 1K
• Tang Nano 4K (with HDMI, and ARM inside the FPGA)
• Tang Nano 9K (with HDMI, TF Card slot, and a bigger FPGA)

Last version news: https://www.cnx-software.com/2022/01/17/tang-nano-9k-fpga-board-can-emulate-picorv32-risc-v-soft-core-with-all-peripherals/

You say you have a Tang Nano 1K, but the link you provided points to the schematic of the Tang Nano.

• Tang Nano Schematic  https://dl.sipeed.com/TANG/Nano/HDK/Tang-NANO-2704(Schematic).pdf
• Tang Nano 1K Schematic https://dl.sipeed.com/fileList/TANG/Nano%201K/2_Schematic/Tang%20nano-6100_Schematic.pdf

While the Tang Nano uses a CH552T as a USB JTAG converter, the Tang Nano 1K, 4K and 9K, all use a BL702 processor.   

In order to program a Tang Nano, you must use the "special version" provided by Sipeed: https://dl.sipeed.com/shareURL/TANG/Nano/IDE
Yes, the programmer software is inside the programmer2.7z archive (use 7zip to decompress).
You a have stupid captcha, that is terrible for those who have some kind of color blindness... 

If you are thinking of using Linux, openFPGAloader (https://github.com/trabucayre/openFPGALoader) does not support the Tang Nano, but works with all the others.
See https://github.com/trabucayre/openFPGALoader/issues/32

[nctnico]

I know this doesn't contribute anything to the conversation, but I'm glad I didn't hop on the train of using Gowin's first-gen Lattice clones.

The FPGA chips work just fine. It is the cheap-ass programming hardware that causes the problem (as usual; just stay clear from cheap development boards). Recently I've used a Gowin FPGA in a design where it is programmed from a microcontroller and that works like a charm.