FPGA VGA Controller for 8-bit computer

[BrianHG]

TFP410 pros

Pros:
Well, easy coding as you just need to add a DDR output buffer to your existing code and it will work saving you 12 IO.
You are pretty sure TI's example output will pretty much pass FCC/EMI regs with a clean PCB layout.
It is likely to work with any DVI display.
Your chosen CycloneV can output 1080p with the device.
Cons:
No audio.
It's an additional IC.  (You still need that DVI/HDMI protection IC and EDID voltage level converter.)

FPGA direct DVI pros:
Save an additional ~4 IOs compared to running the TFP410 in DDR mode bringing the total saved IOs to 16.
(Still need that DVI/HDMI protection IC and EDID voltage level converter as discussed earlier in this thread)
Can support HDMI embedded audio.

FPGA direct DVI cons:
Though you may have no trouble getting a picture on all your DVI/HDMI displays, this is no guarantee how it will operate in the field at large.  However, 480p is so low res and slow, I dont think this will be an issue.
With your CycloneV, though you probably can get 720p to work if you want using a simple DQ port, the spec is slightly outside your FPGA's soft-serializers by around ~15% (I uploaded a code here on another thread which makes a trick 10:1 soft-serializer using the DDR-DQs which seems to full-timing-simulate good up to 742.5MHz for 720p.  It will work fine for 480p).  1024x768 @60hz is within spec.
(I guarantee you wont pass any HDMI/DVI certifications no matter how perfect it works.  )

You will have to ask asmi what voltage you will need to set that IO bank to (I haven't done a direct HDMI myself) and you will no longer have any analog video fallback to rely on.

[asmi]

Like I said before, Xilinx FPGA's output buffers support TMDS standard directly, so no additional analog tricks are required. TMDS standard uses current drivers which need to terminate to +3.3V via 50 Ohm resistor. So in this case Vccio needs to be 3.3V. In my designs I use TPD12S521 chip as ESD protection for main data lines, also as voltage level translator for auxiliary HDMI signals (like Hot Plug Detect, or DDC channel which can be used to discover capabilities of connected display), and finally as overcurrent protection for HDMI power line. Look at the last page of my project's schematic on how to connect it: https://github.com/asmi84/kicad-projects/blob/master/S7_Min/S7_Min.pdf Check documentation for your FPGA to see if it supports TMDS, and what exactly needs to happen to use it.

If FPGA you've chosen does not support TMDS standard directly, you can use "regular" LVDS standard and a voltage translator/retimer like SN75DP149. In this case you will need to use whatever Vccio that your FPGA needs for LVDS standard. Since it's going to be AC-coupled to voltage translator, the DC reference level for LVDS doesn't matter. Also some LVDS drivers require 100 Ohm differential termination resistor, so you've got to watch out for this. Now I want to be clear that I only ever implemented the first approach, so you will need to do your own research if the second approach will be required. The way I typically approach this is by searching for schematics of FPGA devboards that have this implemented, and borrowing the part that interests me.

[asmi]

(I guarantee you wont pass any HDMI/DVI certifications no matter how perfect it works.  )

And you'd be totally wrong

[BrianHG]

(I guarantee you wont pass any HDMI/DVI certifications no matter how perfect it works.  )

And you'd be totally wrong

You do realize just the wrong spacing/location of the HDMI connector compared to other connectors will fail HDMI certification.
You also realize the wrong size and color combination of the HDMI logo printed on your device will fail certification.
You also realize not paying the annual fee leads to failure.
In fact the rule book is so large and complicated, you usually need to pay a third party to evaluate your design before you even attempt to apply for certification.
Even the HDMI connector itself needs to be a certified version and not a knock off for your product to get certified.

Like I said, I guarantee you wont pass any HDMI/DVI certifications no matter how perfect it works.

[james_s]

One of my tasks at a former job was running some of the HDMI certification tests on settop boxes. It was indeed complicated, and the stuff I was doing was just testing the signal, handshaking and content protection. I'm not sure why anyone other than a big company selling a mass produced consumer product would bother.

[asmi]

You do realize just the wrong spacing/location of the HDMI connector compared to other connectors will fail HDMI certification.
You also realize the wrong size and color combination of the HDMI logo printed on your device will fail certification.
You also realize not paying the annual fee leads to failure.
In fact the rule book is so large and complicated, you usually need to pay a third party to evaluate your design before you even attempt to apply for certification.
Even the HDMI connector itself needs to be a certified version and not a knock off for your product to get certified.

There is nothing you listed here that is impossible to satisfy using FPGA. Therefore...

Like I said, I guarantee you wont pass any HDMI/DVI certifications no matter how perfect it works.

You'd be totally wrong.
Oh, and also - DVI and HDMI are different things as far as certification is concerned. So you can't really say DVI/HDMI when we talking about certifications.

Finally, and I think most importantly, none of that matters for hobby designs, which is why I'm puzzled as to why have you even brought this up as an argument against using FPGA for implementation. This is absolutely irrelevant here. As long as the monitor(s) nockieboy will be using will display the video feed properly (and render audio if that's included into the stream, though that will force to use true HDMI standard as opposed to DVI), we should be good to go. And so far I have not encountered a monitor (or TV), which didn't work with my implementation of it, or many others founds online which are substantially similar.

[BrianHG]

You do realize just the wrong spacing/location of the HDMI connector compared to other connectors will fail HDMI certification.
You also realize the wrong size and color combination of the HDMI logo printed on your device will fail certification.
You also realize not paying the annual fee leads to failure.
In fact the rule book is so large and complicated, you usually need to pay a third party to evaluate your design before you even attempt to apply for certification.
Even the HDMI connector itself needs to be a certified version and not a knock off for your product to get certified.

There is nothing you listed here that is impossible to satisfy using FPGA. Therefore...

Like I said, I guarantee you wont pass any HDMI/DVI certifications no matter how perfect it works.

You'd be totally wrong.
Oh, and also - DVI and HDMI are different things as far as certification is concerned. So you can't really say DVI/HDMI when we talking about certifications.

Finally, and I think most importantly, none of that matters for hobby designs, which is why I'm puzzled as to why have you even brought this up as an argument against using FPGA for implementation. This is absolutely irrelevant here.

Didn't you notice the "    " when I first commented...

[asmi]

Didn't you notice the "    " when I first commented...

So let's leave this certification nonsense alone, and talk about the actual implementation. I'm certain that you know Cyclone V much better than I do, so can you tell us if its' output buffers support TMDS standard directly, or we will need to use retimer and LVDS drivers instead?

[asmi]

Also I have a question for nockieboy: how many IO pins your project requires, excluding pins for the memory and video out interface(s)?

[BrianHG]

Didn't you notice the "    " when I first commented...

So let's leave this certification nonsense alone, and talk about the actual implementation. I'm certain that you know Cyclone V much better than I do, so can you tell us if its' output buffers support TMDS standard directly, or we will need to use retimer and LVDS drivers instead?

Directly driven, you can get on an IO bank of 4 clock aligned LDVS transmitters with a matching & jitter performance <+/-250ps.   You would have to make a crap PCB, and poorly filter the VCC_PLL swinging the temperature between coldest and hottest to achieve that poor performance worst case scenario.  @250 megabit for 640x480, or even double that, you will have a huge clean data EYE which any monitor or TV should be able to display directly driven from the FPGA.  You still need the ESD protection IC.  As for the proper termination, I would consult existing third party dev board which drive HDMI/DP directly to see what they use.

In the past, I've fed DVI/HDMI with spread spectrum clocks and it still works fine except for some old TVs back around 2005 which at the time were not engineered to support spread-spectrum HDMI.  Today, I doubt you could find a monitor which the Cyclone could not drive all on it's own to 480p @ 270MHz.

I've attached the required EYE (blue eye) for 720p, 742.5MHZ and it looks like the Cyclone can just make it there as well, 480p will be easy.

(source : R&S HDMI measurements, page 11, 742.5MHz 720p graph )

[nockieboy]

Also I have a question for nockieboy: how many IO pins your project requires, excluding pins for the memory and video out interface(s)?

Okay, let's see:

Z80 data bus - 8 + 2 IOs
Z80 addr bus - 24 + 2 IOs
Z80 ctrl bus   - 8 IOs

PS2 interface - 4 IOs
uSD interface - 6 IOs
Debug port    - 2 IOs
Serial port     - 4 IOs
Audio DAC     - 3 IOs
---------------------------
TOTAL:           63 IOs
---------------------------

That doesn't include the 24-bit RGB video output and 3 control signals (HS, VS and DE).  It also doesn't include any additional IOs I've used for LEDs (3, currently).

Directly driven, you can get on an IO bank of 4 clock aligned LDVS transmitters with a matching & jitter performance <+/-250ps.   You would have to make a crap PCB, and poorly filter the VCC_PLL swinging the temperature between coldest and hottest to achieve that poor performance worst case scenario.  @250 megabit for 640x480, or even double that, you will have a huge clean data EYE which any monitor or TV should be able to display directly driven from the FPGA.  You still need the ESD protection IC.  As for the proper termination, I would consult existing third party dev board which drive HDMI/DP directly to see what they use.

In the past, I've fed DVI/HDMI with spread spectrum clocks and it still works fine except for some old TVs back around 2005 which at the time were not engineered to support spread-spectrum HDMI.  Today, I doubt you could find a monitor which the Cyclone could not drive all on it's own to 480p @ 270MHz.

Okay, well I'm given confidence by projects like this one, where a Cyclone II is used to generate a 480p image via directly-driven HDMI/DVI.

TFP410 pros

Pros:
Well, easy coding as you just need to add a DDR output buffer to your existing code and it will work saving you 12 IO.
You are pretty sure TI's example output will pretty much pass FCC/EMI regs with a clean PCB layout.
It is likely to work with any DVI display.
Your chosen CycloneV can output 1080p with the device.
Cons:
No audio.
It's an additional IC.  (You still need that DVI/HDMI protection IC and EDID voltage level converter.)

FPGA direct DVI pros:
Save an additional ~4 IOs compared to running the TFP410 in DDR mode bringing the total saved IOs to 16.
(Still need that DVI/HDMI protection IC and EDID voltage level converter as discussed earlier in this thread)
Can support HDMI embedded audio.

Additional FPGA direct pros - easier routing and saving PCB space with no TFP410 or ADV7125 (and associated VGA socket) required.

Also, currently I've got the TFP410 set up for single-edge latching, so a full 24 IOs are required for the RGB bus, not 12.  My hand was forced here as I wanted to keep the VGA output and, as far as I can tell, the ADV7125 only latches data on the rising edge - it doesn't do DDR.

I guess I should just drop the VGA altogether, whether or not I go with the TFP410.  I'm just nervous as I haven't tested the DVI output method practically, whereas with VGA I had it set up and working on my dev board (albeit with a resistor-ladder rather than an ADV7125).

FPGA direct DVI cons:
Though you may have no trouble getting a picture on all your DVI/HDMI displays, this is no guarantee how it will operate in the field at large.  However, 480p is so low res and slow, I dont think this will be an issue.
With your CycloneV, though you probably can get 720p to work if you want using a simple DQ port, the spec is slightly outside your FPGA's soft-serializers by around ~15% (I uploaded a code here on another thread which makes a trick 10:1 soft-serializer using the DDR-DQs which seems to full-timing-simulate good up to 742.5MHz for 720p.  It will work fine for 480p).  1024x768 @60hz is within spec.

So, no real cons at all then?

720p would be useful - can always upscale the 640x480 image to 720p - and providing a proper 720p image would be more compatible with the displays' native resolutions.

[BrianHG]

Okay, well I'm given confidence by projects like this one, where a Cyclone II is used to generate a 480p image via directly-driven HDMI/DVI.

Just copy his PCB and we will double verify your IO selection and placement to ensure you also get the chance to achieve 720p with at worst having increasing the VCCint from 1.1v to ~1.15v/1.2v if it didn't already do the 720p out of the box.

From experience routing CycloneIII with tests on an older true 5gs/sec/channel scope with amplified 1.5GHz jfet low capacitance probes, your output jitter and EYE is well under the +/-250ps, much closer to the +/-150ps in practice and the PLL is designed to go up past 700MHz.

As for the DDR2/3, your cyclone is guaranteed to do 250MHz/500mtps by Intel.  I'm not sure about the lower frequency limit of DDR3, but if it can do 250MHz, then you can use it.  DDR2s are still readily available with 4 banks allowing you continuous streaming memory access providing at least 3x the speed of a Hyperbus ram when comparing with an 8bit DDR2/3.  Since your core internally is 250MHz 16bit, this means the ram would also run internally in 1:1 mode in clock and depth.  Sparing up a second 8bit IO bank for a 16bit DDR2/3 will give you 8x the speed of the current Hyperbus ram.  Though, you core pixel writer and other newer functions will probably never saturate that speed.

[asmi]

Just copy his PCB

Do you have a link to it? I couldn't find anything.

Overall I'm surprised that it's incredibly hard to find any schematics for direct HDMI out for Antel FPGAs, while there are tons of implementations using Xilinx devices. I spent about half an hour trying to find any schematic in the Google, but totally failed.

Maybe it's a good time to discuss moving to Artix/Spartan-7? Artix-7 in 1 mm BGA256 package has 170 user IO balls, so it should be enough for everything we've got + direct HDMI out up to 1080p@60 + x16 DDR2/3 memory module running at 400 MHz. This package also has a wide range of pin-compatible densities from 15K to 100K, so you can easily scale device up or down as required without any PCB changes aside from possibly minor changes in PDS. The top level device (A100T with 100K) requires a beefy DC-DC converter for Vccint rail as it can consume up to about 6 Amps@1.0 V, and it will need at least some glued-on or clipped-on heatsink. Smaller density devices can get away without heatsink.

[nockieboy]

Just copy his PCB and we will double verify your IO selection and placement to ensure you also get the chance to achieve 720p with at worst having increasing the VCCint from 1.1v to ~1.15v/1.2v if it didn't already do the 720p out of the box.

From experience routing CycloneIII with tests on an older true 5gs/sec/channel scope with amplified 1.5GHz jfet low capacitance probes, your output jitter and EYE is well under the +/-250ps, much closer to the +/-150ps in practice and the PLL is designed to go up past 700MHz.

*deep breath*

Okay, I'm going to pull the trigger and remove the TFP410 and VGA gubbins from the board.  We're going full-throttle on a DVI-D-compatible 480p (maybe 720p later) video output by driving the HDMI connector directly from the FPGA.

I'll keep the 3.3VA supply at the bottom-right corner of the board to supply the PCM5101.

As for the DDR2/3, your cyclone is guaranteed to do 250MHz/500mtps by Intel.  I'm not sure about the lower frequency limit of DDR3, but if it can do 250MHz, then you can use it.  DDR2s are still readily available with 4 banks allowing you continuous streaming memory access providing at least 3x the speed of a Hyperbus ram when comparing with an 8bit DDR2/3.  Since your core internally is 250MHz 16bit, this means the ram would also run internally in 1:1 mode in clock and depth.  Sparing up a second 8bit IO bank for a 16bit DDR2/3 will give you 8x the speed of the current Hyperbus ram.  Though, you core pixel writer and other newer functions will probably never saturate that speed.

Let me get this straight - the existing HyperRam setup requires two BGA chips and will require some nifty HDL-ing to interface with it and push it up over its 200MHz rated limit.  Even then, it's only fast enough to give full-speed, no latency access to one MAGGIE?

However, if I strip that out and replace with a DDR2 or 3 chip, I'll only need one chip but a load more IOs (so I'll be setting two banks to 1.8V instead of that faff trying to find just the one for the HyperRam) - I could potentially use the entire bottom-right corner/quadrant of the FPGA for the DDR.  But all that aside, what benefit will the DDR2/3 bring?  Would it be a little closer to the internal RAM in terms of performance?  i.e. could more than 1 MAGGIE access it?  I'm just wondering if I could use it as the frame buffer....  that would unlock some serious resolutions and colour combos....

Just copy his PCB

Do you have a link to it? I couldn't find anything.

As far as I can tell from watching this , he's using a bog-standard Cyclone EP2C5T144 board, like this one, and incidentally, exactly like one I've got sitting in a tin on my shelf that I was using when I started this thread...  Doesn't appear to be any fancy wiring, he's just connected the IOs to the HDMI connector, although I can't see if there's any discrete components on the connector PCB in the video. Jump to 1min50secs to see.

Overall I'm surprised that it's incredibly hard to find any schematics for direct HDMI out for Antel FPGAs, while there are tons of implementations using Xilinx devices. I spent about half an hour trying to find any schematic in the Google, but totally failed.

Maybe it's a good time to discuss moving to Artix/Spartan-7?

Well, I guess this is the elephant in the room now.  Am I using the right tool for the job?  Thing is, whilst I'd likely be as clueless with a Xilinx as I am with an Altera FPGA, I'm quite comfortable and familiar with the Cyclone dev chain.  That's not to say that Xilinx's 7-series isn't appealing - they seem to have more RAM than the equivalent Cyclones and that's a big factor in our current designs.  I do actually have a Spartan-6 dev board and programmer, still in their static bags, sitting around somewhere.

The biggest thing though, is that whether or not he'd like to admit it, BrianHG is critical to the success or failure of this project.  He's the only one who knows how to finish what we've started on the HDL-side (if nothing else, I have learned a lot about what I don't know about HDL so far), so I'll always be guided by his preference here.  And I'm sure that if we did move over to Xilinx, there'd be a lot of head-scratching as the HDL wouldn't just lay back and allow us to port it without causing issues.

Artix-7 in 1 mm BGA256 package has 170 user IO balls, so it should be enough for everything we've got + direct HDMI out up to 1080p@60 + x16 DDR2/3 memory module running at 400 MHz. This package also has a wide range of pin-compatible densities from 15K to 100K, so you can easily scale device up or down as required without any PCB changes aside from possibly minor changes in PDS. The top level device (A100T with 100K) requires a beefy DC-DC converter for Vccint rail as it can consume up to about 6 Amps@1.0 V, and it will need at least some glued-on or clipped-on heatsink. Smaller density devices can get away without heatsink.

At the end of the day, this GPU card sits on a stack of cards that all draw power from either a USB serial connection to my PC, or a DC jack connected to a 7805 regulator.  Yep.  Exactly.  I've been putting off redesigning the power card for a while, as the current GPU (Cyclone IV) works just fine on the USB (though I've just checked and it only draws 0.08A!).  I'm hoping that the Cyclone V will work without MAJOR issues - I might have to run it from the jack rather than the USB supply like I do now with the Cyclone IV, but then again it should actually be more power efficient than the IV.  I suspect that a Xilinx (certainly some of the ones you've described) may cause power issues.

[BrianHG]

Just copy his PCB

Maybe it's a good time to discuss moving to Artix/Spartan-7? Artix-7 in 1 mm BGA256 package has 170 user IO balls, so it should be enough for everything we've got + direct HDMI out up to 1080p@60 + x16 DDR2/3 memory module running at 400 MHz. This package also has a wide range of pin-compatible densities from 15K to 100K, so you can easily scale device up or down as required without any PCB changes aside from possibly minor changes in PDS. The top level device (A100T with 100K) requires a beefy DC-DC converter for Vccint rail as it can consume up to about 6 Amps@1.0 V, and it will need at least some glued-on or clipped-on heatsink. Smaller density devices can get away without heatsink.

LCSC only has stock of the ' XC7A35T-2FTG256C ' @ 16$, 26kle 1.8mbit ram.  + Learning curve.
The DDR3 will run max in mode 2:1 @ 350Mhz with 700mtps  compared to CycloneV 2:1 303MHz, 606mtps.
The DDR3 can also run in mode 4:1 @ 200Mhz with 800mtps.
(Table 16 in Xilinx da181_Artix_7_datasheet.)
It's LVDS can guarantee 720P performance.

Our core clock is 250MHz/125MHz for VGA, or it goes up to 270MHz/135MHz for broadcast 480p.

[nockieboy]

LCSC only has stock of the ' XC7A35T-2FTG256C ' @ 16$, 26kle 1.8mbit ram.  + Learning curve.
The DDR3 will run max in mode 2:1 @ 350Mhz with 700mtps  compared to CycloneV 2:1 303MHz, 606mtps.
The DDR3 can also run in mode 4:1 @ 200Mhz with 800mtps.
(Table 16 in Xilinx da181_Artix_7_datasheet.)
It's LVDS can guarantee 720P performance.

Our core clock is 250MHz/125MHz for VGA, or it goes up to 270MHz/135MHz for broadcast 480p.

The Cyclone IV can't handle 135MHz without some (serious, I'm guessing) work on the HDL.  I wonder if the Cyclone V will be any better?

Anyway, LCSC only have stock of the A2 variant of the Cyclone V, so product choice is restricted either way I guess.  The Xilinx part is $3 cheaper (exchange rate approximate). 

Hmm... around 200KB of RAM though.  The Cyclone V A4 has about 300KB?

[mariush]

Maybe also have a look at the recently released Efinix chips?

For example the T85 series : https://www.efinixinc.com/docs/trion85-ds-v1.2.pdf

BGA324 : https://www.digikey.com/en/products/detail/efinix-inc/T85F324C3/11591357

Has built in ddr3 controller block, supports ddr3 / ddr3l up to 1066 mhz x16 (the 484 and  576 support x16 and x32) ,  519040 bytes of memory ... but the bga324 is in 0.65 pitch which may be small  (bga484 is in 0.8mm)

[asmi]

At the end of the day, this GPU card sits on a stack of cards that all draw power from either a USB serial connection to my PC, or a DC jack connected to a 7805 regulator.  Yep.  Exactly.  I've been putting off redesigning the power card for a while, as the current GPU (Cyclone IV) works just fine on the USB (though I've just checked and it only draws 0.08A!).  I'm hoping that the Cyclone V will work without MAJOR issues - I might have to run it from the jack rather than the USB supply like I do now with the Cyclone IV, but then again it should actually be more power efficient than the IV.  I suspect that a Xilinx (certainly some of the ones you've described) may cause power issues.

I said "up to" for a reason. That is almost absolute maximum it can consume if you reach near 100% utilization of it's resources. Given that currently your design fits into like 1/4 of resources A100T has, you won't get anywhere near that consumption. Infact, this device is going to be a massive overkill for this project as it is, but it's nice to have options for future growth. As it is, even A35T is going to be more than enough. And that device is available on Digikey and Mouser for about 35-40$, so you don't run the risk of it suddenly disappearing from stock (which is what tends to happen quite a bit on LCSC).
That said, the very same TLV62130 that you use on a current board can be used to step down any power brick voltage (up to 17 V I think), which I'm sure you have quite a bit of, like we all do, down to 5 V, and it can output up to 3 Amps and so 15 W of power, which is going to be more than enough for any of your boards even if you use A100T FPGA and somehow manage to fill it to the gills, all that while maintaining fairly good efficiency and so not getting too hot. I learnt very early that using USB for power is not the greatest idea, because the voltage on it can sag quite a bit during current bursts - even simple microSD card can consume up to 300 mA in certain situations. I actually had all kind of weird issues which were traced to insufficient power specifically with microSD cards.

[asmi]

Our core clock is 250MHz/125MHz for VGA, or it goes up to 270MHz/135MHz for broadcast 480p.

I've been wondering for a while now if it would be possible to duplicate (with perhaps some modifications, hopefully minor) your processing pipeline and run two (or maybe even more) of them in parallel instead of raising the frequency? So essentially is it possible to go wide instead of going fast, and double effective throughput this way? FPGA resources are relatively cheap nowadays, and running at lower frequencies makes closing timing much easier, it also allows you to get away with more things that you can while running at higher frequencies.

[asmi]

Maybe also have a look at the recently released Efinix chips?

I don't think go to what effectively is a noname vendor in this field is a great idea. At least with Xilinx you get the benefit of a ton of information publicly available for just about anything related to these devices, excellent documentation provided by the vendor, lots of helpful guides, tutorials, open source and open HW projects, etc. And the vendor itself is quite hobbyist-friendly with a lot of free IPs and access to quite wide range of their devices in free version of tools, and the tools themselves are full-featured, not some cut-down versions of a cut-down versions of products, which is what some other FPGA vendors are doing, I guess in the hope that if they cripple and annoy you enough, you might just pull the trigger and buy a commercial license.

BGA324 : https://www.digikey.com/en/products/detail/efinix-inc/T85F324C3/11591357

324 package? That's at least 6 layer PCB for sure. No way you can get away with 4 layers.

[asmi]

Anyway, LCSC only have stock of the A2 variant of the Cyclone V, so product choice is restricted either way I guess.  The Xilinx part is $3 cheaper (exchange rate approximate). 

Interesting - even Digikey only has two options for CV in 256 ball package - A2 and A4. While it's got entire family of Artix-7 in the same package from smallest A15 all the way up to A100, and most densities are available in multiple speed grades and temperature ratings. Well I guess that shows which devices are more popular

[BrianHG]

Maybe also have a look at the recently released Efinix chips?

For example the T85 series : https://www.efinixinc.com/docs/trion85-ds-v1.2.pdf

BGA324 : https://www.digikey.com/en/products/detail/efinix-inc/T85F324C3/11591357

Has built in ddr3 controller block, supports ddr3 / ddr3l up to 1066 mhz x16 (the 484 and  576 support x16 and x32) ,  519040 bytes of memory ... but the bga324 is in 0.65 pitch which may be small  (bga484 is in 0.8mm)

This one is really interesting @20$:
https://www.digikey.com/en/products/detail/efinix-inc/T85F484C3/11591358
However, I never seen their tools or dev boards and Digikey seems to have exclusive stock.

[nockieboy]

Oh. My. Gawd. 

Xilinx isn't selling itself to me at the moment.  I've just spent the last hour trying to get the damn ISE software to install and load so that I might have a play with my Spartan-6 over the weekend.  I'll be damned if I'm uninstalling my Oracle VM software just so that the ISE can run its own (older version) VM environment.  WTH is that for, anyway?  Upshot is that I'm currently downloading an older version of the ISE in the hope it's the non-VM version.  Then I've got to apply a hack to get it to work in Windows 10.

Be as critical as you want about Antel, but Quartus just works.

[BrianHG]

Our core clock is 250MHz/125MHz for VGA, or it goes up to 270MHz/135MHz for broadcast 480p.

I've been wondering for a while now if it would be possible to duplicate (with perhaps some modifications, hopefully minor) your processing pipeline and run two (or maybe even more) of them in parallel instead of raising the frequency? So essentially is it possible to go wide instead of going fast, and double effective throughput this way? FPGA resources are relatively cheap nowadays, and running at lower frequencies makes closing timing much easier, it also allows you to get away with more things that you can while running at higher frequencies.

It is a pipeline right now at 10 dual channels = 20 channels, 15 for 15 layers and 1 fat channel for Z80 and GPU geometry.

Pixel clock = 25Mhz * 10 dual channels = 250MHz/125MHz core.
You can easily configure the pipeline to for example 8 dual channels = 16 channels, 12 for 12 layers and 1 fat channel for Z80 and GPU geometry.
In this configuration, 25MHz pixel = 25MHz * 8 dual channels = 200MHz/100MHz core.
You can go in the other direction as well, but it is not worth all the layers unless you change the layers to 12 dual channels, 1 for 12 layers and 2 fat channels to either make a double speed geometry unit (modifying just the pixel writer module would be easiest), or run 2 parallel geometry units.  (IE 300MHz/150MHz core)

You can also cut the layers in half and double the pixel clock output.  With a few calculations after seeing the FPGA's fabric's max performance, an optimum configuration may be chosen for 720p if interested.  Also, the DDR port may have a dedicated 1 or 2 layer channels in addition to the ones listed above which are more like full screen sprites and hardware accelerated tile/font/sprite/overlay screens memory.

Though it is easy enough to add 2 geometry units, this would only offer acceleration with solid polygons and there is no mechanism in place to split the work between them as painting some shapes may require 1 being painted on top of another.

[BrianHG]

This means with the current setup, Nockieboy can have 720P with the current core with 5 layers instead of 15 layers, ie 3x25MHz = 75MHz pixel clock.  The HeyperRam/DDR would add another 1/2 layers on top of the 5 since it will have a dedicated pipe to draw the background screen.

The bridge between the 2 will be the GPU geometry and blitter core.