shmups.system11.org

I've now ported the code to Cyclone V GX Starter Kit ("C5G"). The board / FPGA is somewhat limited in IO as there's only 2x20 GPIO and HSMC, and some of the existing IO is shared between different HW/connectors. The on-board ADV7513 also has none of its audio inputs connected to FPGA although they are wired to test points which could be easily connected to DExx-vd_isl audio outputs. Most on my testing concentrated around SiI1136 daughtercard which seems to work very well - I was able to get 2560x1440@60Hz output operational (via Si5351C generated clock) with and without pixel repetition, and SiI1136 seemed to work in a stable manner with custom drivers. A major surprise was that ADV7513 also output these modes fine - I'm not sure if I was just locky to get a fast chip, but will try that next on DE10-Nano too.

One disappoiment casted a shadow on otherwise good news, though: performance of the C7 grade Cyclone V (28nm) is not that much better than previous generation Cyclone IV (65nm) according to timing analyzer. On slow condition it only guarantees ~200MHz operation which is quite far from 242MHz target. So it seems 2560x1440@60Hz support will be more or less a silicon lottery, even if SiI1136 is used.

2560x1440@60Hz seems to work on my DE10-Nano too even if it requires going way beyond specs of 3 different chips... Updated repo with C5G and DE10-Nano images with added support for 2560x1440 in generic modes (will generate PLL configs for optimized modes later).

In some quick tests, 2560x1440@60Hz seemed to work just fine with my DE-10 Nano too. An example: YouTube. Will test 480p input / 16:9 later.

My monitors' specs don't allow me to view the 1920x1080@120Hz that's now available via the test pattern. The capture card should just about handle it (297MHz HDMI RX and supports capture of up to 120fps), but jumps around between "no signal" and "unsupported signal". Tried it with three different HDMI cables, same behavior with each, so possibly signal integrity has taken too much of a hit at an earlier point.

Surprising findings indeed - now what to do? Do you think it may be worthwhile to try an OSSC Pro prototype with a C6 grade Cyclone V, introducing more leeway there, hopefully excluding faults? Then again, especially if a HW design that incorporates the SiI1136 instead of the ADV7513 isn't yet ready, it'd be a significant risk in various ways again.

In Jan 2020 you reported that you got visible artifacts with the ADV7513 at 2560x1440 w/ reduced blanking using pixel repitition. Since the OSSC Pro spec so far included a C8 grade Cyclone V, can the latter be ruled out as being the bottleneck instead of the ADV7513?

I didn't either get 1920x1080@120Hz output on ADV7513 while SiI1136 had no issue with 285MHz as expected (clock generator and FPGA ran at half frequency due to pixel repetition trick).

There were indeed artifacts back then while quickly testing the mode with older firmware and prototype. However, I just integrated the latest changes and it seems to run fine on the new board. Upgrading to C7 might make sense as it'd bring FPGA performance on par with these Cyclone V development boards. Going to C6 probably pushes price too much while still not guaranteeing each board will run without issues. The official spec for OSSC Pro thus is likely to remain at 1920x1440@60Hz (185MHz) while 2560x1440@60Hz (242MHz) should be treated as an extra that would still work on most cases. The official spec shouldn't either require going beyond limits of other chips, so replacing ADV7513 (165MHz spec) with SiI1136 (300MHz spec) is preferable and would also enable 1920x1080@120Hz as a bonus. Based on recent tests I'm becoming more confident with SiI1136 so the risk of using that in next prototype is not so massive.

Thank you for your assessment and prospects.

So far I didn't encounter any problems with 2560x1440@60Hz on my DE-10 Nano. 480p input and 16:9 sampling also works well, example: YouTube*
* YT's compression really made that look at lot worse, it's a mere shadow of DE10-vd_isl's output. Intentionally no audio for the reasons I explained earlier.

Displayed value for H frequency with interlaced input and pure LM Deint+L4x mode are also fixed with the Feb 06 revision.

I've recently run some tests with Intel VIP cores such as Deinterlacer II on OSSC Pro. If there are people interested in helping evaluate and/or integrate functionality which is closer to more traditional scalers, I could port the test branch to some board(s) supported by DExx-vd_isl.

I'm a little busy right now, but I'm keen on trying this out - if you port the test branch to DE10-Nano I'll see how I can support.

The branch is now ported to DE10-Nano. Setting up the system is a bit cumbersome as it needs HPS to configure DRAM bridge and bitstream must be programmed separately due to VIP evaluation. The following steps are required in order to get it running:

1. HPS bootloader image needs to be first written (raw mode) to a micro SD card.
2. DE10-Nano is then powered up with the SD card inserted
3. Time-limited bitstream is next programmed to FPGA. USB cable should be left connected and the popup window open
4. HPS must be then reset with the centermost button of the triplet on DE10-Nano PCB
5. Now DRAM interface should be functional, and scaler mode can be selected on Output opt. Scaler settings under scaler menu are then effective.

It's a good idea to make sure a capable PSU is used since I spent hours debugging a stability issue that was caused by a 2A PSU which I've been using with OSSC Pro without issues. The build is still work in progress but has quite a few features. Some notes on scaler functionality:

* 1920x1080p output mode has the largest amount of framelock presets implemented currently
* Framelock status is indicated by 4 user LEDs closest to FPGA. If suitable PLL preset is not found for input/output combination, operation falls back to free-running (i.e. no framelock)
* If framelock is disabled manually and aspect is set to any other than 1:1 source PAR, input mode switching does not interrupt output
* Scaling algorithm should be set to Nearest for 2D content
* Scaler mode does not yet have as low latency as should in framelocked mode. It seems that framebuffer module would need to be custom-designed for that, or perhaps separate VIP writer and reader plus some logic to sync them optimally could be used.
* Many console-specific low-res optimal modes do not work due to a bug in VIP. SNES 512col is one of the few that seems to be OK

Thanks a lot, that's indeed a considerable assortment of features already! In accordance with the steps mentioned, the vip_test branch is up and running on my DE10-Nano, I'll have a closer look on it soon. Thanks as well for the advice with regards to the PSU – a 4A one is already ordered just in case.

I've now had some time to look into it, I tried to touch on a broader range of topics to get an overview for now. Below are the main points from my notes, feel free to take up any aspect.

About the output timings, I've found that 1600x1200 (60Hz) and 1280x1024 (60Hz) neither work with my monitor nor with my capture card (both show 'no signal'), regardless of framelock status. Both accept the 1600x1200 signal that cps2_digiav outputs, and I believe 1280x1024 shouldn't be a problem for both, so I'm drawn towards the thought that there might be something wrong with them, but I didn't further look into it yet. 1920x1200 works with the capture card, with the monitor it so far only cooperated with disabled framelock (while the monitor accepts 1920x1200 from the OSSC Classic at various refresh rates). The remaining timings implemented so far, namely 720x480 (60Hz), 720x576 (50Hz), 1280x720, 1920x1080, 1920x1440 and 2560x1440 all work (the latter two I could only test with the capture card as they surpass the capabilities of the monitor).

On the motion-adaptive deinterlacer, considering it only uses a retrospective framebuffer, introducing only around 2 lines of latency, the result is indeed quite good as far as I can judge. I've compared it to the Framemeister's based on a couple examples: for 3D games, a well configured FM looks smoother and sharper overall, the vip_test branch currently has a slightly more grainy appearance in comparison, but this is mostly caused by differences in the polyphase scaler, not in the deinterlacer. In general, the tendency for deinterlacing artifacts appears to be quite similar based on what I've seen so far, but I haven't yet tried any frame-rendered (as opposed to field-rendered) games that have interlaced output. Perhaps there are some specific games/scenes or stress tests too where a comparison would be worthwhile – if you have any suggestions, feel free to mention them. The only thing that stands out a bit to me currently is that with vip_test, bobbing artifacts can sometimes get quite obvious when navigating menus (the FM masks bobbing artifacts a bit better, see below), so it would be nice if the computed motion could be made to decay a touch faster, but it looks like this aspect is baked into the IP core without the possibility to modify it.

Here are a few videos, the lossy (but still high quality) encodings are also on YT (loses a bit more detail): vip_test, Framemeister
If there's anything notable that I've missed (which I'm almost certain of), please do chime in! With DE10-vd_isl, there's sometimes a bit of shakiness to parts of the picture. This is because of some clock problem my vd_isl board seems to have developed, which I haven't really debugged yet. I'm sorry about that, but you should be able to ignore it for the purposes here.

I'd be able to test the 'High Quality' motion-adaptive deinterlacer that utilizes sobel edge interpolation. Considering there was talk in the OSSC Pro thread about an alternative firmware that could provide it by means of jettisoning other functionality, or an OSSC Pro variant with a beefier FPGA (due to the IP core eating up quite a lot of FPGA resources), a comparison might make sense (I'm certainly curious myself). However, it might be worthwhile to check beforehand to what extent the performance of the 'standard' motion-adaptive deinterlacer could be improved by tuning it via its motion shift and -scale registers (section 15.13.2 in the VIP user guide).

As for the scaler, vip_test's polyphase one appears smoother for 2D games as the FM's emphasis on edges gets very obvious there. vip_test's nearest-neighbor scaler expectedly delivers the most accurate (still) picture, but depending on the ratio between the source and target pixel dimensions it can cause visible shimmering. The FM's more 'aggressive' scaling at times almost reminds me of something in the mould of hqnx and the like, but it causes more ringing (which distorts the original picture information more but also increases perceived sharpness). It helps the FM mask the deinterlacing artifacts a bit better, which applies mostly to the bobbing that affects moving parts of the image. Here are a few lossless screenshots comparing vip_test to the FM: 1, 2, 3, 4, 5, 6, 7

Although it's a matter of taste in the end, the result(s) generated by a Scaler II core can be tweaked by feeding it with custom filter coefficients. Generally speaking, for best results, the coefficients used should be conditioned on the scaling factor, and could be calculated as needed using the soft-CPU. And maybe someday there could be a WYSIWYG editor that lets users customize the look of the scaler and generate an appropriate coefficients file, which could then be put onto an SD card and loaded into the scaler core at runtime using the soft-CPU. On that note, I'm wondering if the NN-Scaler block is needed at all in the long term, since (in theory) polyphase scaling is a generalization of nearest-neighbor scaling, so with the right set of coefficients, a polyphase scaler should be able to assume that task as well.

Further, here's a demonstration of the seamless mode switch feature:
vip_test: please ignore the "Switched to ... at"-times, I simply pressed A at an arbitrary point in time to advance the switching – what you see is what I saw.
Framemeister for comparison: "Switched to ... at"-times are about corrent, the capture card was faster than the monitor.

Finally, these are the bugs I've encountered so far:
* When AR is 1:1 source PAR, and the input mode is switched, there's a chance that the output gets corrupted into noise, see video (what's also noteworthy is that seamless mode switch does work in combination with 1:1 source PAR when framelock is disabled manually)
* When the deinterlacer is in weave mode, and the input mode is switched to 288p, the progressive signal is 'deinterlaced' instead of passed through, see video
* When the signal source is switched off, the last frame remains on screen indefinitely (sometimes corrupted/truncated, depending on settings), maybe because the frame buffer stalled.

I'll perform some more tests with different input signals soon.


Could it be the case that the Frame Buffer II always operates in triple buffering mode currently, even when framelocked? In Platform Designer I seemingly can't specify whether it should be a double or a triple buffer at compile time; the introduction to chapter 16 and section 16.6 in the guide read like the core only implements double buffering when frame dropping and frame repeating are disallowed, but both are allowed currently.

Thanks for testing it out. A few quick comments:

* Do 1600x1200 (60Hz), 1280x1024 (60Hz) and 1920x1200 work in Adaptive LM mode? It should use same framelock/output parameters, so if they work then there's probably just some issue on scaler preset selection which has been added recently
* There should be enough unsed logic on the FPGA to enable HQ motion adaptive deinterlacer, but block RAM is getting tight. Adaptive LM currently uses block RAM instead of external RAM so reducing its line buffers is an easy way to free block RAM if needed.
* HQ motion adaptive deinterlacer might not meet timing at current 125MHz, but it can be reduced if you're just testing 480i/576i content and not using 2560x1440 output. In principle 75MHz should be enough for deinterlacing 1080i, but for some reason at least on Pro I've had to run processing chain at 150MHz (2 pixels parallel) to do that succesfully even though it should need only half of that throughput.
* about progressive signal getting deinterlaced, it might be due to the CVI IP expecting fields in certain way. Now that I remember, constant even field indicator caused some issues so I should make sure progressive video is sent to VIP always with constant odd field.
* I think the largest limitation in Frame Buffer II is that it starts to read buffer only after a frame has been fully written on it. The triple buffer configuration (which is inherently needed for non-framelock) would be just fine if it was possible to start reading of the buffer while it's still written. Exact timing would depend on scaling parameters and would be calculated like in adaptive LM mode.

Thank you for your comments.


I retested this, here is a slightly corrected and more detailed account:

SCL mode of operation, DE10-vd_isl FW 0.43 @ Apr 6 (vip_test branch) with PS2/Fantasy Zone II DX (525-i, 15.73kHz, 59.93Hz):
Monitor | capture card


With the same game at 240p using SCL mode, or using ALM mode with the game at 240p or 480i, everything works as expected.


Thanks for the advice. For now, when compiling the HQMA variant of the deinterlacer core, 60% of total logic space, 66% of total memory bits, 97% of total RAM blocks and 91% of total DSP blocks are utilized according to fitter summary (when compiling with the standard quality MA deinterlacer core, these numbers amount to 41/64/94/51%, respectively). Programming the thus newly generated time-limited .sof, the deinterlacing works, but it looks exactly like the standard quality MA deinterlacing, I think. All I did to that end was changing the deinterlacing algorithm of the core to the HQ variant in Platform Designer, regenerating the qsys output files, and starting a new complete compilation – I might have missed something.


Oh, I see now, yes...
But to hark back to my original point, couldn't it be a cleaner solution to use only double buffering for framelocked mode (since no frame rate conversion is needed), as it makes impossible the asynchronous/nondeterministic behavior that comes with the triple buffering? In fact I'm wondering what the reasons are for using the frame buffer during framelocked operation... couldn't it be bypassed in that case?


Addendum: the bug only seems to happen when framelock is on, and doesn't seem to happen with slower timings like 720x480 (60Hz). I was also able to trigger it by switching from 2560x1440 to 720x480 (60Hz) while AR was set to 1:1 source PAR. A clocking/metastability issue? In that latter scenario with framelock off, seamless mode switch only works ~95% of the time, at least with my equipment. Another thing I encountered is that when AR is at 1:1 source PAR, 1920x1440 and 2560x1440 show an all-black picture even though the signal source is switched on etc, but it's probably just not (yet) implemented.