FPGA VGA Controller for 8-bit computer

[asmi]

Yeah, I know, but I have a bit of OCD when it comes to fine-tuning stuff like this.  I could happily spend the next week tweaking signal traces and component positioning to make it as efficient as possible (within my level of skill and knowledge, obviously).

Now I definitely can't wait to see your OCD going nuts as you route and length-match DDR3 interface As someone with a relatively mild case of the same illness things get... painful at times when I work on DDRx interfaces

[BrianHG]

Arrg, stop the board.  I tried using those pins in Quartus and it says that the maximum for the selected IO is 640mbs.  Fine for 480p, but not 720p.  I think I've just selected the wrong IO standard in Quartus, but I need to make sure if you want to attempt 720p.

Ok, 'STTL-2 Class II' on those chosen IOs supports 740mb/sec, so we are ok...
In fact, we can even do it non-differential.  If the NXP will take in a non-differential and output proper HDMI, then you only need 4 outputs to drive the HDMI saving another 4 IOs.  However, you loose the common mode noise rejection between the FPGA and NXP IC.  But, I guess it is the same for DDR3 data lines...

Otherwise, the board is fine.

Ok, it's annoying how Quartus hounds you when you use their LVDS megafunction when compiling, checking the clocks exactly and aborting if you exceed a single MHz.  I'm having trouble getting 740MHz and true differential working with the exact chosen IO, however, the code is simple enough to compile in a CV chip and Quartus tells you if you will achieve the official frequency or not.

This is also good if we use Quartus' DDR3 memory compiler and choose the IO pins.  It will tell us straight in the face if we will achieve the 400MHz/800mtps mark or not.

[asmi]

In fact, we can even do it non-differential.

No, you can not.

If the NXP will take in a non-differential and output proper HDMI

No, it can not.

Don't get too excited just yet. We still don't see any image on nockieboy's monitor.

And the IC you've chosen is purely analog one. It doesn't do anything aside from voltage shifting. Here is direct quote from the datasheet:

The PTN3366 does not retime any data. It contains no state machines. No inputs or outputs of the device are latched or clocked. Because the PTN3366 acts as a transparent level shifter, no reset is required.

So it just takes what's on input and places it on the output - no logic, no latches, no nothing.
I would've chosen something more smart, with retiming.

[asmi]

This is also good if we use Quartus' DDR3 memory compiler and choose the IO pins.  It will tell us straight in the face if we will achieve the 400MHz/800mtps mark or not.

Xilinx MIG (Memory Interface Generator) doesn't even let you select options or enter parameters which won't work with device/speed grade/package combination you've chosen.

[nockieboy]

Yes, the pin 1 ID is missing...
Add a fat dot or arrow on the silkscreen.

Added a white dot - bottom right corner, next to C2, corresponding with pin 1.

Yes, the pin 1 ID is missing...

I don't see polarity mark for the diode either.

It's underneath the diode. Check any of my previous posts with the 2D PCB image. 

Don't get too excited just yet. We still don't see any image on nockieboy's monitor.

And the IC you've chosen is purely analog one. It doesn't do anything aside from voltage shifting. Here is direct quote from the datasheet:

The PTN3366 does not retime any data. It contains no state machines. No inputs or outputs of the device are latched or clocked. Because the PTN3366 acts as a transparent level shifter, no reset is required.

So it just takes what's on input and places it on the output - no logic, no latches, no nothing.
I would've chosen something more smart, with retiming.

I won't lose sleep over not being able to test or output 720p.  I don't know enough about the signal speeds or other factors at play here to know how much leeway we have with these signals.  Would a 'smart' device be overkill?  Or would it be the difference between being able to display 480p or 720p?

I can't help but look at this video...

https://youtu.be/bTamCo2C6kg?t=105

... and wonder if we're over-engineering or over-worrying about the problem, though.  Admittedly, we can't see what else is on the little PCB that holds the HDMI connector, but it doesn't seem to me that the maker is that concerned about differential pairing, trace lengths, or even the power of the FPGA he's using (it's a Cyclone II EP2C5T144 connected with ribbon cable, for Pete's sake) - it seems to spit out a stable 480p image just fine.

[BrianHG]

If the NXP will take in a non-differential and output proper HDMI

No, it can not.

Don't get too excited just yet. We still don't see any image on nockieboy's monitor.

And the IC you've chosen is purely analog one. It doesn't do anything aside from voltage shifting. Here is direct quote from the datasheet:

Heheheh, did you not know?  A linear differential amplifier only evaluates the 2 input signals, if 1 input is higher than the other, the output will go high, IE the + goes to + and the - goes to -.  If the + input is lower than the - input, then the + output goes low while the - output goes high.  It's basically a 3GHz differential opamp with a differential output line driver.

If the internal terminator hold both the +&- inputs to 1.8v via in's internal 50ohm terminator resistor and we only cycle the +input through that 0.1uf cap, as we push the + above and below the 50 1.8v threshold while the - stays at 1.8v, the amp will make a balanced output...

[BrianHG]

... and wonder if we're over-engineering or over-worrying about the problem, though.  Admittedly, we can't see what else is on the little PCB that holds the HDMI connector, but it doesn't seem to me that the maker is that concerned about differential pairing, trace lengths, or even the power of the FPGA he's using (it's a Cyclone II EP2C5T144 connected with ribbon cable, for Pete's sake) - it seems to spit out a stable 480p image just fine.

It's not that.  You are making a public domain PCB and code available on github.  We just want to make sure whoever builds the thing will:
A) Get it operational no matter what monitor or cable they have.
B) Wont accidentally kill their FPGA when plugging the thing into a monitor.
C) Won damage a really expensive TV they may be connecting this VGA board to.

This 92cent NXP chip allows us to check those boxes while a flat ribbon cable might work for you and a few others, I cannot in good conscience let you try and save that 1$ and send out questionable hardware, especially after removing all the other parts on your PCB.  IE, no analog VGA to fall back on...

[BrianHG]

I just tried compiling a 740mb 4 channel serializer for CycloneV.  All the differential IO voltage standards work fine.  It's just the CycloneIII which couldn't handle 740mbs, only 640mbs.

Also, the new Quartus, you just provide parallel data & clock, it will automatically configure the PLL on it's own.

[BrianHG]

So many damn features.
It's gonna take time to setup the best possibly way for our GPU.

Though, 400MHz seems to turn up (not red) as well as the CV's 'hard external memory controller'.

I also like the that you can define multiple in, out, IO read/write ports and set a priority to each one.

[nockieboy]

It's not that.  You are making a public domain PCB and code available on github.  We just want to make sure whoever builds the thing will:
A) Get it operational no matter what monitor or cable they have.
B) Wont accidentally kill their FPGA when plugging the thing into a monitor.
C) Won damage a really expensive TV they may be connecting this VGA board to.

This 92cent NXP chip allows us to check those boxes while a flat ribbon cable might work for you and a few others, I cannot in good conscience let you try and save that 1$ and send out questionable hardware, especially after removing all the other parts on your PCB.  IE, no analog VGA to fall back on...

In fairness, I'm all for safety and making sure it works - see my changes to the ESD protection for the HDMI connector as an example - I was just throwing a grenade into the conversation between you and asmi around the whole 'will it, won't it' at 480p/720p.  I'm sure that if someone can bodge a 480p output using a Cyclone II and some ribbon cable, this should work quite nicely given the thought that's gone into it - especially if the Cyclone V's IO can manage the frequencies needed for 720p. 

I'm going to pull the trigger on this PCB order later today and put the parts order in with Mouser.  That'll include (most of) the parts I'll need for the GPU card, too - including:

• TLV62130ARGTR switchable voltage regs,
• 10x PTN3366s (probably going to need practice soldering these, so have over-ordered), and
• MT41J128M16JT-125:K TR DDR3 DRAMS.

...and a whole host of passives in 0402 and 0603.

On a slight tangent, can anyone shed any light on the MAX3421 USB Interface IC?  I've got it (and supporting components) in my trolley with the intention of adding it to the GPU card (or, more likely, building a test/dev card to try it out on my EasyFPGA dev board), but it's not a cheap IC and I'm wondering about the viability of using it to replace the PS2 port, so I can use a USB keyboard instead of a PS2 one.  Anyone have any thoughts on the idea?

[nockieboy]

JLCPCB is quoting CAN$13.21 for 10x 0.8mm PCBs.  More than half of that is shipping to the UK.

[asmi]

On a slight tangent, can anyone shed any light on the MAX3421 USB Interface IC?  I've got it (and supporting components) in my trolley with the intention of adding it to the GPU card (or, more likely, building a test/dev card to try it out on my EasyFPGA dev board), but it's not a cheap IC and I'm wondering about the viability of using it to replace the PS2 port, so I can use a USB keyboard instead of a PS2 one.  Anyone have any thoughts on the idea?

There is also FT313H chip, which is about two times cheaper and supports USB 2.0 high-speed (480 Mbit/s). But I have no experience with either of them, so can't really say anything for or against. Purely on paper FTDI chip seems like a better idea (cheaper, higher speed - you can even connect thumb drive to it), and if you combine it with something like USB2514 (4 port USB 2.0 hub), you can implement 4 USB 2.0 ports and so connect not only keyboard and mouse, but other stuff as well. That would probably be another good candidate for a prototype PCB.

[nockieboy]

@BrianHG
which protections would you recommend between a FPGA and a CGA-CRT tube (C-G-A, not VGA)?

You're going to want to start your own thread for anything off-topic like this. 

[BrianHG]

• MT41J128M16JT-125:K TR DDR3 DRAMS.

LCSC has stock of the DDR3, why not let JLPCB mount that ram with the FPGA?

https://lcsc.com/product-detail/FLASH_Micron-Tech-MT41J128M16JT-093-K_C395383.html

Though it's the 1066MHz version.  Ask asmi if it will work down at 400MHz, or 303MHz.

[BrianHG]

I'm sure that if someone can bodge a 480p output using a Cyclone II and some ribbon cable, this should work quite nicely given the thought that's gone into it - especially if the Cyclone V's IO can manage the frequencies needed for 720p. 

He might only be doing 240p/480i which is 135 megabit, or, a maximum signal of 67.5MHz going down that ribbon cable.
If he is doing 480p, then that's double, 270megabit, or a maximum signal of 135MHz going down that ribbon cable.

(Both of these well withing CycloneI/II/III/IV capabilities.)

720p is 742.5megabit, or a top frequency of 372.75MHz going down an HDMI cable.

Only Cyclone V -7/-6 reach this mark or CycloneIV -6-7 on specific IO banks running with Altera's megafunctions & expected code.

[asmi]

One more thing I would like to add regarding USB. I read up a bit on FT313H and it seems like a good device - it implements SRAM-like access via 8 or 16 bit wide parallel bus (this is good for speed) which can run up to 1000 / 80 ns = 12.5 MHz, so up to 25 MBytes/s of bandwidth. It's got 24 KB of internal memory, and supports both PIO and DMA operations. It also implements EHCI (Enhanced Host Controller Interface), which is Intel's standard for USB 2.0 controllers, that is good in a sense that there is quite a bit of information out there on how to use it, but not so good in a sense that you will have to write quite a bit of code, as well as you will need to have a good knowledge of how USB bus actually works at the packet level. Another good news is that unlike most other specifications, USB specs are all in public access, so there won't be any shortage of information.
My concern here is that all that software stuff may prove to be too much for a little Z80 to handle. USB stacks has always been relatively light on hardware, but heavy on software. This design decision was a key to it's success as software can be updated in the field while hardware can not, but in our case it might become a problem. Things like keyboard and mouse will probably be OK as they don't generate much USB traffic, but something more bus-intensive might be a challenge. I still think it's worth a try to implement and experiment with, but I also think it's important to set your expectation appropriately.

[asmi]

https://lcsc.com/product-detail/FLASH_Micron-Tech-MT41J128M16JT-093-K_C395383.html

Though it's the 1066MHz version.  Ask asmi if it will work down at 400MHz, or 303MHz.

Absolutely - see attached speed bin. BTW these tables are all taken from the datasheet for these chips
DDRx memory devices is a rare shining example of HW design done right when it comes to compatibility - higher-speed devices will work in lower-speed modes, DDR3L devices (1.35V) will work in "regular" DDR3 mode (1.5V), all footprints for specific bus width are designed to ensure that lower capacity devices will work instead of higher-capacity ones, and the other way around, and devices from different vendors work together no problem (if other parameters are compatible). You won't find many examples like that in hardware world.

[nockieboy]

One more thing I would like to add regarding USB. I read up a bit on FT313H and it seems like a good device - it implements SRAM-like access via 8 or 16 bit wide parallel bus (this is good for speed) which can run up to 1000 / 80 ns = 12.5 MHz, so up to 25 MBytes/s of bandwidth. It's got 24 KB of internal memory, and supports both PIO and DMA operations. It also implements EHCI (Enhanced Host Controller Interface), which is Intel's standard for USB 2.0 controllers, that is good in a sense that there is quite a bit of information out there on how to use it, but not so good in a sense that you will have to write quite a bit of code, as well as you will need to have a good knowledge of how USB bus actually works at the packet level. Another good news is that unlike most other specifications, USB specs are all in public access, so there won't be any shortage of information.
My concern here is that all that software stuff may prove to be too much for a little Z80 to handle. USB stacks has always been relatively light on hardware, but heavy on software. This design decision was a key to it's success as software can be updated in the field while hardware can not, but in our case it might become a problem. Things like keyboard and mouse will probably be OK as they don't generate much USB traffic, but something more bus-intensive might be a challenge. I still think it's worth a try to implement and experiment with, but I also think it's important to set your expectation appropriately.

I just want to be able to plug a USB keyboard into my computer, maybe a mouse at a stretch.  That's really it.  It would be nice to replace the PS2 keyboard interface as it's getting harder and harder to find PS2 keyboards these days (and I don't have a PS2 mouse), whereas USB ones are ubiquitous.  My intention was for the FPGA to pass characters (or mouse coordinates) to the Z80 in much the same way as the current PS2 interface does.  I'm not really concerned with accessing USB storage - that would definitely be a big ask of the Z80, I think.

I think that 8/16-bit bus between the FT313 and the FPGA will be an issue for me, though - that's potentially a lot of IOs that I may not have, depending on how the DDR3 goes.  The MAX3421 can do it over an SPI connection, so that keeps IO usage to an absolute minimum.

[BrianHG]

  Intel, with their new online datasheet BS.
Here are all the CV  in old fashioned .pdf.

Cyclone V Handbook Volume I -> General IC features
https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-v/cv_5v2.pdf

Cyclone V Handbook Volume II -> GX tranceivers (not us...)
https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-v/cv_5v3.pdf

Cyclone V Handbook Volume III -> Hard Processor System (Contains information on A9 & hard memory controler)
https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-v/cv_5v4.pdf

Cyclone V Handbook Datasheet I -> Contains IO voltages, standards & maximum switching clock MHz of normal IOs and core ALU/ram FMAX.
https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/hb/cyclone-v/cv_5v1.pdf

Page 52 of the 'datasheet' has the True-Differential-LVDS transmitter specs.
The jitter rating is worst case 160ps.  This is good enough for HDMI 720p without any re-clocking.
However, the 'Intel-dicks' didn't define the 'SERDES factor J = 1 to 2, Uses DDR Registers ' in the data sheet, though you do see it is part of the 'True Differential I/O Standards - fHSDR'rated at 840mbps & we know from the DDR controller that the DDR buffers can do at least 800mbps on the -6 & -7 variants.

Page 18 says the Cyclone V can support up to 2 DDR3 hard-memory controllers @400MHz, 800mtps.  The soft-controller at 300MHz is for when you place the DDR on any IOs you like.  The hard controller means you must properly wire the each dedicated 8/9 DQ's in a bank with the 2 DQS/DQSn for that bank to get the 400MHz/800mtps speed.

[asmi]

I just want to be able to plug a USB keyboard into my computer, maybe a mouse at a stretch.  That's really it.  It would be nice to replace the PS2 keyboard interface as it's getting harder and harder to find PS2 keyboards these days (and I don't have a PS2 mouse), whereas USB ones are ubiquitous.  My intention was for the FPGA to pass characters (or mouse coordinates) to the Z80 in much the same way as the current PS2 interface does.  I'm not really concerned with accessing USB storage - that would definitely be a big ask of the Z80, I think.

I agree, but "a man can dream" (C)

I think that 8/16-bit bus between the FT313 and the FPGA will be an issue for me, though - that's potentially a lot of IOs that I may not have, depending on how the DDR3 goes.  The MAX3421 can do it over an SPI connection, so that keeps IO usage to an absolute minimum.

Have you actually started putting together schematics for all these updates?

Most USB-capable SoCs these days connect to USB 2.0 PHY via ULPI bus, which is a parallel 8 bit bus, and implement EHCI inside the SoC itself. This is why I was surprised to learn that such chips even exist as a stand-alone devices. The more I read about it, the more I like it. Of course, if you want performance, that device won't quite cut it, but in many-many cases performance is not very critical, and 10-20 MBytes/s might be more than enough, especially if you also get simplicity of implementation. Come to think of it, even USB audio streaming would require much less bandwidth than that.

[asmi]

Page 18 says the Cyclone V can support up to 2 DDR3 hard-memory controllers @400MHz, 800mtps.  The soft-controller at 300MHz is for when you place the DDR on any IOs you like.  The hard controller means you must properly wire the each dedicated 8/9 DQ's in a bank with the 2 DQS's for that bank to get the 400MHz/800mtps speed.

But does it actually list the pins you are supposed to use? I was not able to find such information anywhere...

[BrianHG]

Page 18 says the Cyclone V can support up to 2 DDR3 hard-memory controllers @400MHz, 800mtps.  The soft-controller at 300MHz is for when you place the DDR on any IOs you like.  The hard controller means you must properly wire the each dedicated 8/9 DQ's in a bank with the 2 DQS's for that bank to get the 400MHz/800mtps speed.

But does it actually list the pins you are supposed to use? I was not able to find such information anywhere...

Ahhh, you are looking for the 'Pin Planner' / IO pin list.

They are labeled already in the current schematic blocks, + in Quartus, when you open the chosen IC's pin-planner, they are also all fully labeled.
Give me a sec, I do believe Excel spreadsheets exist from Intel with the same info.

However, I will not let Nockieboy get away with finishing the schematic until he builds a project with at least a wired DDR3 ram controller into the FPGA he is using with a simple separate read and write port to unused IO pins at a minimum.  I want to see a timing closure compile of such a project guaranteeing the chosen DDR3 wiring will work.

[asmi]

However, I will not let Nockieboy get away with finishing the schematic until he builds a project with at least a wired DDR3 ram controller into the FPGA he is using with a simple separate read and write port to unused IO pins at a minimum.  I want to see a timing closure compile of such a project guaranteeing the chosen DDR3 wiring will work.

When I design a board with 7 series FPGA, in Vivado there is a way to quickly and graphically put together a "simple" (it's not very simple really, but since we use only pre-made IPs, it seems that way) design with memory controller, softcore CPU with debug module, and GPIO module (to flash some LEDs) so that I can test that my DDR pinout will work, and I also use this design in initial hardware bring-up since it's known-to-work. In Vivado such design literally take a couple of minutes to put together (pin mapping is by far the longest stage as it's more-or-less manual), and after 5-10 minutes to place&route design I have my bitstream ready to be programmed into the FPGA.

Is something like this possible in Intel world? I seem to recall that qsys thingy, but it's been few years since I touched it, so don't really remember much of what it can do.

[BrianHG]

Question for Nockieboy, will you stick with Quartus Prime 18.1 for this project, or upgrade to Quartus Prime 20.3?

[BrianHG]

However, I will not let Nockieboy get away with finishing the schematic until he builds a project with at least a wired DDR3 ram controller into the FPGA he is using with a simple separate read and write port to unused IO pins at a minimum.  I want to see a timing closure compile of such a project guaranteeing the chosen DDR3 wiring will work.

When I design a board with 7 series FPGA, in Vivado there is a way to quickly and graphically put together a "simple" (it's not very simple really, but since we use only pre-made IPs, it seems that way) design with memory controller, softcore CPU with debug module, and GPIO module (to flash some LEDs) so that I can test that my DDR pinout will work, and I also use this design in initial hardware bring-up since it's known-to-work. In Vivado such design literally take a couple of minutes to put together (pin mapping is by far the longest stage as it's more-or-less manual), and after 5-10 minutes to place&route design I have my bitstream ready to be programmed into the FPGA.

Is something like this possible in Intel world? I seem to recall that qsys thingy, but it's been few years since I touched it, so don't really remember much of what it can do.

Yes.  But when Nockieboy will be doing this for the first time, it will take longer than 5-10 minutes...
Those screenshots from Intel's DDR3 ram controller setup page generates 2 things you can use, either a 'Block Symbol' which you place in a block diagram which will have a bunch of input and output busses (IE Address-data in/out, or avilon bus), and IOs port for the DDR3 ram chips/module which you wire to where you like.  Or, it will output a VHDL/Verilog module with those busses and IOs as ports & parameter settings which you may adjust.