FPGA VGA Controller for 8-bit computer

[nockieboy]

I actually use it on my FPGA board:

I can assure you that it really works just fine Moreover, it also provides a current limiter for HDMI port's power line, also the destination voltage (on the FPGA side) for DDC/HPD/CEC lines doesn't have to be 3.3 V - it can be any voltage from 1 to 3.3 V.

Very impressive, asmi  - how did you make that board?  I presume it was done in a reflow oven?  Is it 4-layer?  Done in KiCAD or something professional?



As for the TPD12S521, will I need this with a TFP410?

[BrianHG]

I actually use it on my FPGA board:

I can assure you that it really works just fine Moreover, it also provides a current limiter for HDMI port's power line, also the destination voltage (on the FPGA side) for DDC/HPD/CEC lines doesn't have to be 3.3 V - it can be any voltage from 1 to 3.3 V.

Very impressive, asmi  - how did you make that board?  I presume it was done in a reflow oven?  Is it 4-layer?  Done in KiCAD or something professional?



As for the TPD12S521, will I need this with a TFP410?

Your link is for the wrong datasheet.  Get the right one from TIs website and see what it says...

[BrianHG]

 Use this NXP ic if you want HDMI with digital audio support:
https://www.digikey.com/product-detail/en/nxp-usa-inc/TDA19988BHN-C1551/568-12058-ND/2780351

[nockieboy]

Your link is for the wrong datasheet.  Get the right one from TIs website and see what it says...

Darn it, pasted the wrong link, sorry. 

[jhpadjustable]

Use this NXP ic if you want HDMI with digital audio support:
https://www.digikey.com/product-detail/en/nxp-usa-inc/TDA19988BHN-C1551/568-12058-ND/2780351

Note, external HDMI transmitters are almost useless to the hobbyist due to NDA and licensing restrictions, unless you are fortunate enough to find a leak with enough information to get started.

[BrianHG]

Use this NXP ic if you want HDMI with digital audio support:
https://www.digikey.com/product-detail/en/nxp-usa-inc/TDA19988BHN-C1551/568-12058-ND/2780351

Note, external HDMI transmitters are almost useless to the hobbyist due to NDA and licensing restrictions, unless you are fortunate enough to find a leak with enough information to get started.

The chip I listed which is freely available without NDA as well as the data sheet doesn't have HDCP, the true roadblock for hobbyists.  HDMI transmitters with and without audio is allowed.  The hobbyist just isn't allowed to use HDMI's logo or claim authenticated HDMI output in their documentation.

I've never had problems with getting such ICs unless HDCP was built in, however, I've been using Analog Devices HDMI transmitters.  NXP may require a license.

[asmi]

Very impressive, asmi  - how did you make that board?  I presume it was done in a reflow oven?  Is it 4-layer?  Done in KiCAD or something professional?

This specific one is a six layer board, manufactured by WellPCB for $145 for 10 boards. There is 512 Mbytes of DDR3L memory onboard. I've designed it in Orcad Professional, but it should be possible to do it in KiCAD. I'm actually working on a board for Spartan-7 FPGA and DDR2 memory in KiCAD - the goal is to do it in 4 layers, as this project is meant for beginners - I'm going to publish all sources once I actually make the board and verify that it works. I will also place HDMI out connector on this board because Spartan-7 can also drive HDMI out directly.

As for the TPD12S521, will I need this with a TFP410?

I didn't need it because Artix FPGA that I have on this board is capable of driving HDMI interface directly.

[legacy]

DDR3L

DDR3, the most complex stuff to be designed and handled, especially for beginners.

[asmi]

DDR3, the most complex stuff to be designed and handled, especially for beginners.

That's what I thought too in the past. But once I actually tried that, it turned out be much easier than I ever expected it to be.

[BrianHG]

DDR3, the most complex stuff to be designed and handled, especially for beginners.

That's what I thought too in the past. But once I actually tried that, it turned out be much easier than I ever expected it to be.

Ignoring some of the advanced features and if you don't care about shaving every last half clock latency cycle and running them at full tilt speed possible, your controller just about the same as a DDR2 controller.

[jhpadjustable]

DDR3L? Isn't that the stuff that explodes if you turn it off wrong?

[asmi]

Ignoring some of the advanced features and if you don't care about shaving every last half clock latency cycle and running them at full tilt speed possible, your controller just about the same as a DDR2 controller.

I meant from the HW design standpoint. At least for me DDR3 layout seemed much harder than it actually turned out to be. At least for lower speeds (400 MHz is rather low for DDR3), which is what Spartan-7 and Artix-7 support. Going higher requires using Kintex-7, which is significantly more expensive.
For controller I just use MIG (Memory Interface Generator) - it's free and easy to work with.

[asmi]

DDR3L? Isn't that the stuff that explodes if you turn it off wrong?

Well it didn't explode on me...yet

[BrianHG]

Ok, we at at a point where the OP, 'nockieboy' has enough info to make a decision:

A: project must not have BGA, or it can have BGA.
If it cant have BGA, the OP must select to either go with a low cost older FPGA with DRAM, or an all in 1 IC solution like the MAX10 144pin QFP.

When using the older FPGA and DRAM, the op must contend with a more complex PCB, multiple power supply voltages, ram chips and bootprom.


B: Price sensitivity.  If 1 BGA IC is allowed, the Lattice 16$ for 1 chip IC with almost 2 megabit internally pretty much kills everything else in logic density and memory.  Lattice being the third largest FPGA vendor still has relatively decent toolset.  However, you would still need a bootprom and a second regulator for the VCC core voltage.


C: design complexitity.
The TFP410 DVI Transmitter solves the headache of creating and testing his own DVI output serializer core (I realize that home made verilog examples of such a core already exist, but this can be extra work).

Now, with the video modes mentioned, anything he chooses will work, it the development effort and needed and if there will be room for special treats.

If I want a tiny PCB, 1 main IC and HDMI plug, the MAX10 eliminates a lot of complexity and may be possible to be done on a 5$ for 10x 2 layer PCB***. (You really need to know what you are doing and basically the bottom layer is basically a flood-fill GND with a few short trace jumps)

I would make this board a stand alone with a connector for the 8bit MCU board.  I would also offer to make the IC's onboard ram useable as the 8bit cpu's system memory.

If the op went with the larger 2mbit Lattice part, he has the density and speed to offer something like 12 new 256 color sprites, any width up to the width of the screen, with a translucent colors, on every new line of video, from anywhere within the block of system memory, in real time without any overhead.  With the max 10, he could get away with something like 8 sprites at the 180/or/160x240 mode.

For such a project, I would personally recommend using the standard SMPTE 480p base mode of 720x480, 16:9, 27Mhz reference clock as it will work on any PC monitor as well as any TV sold today.  If the op wants 640x480, just center crop the image. (make a black bar an the left and right of the image.)  Also, this standard mode makes integrating the standard HDMI embedded 48Khz stereo audio easy as the exact standard specs are well defined.  Using the 25Mhz VGA 640x480 will add an obstacle upgrade path for embedded audio in the future.

This project is nothing more than a large number of start and stop sequence counters, driving another set of counters look-up memory, use the contents to look up more memory to point to alternate contents of same chunk of memory, and shift the right final content to a palette memory then to feed the DVI transmitter, or feed the internal DVI serializer.

This is why I said in an earlier post, run the internal display memory at 16x the speed of the output pixel feed, you you can read and use each read address to point to another place in ram, 15 times before creating your final resulting pixel.  You may want to make your video memory 16 bits wide so you can access 16 bit words each time allowing a 16bit palette to be stored withing system memory instead of special dedicated registers or memory block.

[jhpadjustable]

When using the older FPGA and DRAM, the op must contend with a more complex PCB, multiple power supply voltages, ram chips and bootprom.

A x16 pseudo-static RAM is not especially layout-sensitive, any more than an SRAM, and is fine running at 3.3V at several tens of megahertz.

However, you would still need a bootprom

Sort of true. A 25 series SPI flash and a dozen pins of header should be plenty, and makes it easy to plug in a USBasp or similar SPI master.

this standard mode makes integrating the standard HDMI embedded 48Khz stereo audio easy

But the TFP410 doesn't. Where does the audio go in?

16-bit palette

There's a point at which one can and should say "screw palettes, we have enough color bits." 4k colors is about that point. More important, it's about as much data as you'd want to push around with a Z80 and a blitter.

There's also a point at which a designer learns that there are a crapload of tradeoffs to be made, and (hopefully) to avoid the second-system effect. 

[nockieboy]

Ok, we at at a point where the OP, 'nockieboy' has enough info to make a decision:

A: project must not have BGA, or it can have BGA.
If it cant have BGA, the OP must select to either go with a low cost older FPGA with DRAM, or an all in 1 IC solution like the MAX10 144pin QFP.

When using the older FPGA and DRAM, the op must contend with a more complex PCB, multiple power supply voltages, ram chips and bootprom.

I'm still waiting on my Spartan 6 dev board, but realise it has SDRAM, not DRAM, on board.  I'd like to be able to test out some DRAM to see how difficult it would be to use it as video RAM in place of internal RAM blocks in the FPGA... If it is viable (both from a complexity AND performance standpoint) then it would be preferable to getting an expensive FPGA with loads of internal RAM.

The MAX10 is tempting, but it's very expensive. 

I have no issue with adding RAM chips and bootprom, even multiple supply voltages so long as it doesn't get TOO complicated (which is highly subjective, I know).  It looks like I'm going to have to switch to KiCAD to design the board no matter what FPGA package / GPU design I go for, as DipTrace's 500 pin/2-layer limit won't cut it with this project. 

BGA is definitely out, though, unless/until I build a suitable reflow oven and get the process stable enough to risk running BGA chips through it.

B: Price sensitivity.  If 1 BGA IC is allowed, the Lattice 16$ for 1 chip IC with almost 2 megabit internally pretty much kills everything else in logic density and memory.  Lattice being the third largest FPGA vendor still has relatively decent toolset.  However, you would still need a bootprom and a second regulator for the VCC core voltage.

Sorry, not sure I read that right - Lattice do a $16 FPGA with 2 megabit internal RAM?!?!?   That changes the game entirely - if that's correct, I'll get started on a reflow oven straight away and would offer the PCB with the FPGA already soldered if I ever put it into production!

Have you mentioned this part already in the conversation?  If so, forgive me as I must have missed the specs (and thus the implications) for it.

C: design complexitity.

If the op went with the larger 2mbit Lattice part, he has the density and speed to offer something like 12 new 256 color sprites, any width up to the width of the screen, with a translucent colors, on every new line of video, from anywhere within the block of system memory, in real time without any overhead.  With the max 10, he could get away with something like 8 sprites at the 180/or/160x240 mode.

Yeah, okay, so I'm seeing that I should really get a grip of this fear of BGA soldering and tackle it head on.

For such a project, I would personally recommend using the standard SMPTE 480p base mode of 720x480, 16:9, 27Mhz reference clock as it will work on any PC monitor as well as any TV sold today.  If the op wants 640x480, just center crop the image. (make a black bar an the left and right of the image.)  Also, this standard mode makes integrating the standard HDMI embedded 48Khz stereo audio easy as the exact standard specs are well defined.

Sounds reasonable to me.  Naive/stupid question - would getting a 27MHz clock from a 25MHz clock source be non-trivial?  All the dev boards I've seen have a 25MHz clock source.

This project is nothing more than a large number of start and stop sequence counters, driving another set of counters look-up memory, use the contents to look up more memory to point to alternate contents of same chunk of memory, and shift the right final content to a palette memory then to feed the DVI transmitter, or feed the internal DVI serializer.

You make it sound so easy... 

[nockieboy]

this standard mode makes integrating the standard HDMI embedded 48Khz stereo audio easy

But the TFP410 doesn't. Where does the audio go in?

Yes of course, this is still a consideration - there must be alternatives that will integrate an audio source into the data stream, though?

16-bit palette

There's a point at which one can and should say "screw palettes, we have enough color bits." 4k colors is about that point. More important, it's about as much data as you'd want to push around with a Z80 and a blitter.

Yes, I was starting to wonder if it wouldn't just be easier to shunt around 2-bytes-per-pixel if I have the memory space for a 4-bit colour space unrestricted by a palette size.  Of course, using internal RAM in the FPGA will still limit my memory size, and doubling the size of the required video RAM will likely either restrict my maximum resolution for 4-bit colour or restrict me to a colour LUT for the screen resolutions that don't have the memory space for 4-bit colour.  Just not sure about the practicalities of using both methods in an FPGA?

There's also a point at which a designer learns that there are a crapload of tradeoffs to be made, and (hopefully) to avoid the second-system effect. 

I'm hoping to avoid the second-system effect - although, as I'll be learning as I go, there's bound to be improvements and embellishments I can make by going back over old code - but I do, however, have a pretty clear end goal in mind. 

[BrianHG]

B: Price sensitivity.  If 1 BGA IC is allowed, the Lattice 16$ for 1 chip IC with almost 2 megabit internally pretty much kills everything else in logic density and memory.  Lattice being the third largest FPGA vendor still has relatively decent toolset.  However, you would still need a bootprom and a second regulator for the VCC core voltage.

Sorry, not sure I read that right - Lattice do a $16 FPGA with 2 megabit internal RAM?!?!?   That changes the game entirely - if that's correct, I'll get started on a reflow oven straight away and would offer the PCB with the FPGA already soldered if I ever put it into production!

Have you mentioned this part already in the conversation?  If so, forgive me as I must have missed the specs (and thus the implications) for it.

$15.86 for 1, $13.94 each for 25, $13.36 each for 100.
A few pages ago: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2752240/#msg2752240

With only 1 small BGA chip (14mm X 14mm), and you using the outer pads only, you can make this work on a 4 layer board and with tinned pads, and because the IC is so small, you can get away with only a good quality hot air gun and a syringe of flux, no oven needed.  Watch a few of Louis Rossman repairs of mac-books where he re-solders small BGA chips.  As long as you have a PCB with solder mask, you can do it easily this way.  (Now, I don't mean populate your PCB with small BGA ICs all over the place.  Dealing with 1 small IC on each PCB will be easy enough with a healthy tube of flux and a hot air gun will be manageable unless you are building 100s of them.  Then use a solder paste stencil and toaster oven...)

As for easy, you really need to plan thing out ahead and choose an HDL and stick with it.  I personally use System Verilog and keep my modules simple stupid enough that they would still work under any compiler, even those which are regular Verilog.

As for the crux of your system, I'll make a reply tonight and you'll laugh as 33% of your problems vanish with around 2 paragraphs of words...

[jhpadjustable]

Sounds reasonable to me.  Naive/stupid question - would getting a 27MHz clock from a 25MHz clock source be non-trivial?  All the dev boards I've seen have a 25MHz clock source.

Rational clock synthesis isn't that bad. Most PLLs on FPGAs can do it just by configuring and instantiating a module. Here's an example from FPGA4FUN's HDMI (really DVI-D) project, which declares an instance of the Xilinx digital clock manager and configures it to multiply the pixel clock by 10, then declares a clock buffer to force the result onto the chip's low-skew clock distribution networks. You could add a .CLKFX_DIVIDE parameter likewise, replacing the default of 1 to achieve a non-integer overall ratio.

Code: [Select]

DCM_SP #(.CLKFX_MULTIPLY(10)) DCM_TMDS_inst(.CLKIN(pixclk), .CLKFX(DCM_TMDS_CLKFX), .RST(1'b0));
BUFG BUFG_TMDSp(.I(DCM_TMDS_CLKFX), .O(clk_TMDS));  // 250 MHz
Some of the lower end FPGAs that don't have onboard clock synthesizers can make use of an offboard clock synthesizer, such as the Si5351, but those can be harder to configure and you must account for delays to and from the synthesizer manually. In either case, clock domain crossing can be a bit tricky if you need other buses to get things done promptly on command. FIFOs, even in their degenerate case of double-buffering with an S-R latch, are an easy and sometimes cheap, but limited and not necessarily prompt way to get clock domain crossing done.

Yes of course, this is still a consideration - there must be alternatives that will integrate an audio source into the data stream, though?

There's a bit of confusion in the thread on DVI-D vs. HDMI. DVI-D is a digital video standard, and basically open and well-documented. HDMI is a superset of DVI-D that includes in-band packets to set color spaces, send audio data, communicate remote control data, defend Hollywood against their customers, etc. and basically proprietary and NDA-infested. HDMI and DVI-D are basically identical at the electrical level. DVI-D transmitters won't generate the packets you need for audio, and HDMI transmitter public data sheets are intentionally incomplete. To my mind, that means you would need to build (or borrow) a transmitter on board the FPGA so that you can generate those packets, glean data about the register configuration for an HDMI transmitter chip from public leaks such as Linux kernel drivers, OR give up on HDMI audio and settle for an analog or S/PDIF output.

Yes, I was starting to wonder if it wouldn't just be easier to shunt around 2-bytes-per-pixel if I have the memory space for a 4-bit colour space unrestricted by a palette size.  Of course, using internal RAM in the FPGA will still limit my memory size, and doubling the size of the required video RAM will likely either restrict my maximum resolution for 4-bit colour or restrict me to a colour LUT for the screen resolutions that don't have the memory space for 4-bit colour.  Just not sure about the practicalities of using both methods in an FPGA?

It's just an if-then statement that turns into a mux. When you're more conversant with HDL, you'll see.

On that note I would strongly caution that you not make any more design or feature decisions until you have hands-on experience with the medium in which you are working. Even then I would wait until I have first picture coming out of the board to decide how to get from spec to implementation. There are subtleties that you might not be considering, such as that block RAMs are still just dozens of individual separate blocks spread over the chip and you (or the synthesis tool) have to use logic and routing to aggregate them, which can get very expensive (in the sense of latency and  logic resources consumed) for a large array.

fpga4fun.com has much fine introductory reading on FPGAs and some gratifying beginner projects. As a reward you can work all the way through the interfacing material to their HDMI example (really just DVI-D, but enough that you would probably understand where to inject logic for audio and so on once you have the spec) and SDRAM. You could even get a head start as most FPGA software has a (limited) simulator suite available, which you can use to display the output waveforms of your design without a board in hand. You'll also want to know how to build virtual test benches for your design to provide stimuli to your design in simulation, say, fake CPU bus cycles or outside clock sources.

[hamster_nz]

Sounds reasonable to me.  Naive/stupid question - would getting a 27MHz clock from a 25MHz clock source be non-trivial?  All the dev boards I've seen have a 25MHz clock source.

This problem can be pretty trivial with a bit of planning.

If you have a 25MHz source, you multiply it by 54 to get a VCO frequency of 1350Mhz, which is in the allowable range of 800MHz to 1600Mhz.

- Divide the VCO by 50 to get 27MHz for your pixel clock
- Divide the VCO by 10 to get your clock to drive the serializers the for DVI-D outputs (using DDR mode).

Oh, it seems that the HDMI spec owners are sending out takedown notices: https://glenwing.github.io/docs/HDMI-1.4b.pdf

Might pay to look for "hdmi specification 1.4 filetype:pdf" in everybody's favorite web search engine while you can, just for future reference.

[BrianHG]

If the OP is making his own board, or is expecting to, he can always change the crystal oscillator from 25Mhz to 27Mhz.
This may allow for slower core PLLs on different FPGA, however, if he uses the PLL setup wizard, he would just type in the wizard the source clock frequency and the desired output clocks & the wizard would handle this all on it's own.

[hamster_nz]

If the OP is making his own board, or is expecting to, he can always change the crystal oscillator from 25Mhz to 27Mhz.
This may allow for slower core PLLs on different FPGA, however, if he uses the PLL setup wizard, he would just type in the wizard the source clock frequency and the desired output clocks & the wizard would handle this all on it's own.

I must be old school. I find the wizards are:

- slow to use - a simple change takes a long time

- somewhat inconsistent on their output esp between tool versions.

- very sensitive to inputs (esp when your desired frequencies are a nice decimal number)

- The generated code need tweaking if you use the generated clocks to do something special (e.g. drive SERDES) as you have to add or remove clock buffers, and when you do this you can't use the wizard to regenerate the code

- unless you know what output constraints you have within the clocking resources of the FPGA you just end up trying things and seeing if you get lucky. It isn't a recipe for a well-engineered design

- for me, they often seem to have different ideas of what a "close enough" solution is. Usually a better "close enough" solution exists

But my biggest grip is that they fill your code base with code that is "(c) Vendor X" with an explicit license, that isn't compatible with open projects:

Do a quick search for for

    site:github.com "Copyright(C)" "by Xilinx, Inc"

Here's an example:

Code: [Select]

-- System Generator version 11.1 VHDL source file.
 --
 -- Copyright(C) 2009 by Xilinx, Inc.  All rights reserved.  This
 -- text/file contains proprietary, confidential information of Xilinx,
 -- Inc., is distributed under license from Xilinx, Inc., and may be used,
 -- copied and/or disclosed only pursuant to the terms of a valid license
 -- agreement with Xilinx, Inc.  Xilinx hereby grants you a license to use
 -- this text/file solely for design, simulation, implementation and
 -- creation of design files limited to Xilinx devices or technologies.
 -- Use with non-Xilinx devices or technologies is expressly prohibited
 -- and immediately terminates your license unless covered by a separate
 -- agreement.


[asmi]

I must be old school. I find the wizards are:

You don't need to actually generate any code with the wizard. I use clocking wizard to calculate all coefficients, and then just place them into my own MCMM/PLL instantiation code. I just couldn't be bothered to calculate this stuff myself

[asmi]

If the OP is making his own board, or is expecting to, he can always change the crystal oscillator from 25Mhz to 27Mhz.

Or just add a second (third, fourth, you get the point) oscillator on a board. This is an advantage of making your own board - you can place whatever stuff you need (or you think you need ).

[hamster_nz]

I must be old school. I find the wizards are:

You don't need to actually generate any code with the wizard. I use clocking wizard to calculate all coefficients, and then just place them into my own MCMM/PLL instantiation code. I just couldn't be bothered to calculate this stuff myself

^^^^^^

This is most likely the optimal way to use the clocking wizard.