Sidequest: VGA scan doubler

[Smonson]

OK so I got this version 0.7 board stuck together now, in exciting purple this time.

IMG20240311154854.jpg

It basically works when I first power it up, but then gets more glitchy over time as it warms up.

That is exactly the same as the previous board, which I assumed was because it had marginal timing. But this one using a much faster chip isn't marginal - the timing analysis says it should be good to go up to at least 120MHz. So I dunno what the reason is. It could be the open-source software. I tried to get the official Lattice software (iCEcube2) to run, but it's pure garbage and just segfaults which is no help.

Checked the signals on my scope and they are solid going into the chip.

The actual scandoubler part works great. It falls apart when it comes to keeping track of wlthe scanline number, and how many pixels are on each line. Those numbers seem to get noisy or they don't work at all.

So this is kind of in that twilight zone now of me just "trying stuff" but not having a solid plan.

Ignore the blue line in the videos - that's just for debugging the line number.

In colour, probably flicking because of wrong BLANK generation.


In mono, not generating any BLANK and basically stable but you can see that line jumping around indicating that it's lost track of where the frame started.


Very annoying.

[troed]

The actual scandoubler part works great. It falls apart when it comes to keeping track of wlthe scanline number, and how many pixels are on each line. Those numbers seem to get noisy or they don't work at all.

Very annoying.

This makes no sense. I assume you're resetting the lines every VBL? If so there's no long running counter that could be affected by "warm up over time".

Are all system clocks generated as before?

[Smonson]

I did get the counter to begin remaining stable, just by randomly changing things until it worked. But only at the expense of disabling the boot-up logo.

I assume you're resetting the lines every VBL? If so there's no long running counter that could be affected by "warm up over time".

I count the lines since VSYNC because I need to re-add the blanking period at the end of each frame. Otherwise all the state could be confined to one scanline. The clocks are the same, the only thing I've changed since switching to the ice40 is the addition of the logo.

I'm certain it's the software that I've been using, now. That is, the open-source project icestorm as it exists in Ubuntu 23.10.

I reached a point where the slightest trivial change of the source would cause the whole thing to fail, then another tiny change would bring the functionality back. It seems like a bug.

For an example, in this first case, it's just an assignment to the output lines in verilog of either the 60Hz or 50Hz scanbuffer output. This code works and displays a perfect screen:

Code: Select all

	wire [8:0] video_pixels = sixty_flag ? sixty_rgb_out : fifty_rgb_out;
	assign rgb_out = video_pixels;

Secondly, the only change in the program is the last line here where I begin to show the logo over part of the screen. With this change, the logo displays while show_logo is true. But unexpectedly the entire rest of the screen turns black.

Code: Select all

	wire [8:0] video_pixels = sixty_flag ? sixty_rgb_out : fifty_rgb_out;
	assign rgb_out = show_logo ? logo_pixels : video_pixels;

Then leaving that bit alone, and changing something somewhere else and the picture comes back. I'm using another program called iverilog to simulate the code and confirm that it is working in theory through a test bench.

Also the fact that I never had these types of issues with the Altera FPGA parts.

I need to get Lattice's official software running in Windows and see if it makes a difference. I expect it will.

At least I got it working (by random poking) without the logo and quickly saved a copy of the ROM file so I can at least use the machine myself!

[stephen_usher]

So, is the unit actually running any "code" internally, such as a state machine?

I say this as this looks awfully like a memory corruption error due to off-by-one or similar array bounds issues, especially if minor changes of the code breaks things. This is a classic writing to the wrong address symptoms.

[Smonson]

So, is the unit actually running any "code" internally, such as a state machine?

I say this as this looks awfully like a memory corruption error due to off-by-one or similar array bounds issues, especially if minor changes of the code breaks things. This is a classic writing to the wrong address symptoms.

It's not running code exactly in that sort of sense. Because this is an FPGA, the behaviour of it is the same as a pile of logic gates. It also has RAMs but they are hooked up directly to the circuit rather than being used for holding variables. And for this application, writing any wrong data into those RAMs wouldn't cause glitchy behaviour, it would appear as screen corruption.

In another sense, I agree with you, because the logic gates in an FPGA are implemented with RAM (look-up tables), and I do suspect that the compiler is causing something to be hooked up wrong in some way.

[exxos]

I do suspect that the compiler is causing something to be hooked up wrong in some way.

There isn't some stupid "optimisation" settings for the compiler is there ? I've had compilers make "innocent" changes and screw things up before. I have to compile with no optimsations with my SEC booster for example. But 99% of the time, it's fine to optimise.

[Smonson]

There isn't some stupid "optimisation" settings for the compiler is there ? I've had compilers make "innocent" changes and screw things up before. I have to compile with no optimsations with my SEC booster for example. But 99% of the time, it's fine to optimise.

There are thousands of options, but they're all super technical and beyond my understanding. I left them on the defaults!

[ijor]

I'm certain it's the software that I've been using, now. That is, the open-source project icestorm as it exists in Ubuntu 23.10.

I reached a point where the slightest trivial change of the source would cause the whole thing to fail, then another tiny change would bring the functionality back. It seems like a bug.
...
I need to get Lattice's official software running in Windows and see if it makes a difference. I expect it will.

It is impossible to work with tools that you don't trust. Might be the compiler or might be not, but you have to use known good, reliable, tools.

I understand from what you are saying that you usually develop on Linux and compiling on Windows might be a bit problematic for you. Use a VM to run Windows (virtualized on Linux) in the worst case.

[mfro]

...
Secondly, the only change in the program is the last line here where I begin to show the logo over part of the screen. With this change, the logo displays while show_logo is true. But unexpectedly the entire rest of the screen turns black.

Code: Select all

	wire [8:0] video_pixels = sixty_flag ? sixty_rgb_out : fifty_rgb_out;
	assign rgb_out = show_logo ? logo_pixels : video_pixels;

Then leaving that bit alone, and changing something somewhere else and the picture comes back. I'm using another program called iverilog to simulate the code and confirm that it is working in theory through a test bench.
...

Might indeed be a bug, but not necessarily so. It might as well be just a timing issue.

At least you're adding a mux into a (probably already timing critical) combinational circuit that might cause that bit of delay that makes the signal missing the next register (probably an I/O cell?) in time (Lattice chips aren't especially known for outstanding performance).

Does that toolchain come with a timing analyzer?

[Smonson]

It is impossible to work with tools that you don't trust. Might be the compiler or might be not, but you have to use known good, reliable, tools.

I understand from what you are saying that you usually develop on Linux and compiling on Windows might be a bit problematic for you. Use a VM to run Windows (virtualized on Linux) in the worst case.

Since the Lattice software is all self-contained, I'm sure it'll be fine to run it on Windows, just nothing else in my GNU-based toolbhain will work. So I have the pain of copying the source code on there, compiling it, then rebooting back into Linux to program the chip. Good for confirming whether it could fix the problem but not good for actual working, although if I use 2 laptops simultaneously I could probably live with it.