Possibility to generate full-spec 1080p?

[c0pperdragon]

As far as I know, the biggest weakness of the OSSC is its off-spec output timing for various screen modes and the ensuing incompatibility with many receivers.
Wouldn't it be possible to implement at least a conversion from 288p to 1080p (50Hz)? Such a signal could be following the well-specified HDTV mode for this resolution. With that, basically all HDTVs and capturing devices should work.

Of course this would then require more than just a one-by-one line conversion, but a bit of buffering to match up the input and output line frequencies. By doing the calcuations, it turns out that you need a buffer holding a little less than 30 lines worth of input data. 30 lines with 720 pixels and 24 bit color resolution need ‭518400 bit of data. ‬The datasheet for your FPGA lists ‭‭608256‬ bit of on-chip RAM.

I don't know the rest of your design, but do you actually need more than 10KByte for the remaining circuit? If the program code for the soft core processor is too big, you could use a portiona of the LUTs as LUM-ROM. In total, the resources of the FPGA seem to be just enough to pull this off.

Are there any reasons, why this is absolutely impossible?

[marqs85]

There are 2 reasons which prevent doing that on the current HW:

1. Lack of line buffer space (as you mentioned)
2. Inability to generate exact pixel clock (with CEA standard H/V timings) required for staying framelocked to input

Both of these limitations are tacked by the upcoming Pro model. The prototype already is able to do such conversion with 40 line buffers being reserved for adaptive line multiplication modes. That leaves input refresh rate as the only potential incompatibility with displays, but a "scaler mode" is also planned which can operate without framelock if required.

[c0pperdragon]

With a bigger FPGA that has at least 2 cascadeable PLLs you should be able to convert from pretty any input pixel frequency (which is provided by the TV input stage, I assume) to the necessary HDMI output pixel frequency.
This works of course only if the PLLs can be reconfigured on the fly as needed - but this is even possible on the "small" MAX 10 FPGA which I use for my projects.
As long as the PLLs run in lock-step you can keep the output image in perfect sync to the input (with basically no lag beyond the 30 lines towards the bottom end of the image).

[marqs85]

I doubt you can implement the required ratio for your example ((2640*1125)/(312*1872)) by cascading MAX10 PLLs. If they are anything like Cyclone IV PLLs, they are also painful to configure dynamically. That's why I'm using a dedicated PLL chip for the Pro.

[c0pperdragon]

These prime factor calculations are really pretty awful, but for the given example I could at least do it with 3 PPLs: (11/13) * (25/13) * (25/8)
And yes, computing the necessary PLL parameter bit-stream is indeed a very, very advanced matter. So far I only use two different settings (both pre-computed by the quartus IDE) with I alternatively load into the PLL. But in theory on-the-fly generation should be possible.
Anyway 3 PLLs are quite much for this feature. But as your upcomming Pro version already has one external (and more programmer-friendly) PLL already, this whole scheme seems more and more possible.

[marqs85]

For Cyclone IV I had to generate a custom pll_reconfig peripheral where soft-CPU can write PLL configuration and which subsequently reconfigures the PLL using scan chain. The configuration data structure was not documented so I had to use presets which were generated by the hard way. Anyway, no need to do such on the Pro since Si5351C is much more flexible and nicer to use.

[c0pperdragon]

So, I guess I really need to get the Pro version then.
Do you plan to sell a bare-bones version (only PCBs and hard to get parts)?

[marqs85]

You can consider this addon board as the DIY version. The project files are available here.

[Sirethief2525]

Is the add on board for the standard ossc? Or something else?

…

On Wed, Oct 28, 2020, 14:48 marqs85 ***@***.***> wrote: Closed #58 <#58>. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#58 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDZHUZP4XN7UYAFICGAF63SNBYPBANCNFSM4NYPUXLQ> .

[marqs85]

Add-on for FPGA dev boards, DE10-Nano and DE2-115 currently supported.