FPGA VGA Controller for 8-bit computer

[BrianHG]

For the external DDR memory interface, the CV Handbook Vol I section 6 spells it out.

Table 6-5 tells you the where the DQs blocks exist.
All x8, 3 of them on the bottom.
We need 3, plus we will also use an x8 block as the HDMI transmitter lanes.
Maybe the bottom and 1 lower left or right side set to 1.5v will be enough for the ram & HDMI.

Figure 6-2 shows the DQS pins and DLL connections on our chosen CV IC.
Figure 6-8 shows the PHYCLK networks.

  
Table 6-16 shows the 'Hard Memory Controller Width for CV ', in the F256 pin device, it is not bonded to the IOs.
You need the U484 or F484 device, or, M383 device to get the 400MHz.

So, we are stuck with 303MHz, 606mtps without any sort of overclocking the fabric.
Or the compiler allows a higher speed without timing violations because our design is so simple.
Or we write our own and cheat a little to get the IO port's theoretical ~800Mhz DDR data IO rate, though, 400MHz logic to control the ram would need to be a simple sequencer.

[BrianHG]

Pinout files:

https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/dp/cyclone-v/5ceba2.pdf
https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/dp/cyclone-v/5ceba2.txt
https://www.intel.com/content/dam/altera-www/global/en_US/pdfs/literature/dp/cyclone-v/5ceba2.xls

Need to be careful about the LVDS output.  If we want the 'TRUE' 740/840mbps, we need to choose dedicated LVDS TX pair channels and not the emulated ones which only achieve 640mbps.

[asmi]

 
Table 6-16 shows the 'Hard Memory Controller Width for CV ', in the F256 pin device, it is not bonded to the IOs.
You need the U484 or F484 device, or, M383 device to get the 400MHz.

So, we are stuck with 303MHz, 606mtps without any sort of overclocking the fabric.
Or the compiler allows a higher speed without timing violations.
Or we write our own and cheat a little to get the IO port's theoretical ~800Mhz DDR data IO rate, though, 400MHz logic to control the ram would need to be a simple sequencer.

See - Antel itself pushes you towards Xilinx! There you will have your 400 MHz DDR3, and 720p HDMI, and more

[BrianHG]

 
Table 6-16 shows the 'Hard Memory Controller Width for CV ', in the F256 pin device, it is not bonded to the IOs.
You need the U484 or F484 device, or, M383 device to get the 400MHz.

So, we are stuck with 303MHz, 606mtps without any sort of overclocking the fabric.
Or the compiler allows a higher speed without timing violations.
Or we write our own and cheat a little to get the IO port's theoretical ~800Mhz DDR data IO rate, though, 400MHz logic to control the ram would need to be a simple sequencer.

See - Antel itself pushes you towards Xilinx! There you will have your 400 MHz DDR3, and 720p HDMI, and more

Yup, you need to pay 4$ more for the F484 version, and more PCB area...
I say they should have retired their entire 28nm garbage and only begin their lineup with the Arria FPGAs.
Or, drop the prices of their 28nm lineup by at least 50% and drop their Arria line's price by a good 50-70%.  Then they will be a good competitive deal.  But this is 'Intel' with their 'Complex' and overpriced self-induced superiority.

[asmi]

Yup, you need to pay 4$ more for the F484 version, and more PCB area...

I meant Artix-7, it's 256 ball package has 170 user IO balls, which will be more than enough for DDR3 and for everything else. And no need for level shifting for HDMI, and even 1080p@60Hz if you overclock it a little.

But this is 'Intel' with their 'Complex' and overpriced self-induced superiority.

I hope they will learn the lesson once again brought to them by AMD. Last time they did so, but evidently it didn't last for long. Hopefully this time it will last longer.

[nockieboy]

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?

Hmm.. well, I did do a schematic for the MAX3421 based on the datasheet - it's on the 'Peripherals' page of all the recent GPU schematics I've posted (NOT the DVI Tester ones).

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.

I agree - if I want performance (anything more than the USB 1 12MBytes/s) then I'll need an 8- or 16-bit interface to the USB Host chip, but for keyboard and mouse usage, I think an SPI interface will work just fine.

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

Don't mind upgrading to 20.3 (well, more accurately, installing 20.3 alongside the other two versions) if it provides more useful tools/is better.

 
Table 6-16 shows the 'Hard Memory Controller Width for CV ', in the F256 pin device, it is not bonded to the IOs.
You need the U484 or F484 device, or, M383 device to get the 400MHz.

So, we are stuck with 303MHz, 606mtps without any sort of overclocking the fabric.
Or the compiler allows a higher speed without timing violations.
Or we write our own and cheat a little to get the IO port's theoretical ~800Mhz DDR data IO rate, though, 400MHz logic to control the ram would need to be a simple sequencer.

See - Antel itself pushes you towards Xilinx! There you will have your 400 MHz DDR3, and 720p HDMI, and more

Yup, you need to pay 4$ more for the F484 version, and more PCB area...
I say they should have retired their entire 28nm garbage and only begin their lineup with the Arria FPGAs.
Or, drop the prices of their 28nm lineup by at least 50% and drop their Arria line's price by a good 50-70%.  Then they will be a good competitive deal.  But this is 'Intel' with their 'Complex' and overpriced self-induced superiority.

Ooookaaaay.  So where does this leave us with the Cyclone V FBGA256 as the FPGA of choice?  Should I start looking at shoehorning an F484 into the PCB, or just stop and bite the bullet and switch over to Xilinx?

[BrianHG]

Just so we are clear, at 300MHz, you are still getting 1.2 giga-bytes a second with even a CV-8...
With overhead, ~1 giga-byte a second.
Do you need more?

Just for comparison, the Hyperram would have achieved ~150 megabytes a second.

1 VGA/480p 16bit color display MAGGIE layer eats around 54 megabytes a second.
1 16bit 720p@60hz, or 1080p@30hz MAGGIE layer eats around 150 megabytes a second.
(That's 4 16 bit 1080p layers easy with DDR3 at 300MHz, or 12 VGA 640x480 layers.  These figures leaves excessive access time left for the accelerated geometry, audio, FPU, SD-hard-disk at a rate the Z80 cant even begin to cope with even if it were 100MHz.  Not to mention if you use 1 layer less, or 1 or 2 of the counted layers is only 8 bit 256 colors.  And all this still has 0 effect on the FPGA internal memory's layers which operate in parallel.)

[asmi]

I agree - if I want performance (anything more than the USB 1 12MBytes/s) then I'll need an 8- or 16-bit interface to the USB Host chip, but for keyboard and mouse usage, I think an SPI interface will work just fine.

Well if you move to a larger package or to Artix, you will have enough IO pins for everything. I still think that FTDI chip is a better long-term option as it provides better path for new functionality down the road. And SRAM is much easier protocol than SPI.

[asmi]

Just for comparison, the Hyperram would have achieved ~150 megabytes a second.

Why 150? It's running at 200 MHz DDR, so theoretical maximum will be 400 Mbytes/s, and in practice my design achieved bandwidth quite close to the limit (though I used 166 MHz DDR devices because 200 MHz ones didn't exist yet at that time). The trick here to utilize LONG bursts - not 4-8 clocks long, but more like 64 clocks long or even longer. This way you will better amortize initial access latency, even if you work in double latency mode (which is how I did it because I had two modules running in parallel lockstep).
DDR3 x16 running at 300 MHz will give you about triple that bandwidth (300 * 2 * 2 = 1200 vs 400), 400 MHz will give 4 times bandwidth.

[BrianHG]

Just for comparison, the Hyperram would have achieved ~150 megabytes a second.

Why 150? It's running at 200 MHz DDR, so theoretical maximum will be 400 Mbytes/s, and in practice my design achieved bandwidth quite close to the limit (though I used 166 MHz DDR devices because 200 MHz ones didn't exist yet at that time). The trick here to utilize LONG bursts...

We cannot do long bursts every time and you cannot terminate midway a long burst with Hyperram when you need to.
We would also throw out a lot of clock cycles here when drawing thin vertical lines.
Intel's DDR3 controller specifies smart alternating banking with multiport priority & weight allocation with burst termination capabilities built in.  Are you saying Nockieboy would have achieved all that with his home-made Hyperram controller?

[asmi]

We cannot do long bursts every time and you cannot terminate midway a long burst with Hyperram when you need to...

What do you mean? Of course you can terminate burst whenever you need to. As long as you provide data, it will accept it. Same for reading - as long as you hold CS low and provide clocks, it will continue pumping out data. There are a couple of gotchas with page wraparounds, but other than that - it's that simple. If you want to to cut off your write burst mid-clock, you can use RWDS to suppress write of the falling edge.
The only real downside of HyperRAM compared to DDRx is that it's not pipelined, meaning you can't send a new command as another one is being executed, and this way effectively hide access latency. With DDRx you can, and that's how you achieve the best data bus utilization.

Intel's DDR3 controller specifies smart alternating banking with multiport priority & weight allocation with burst termination capabilities built in.  Are you saying Nockieboy would have achieved all that with his home-made Hyperram controller?

Absolutely. HyperBus protocol is super-simple - you send address, you wait for latency, and you send data/receive data. That's all there is to it. Use cache BRAM for random access within page and only commit/read long cache lines - and you will achieve very high bus utilization with minimal effort. And use double-buffering to avoid race conditions.
Like I said, the only serious downside of HyperRAM (aside from too few options as far as capacity goes) is the fact that it's not pipelined. This seriously harms random access speed. Everything else are just advantages - it's simple, it's low pin count, it's fairly efficient if utilized properly.

[BrianHG]

We cannot do long bursts every time and you cannot terminate midway a long burst with Hyperram when you need to...

What do you mean? Of course you can terminate burst whenever you need to. As long as you provide data, it will accept it. Same for reading - as long as you hold CS low and provide clocks, it will continue pumping out data.

I knew about setting the burst size and well aware of all the wrap-around ramifications.  I have engineered my own DDR2 controller ~12 years ago.  I missed the part about terminating mid burst just by removing the CS.  Damn, a number of additional penalties & cycles galore just to get the thing started again, especially if you just want to hop somewhere else in the same page...

[asmi]

Damn, a number of additional penalties & cycles galore just to get the thing started again, especially if you just want to hop somewhere else in the same page...

This is why I'm so insistent on doing long bursts. With DDRx you can do random access within the page, or within different pages as long as they are in different banks, with virtually no penalty (thanks to pipelining), but with HyperRAM bursts are the only way to achieve reasonable bus utilization. This is especially so if you need to use fixed double latency (this is default setting BTW even in 64 MBit devices) - for example if you want to use double-die devices, or have multiple devices in parallel lockstep. Random access is *incredibly* expensive with HyperRAM. HyperBus protocol was clearly designed to work with caches (long cache lines will help amortize initial latency), or video/audio streaming (where again you work with rather large chunks at a time), and no attempt was made to improve performance of random access.

[nockieboy]

Just so we are clear, at 300MHz, you are still getting 1.2 giga-bytes a second with even a CV-8...
With overhead, ~1 giga-byte a second.
Do you need more?

Just for comparison, the Hyperram would have achieved ~150 megabytes a second.

1 VGA/480p 16bit color display MAGGIE layer eats around 54 megabytes a second.
1 16bit 720p@60hz, or 1080p@30hz MAGGIE layer eats around 150 megabytes a second.
(That's 4 16 bit 1080p layers easy with DDR3 at 300MHz, or 12 VGA 640x480 layers.  These figures leaves excessive access time left for the accelerated geometry, audio, FPU, SD-hard-disk at a rate the Z80 cant even begin to cope with even if it were 100MHz.  Not to mention if you use 1 layer less, or 1 or 2 of the counted layers is only 8 bit 256 colors.  And all this still has 0 effect on the FPGA internal memory's layers which operate in parallel.)

Ah, maybe I got the wrong end of the stick when I read your previous posts - I read it as though the C5 was going to have difficulty doing what we want.  More than happy with those figures.

I agree - if I want performance (anything more than the USB 1 12MBytes/s) then I'll need an 8- or 16-bit interface to the USB Host chip, but for keyboard and mouse usage, I think an SPI interface will work just fine.

Well if you move to a larger package or to Artix, you will have enough IO pins for everything. I still think that FTDI chip is a better long-term option as it provides better path for new functionality down the road. And SRAM is much easier protocol than SPI.

Just to be clear, the only reason I'm not using the FT313H chip is because I'm not sure how many IOs I'll have available, and I'm still slightly averse to routing all those signals.  I'm sure that'll go when I get started on this DDR3, though...

Maybe I'm more likely to have success with the SRAM interface if it's simpler and it's also a lot cheaper and requires no support chip to handle the VBUS, but I see no harm in throwing together a board based on the MAX3421 to try out on my FPGA dev board; with an SPI interface, I could link the USB dev board to my existing GPU card by temporarily re-purposing the existing serial debug port (and a couple of spare IOs) into an SPI port and try out whatever solution I come up with on an actual GPU card connected to my Z80.

My confidence in getting a working USB interface is pretty low though - there's not a lot of help online about it and what there is seems to be talking about using software stacks, embedded Linux OSes or PIC chips (throwing a whole other tool chain into the mix) and general tomfoolery like that.

[asmi]

Need to be careful about the LVDS output.  If we want the 'TRUE' 740/840mbps, we need to choose dedicated LVDS TX pair channels and not the emulated ones which only achieve 640mbps.

Missed this part - what the hell is "emulated" LVDS and how it differs from "True"? No such thing on 7 series, all diff pairs there are the same

[BrianHG]

Need to be careful about the LVDS output.  If we want the 'TRUE' 740/840mbps, we need to choose dedicated LVDS TX pair channels and not the emulated ones which only achieve 640mbps.

Missed this part - what the hell is "emulated" LVDS and how it differs from "True"? No such thing on 7 series, all diff pairs there are the same

The difference is in each IO bank, there are 16 IOs total, 4 pairs true TX differential pairs and 4 true RX pairs.  Use these pairs as as pairs and you get 840mbps with 160ps output jitter on the TX.  Use any other IO combinations as your transmitter or receiver and you get 640mbps with 160ps jitter.  Use any IOs you like as an emulated differential receiver or transmitter pair, the jitter jumps to 360ps.

Which pairs are which is located in the pinout files I listed above, but, not in the schematics where we have just an ##p & ##n shown on the FPGA symbol.

We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX.  So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.
 

[nockieboy]

We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX.  So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.

Is this a booboo I need to (or it would benefit from being) correct before I submit the PCB design?

[asmi]

The difference is in each IO bank, there are 16 IOs total, 4 pairs true TX differential pairs and 4 true RX pairs.  Use these pairs as as pairs and you get 840mbps with 160ps output jitter on the TX.  Use any other IO combinations as your transmitter or receiver and you get 640mbps with 160ps jitter.  Use any IOs you like as an emulated differential receiver or transmitter pair, the jitter jumps to 360ps.

Which pairs are which is located in the pinout files I listed above, but, not in the schematics where we have just an ##p & ##n shown on the FPGA symbol.

We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX.  So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.

Oh wow - didn't even know that is a thing. No such nonsense in 7 series. All 24 diff pairs in the IO bank (50 pins total per bank, 2 pins per bank are non-differential) are the same and can reach max datasheet speed (and even higher as experience shows).

[BrianHG]

We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX.  So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.

Is this a booboo I need to (or it would benefit from being) correct before I submit the PCB design?

     The pins we chose have a 640mbps limit.  However, they should still work, just that we cannot guarantee 720p/1080p with those pins, just 1024x768 max.

If you want true 840mbps, the only IO pins available on the 144pin package are:
85p,84n
87p,86n
99p,98n
103p,101n
(All available on P3)

However, using P3 means removing U8 and R30 thru R33 from the dev-board.
These traces are long, unbalanced and traverse throughout the eval PCB unlike our current IO port which just goes to that ram chip just below.

I say stick with what we have and just test up to 1024x768.
The IOs we will choose on the real CV board will support 840mbsp, IE 720p/1080p@30hz.
This doesn't mean we wont try overclocking the current test board to 720p anyways...

[BrianHG]

The difference is in each IO bank, there are 16 IOs total, 4 pairs true TX differential pairs and 4 true RX pairs.  Use these pairs as as pairs and you get 840mbps with 160ps output jitter on the TX.  Use any other IO combinations as your transmitter or receiver and you get 640mbps with 160ps jitter.  Use any IOs you like as an emulated differential receiver or transmitter pair, the jitter jumps to 360ps.

Which pairs are which is located in the pinout files I listed above, but, not in the schematics where we have just an ##p & ##n shown on the FPGA symbol.

We made a booboo on the chosen LVDS drivers for the HDMI board as 1 of the 4 pairs chosen was a RX pair instead of TX.  So, Quartus is telling me that our limit is 640mbps for 1 pair and I thought it was a limit of the C4, not that the pair I chose was faster at RX instead of TX if we used the next adjacent pair.

Oh wow - didn't even know that is a thing. No such nonsense in 7 series. All 24 diff pairs in the IO bank (50 pins total per bank, 2 pins per bank are non-differential) are the same and can reach max datasheet speed (and even higher as experience shows).

Nope. I was wrong.  It doesn't seem to care.  I placed 840mbps on tx & rx alike on different banks & the CV says it will run fine from 872mbps to 1092.9mbps depending on IOs chosen.  I wonder why they call them differential RX&TX in the pinout sheet.  Maybe there is something to do with they may be grouped into PLL channels/assignments.  I guess it makes no difference if you are not clocking in from an external source.  (FMAX gets worse if I place 1 transmitter pair on each corner of the FPGA, it's at it's best if all 4 are inside 1 IO bank, or 2 adjacent banks with all the IO at the edge of the FPGA.)

Note that this is different than when compiling with C4, it does hit a hard wall limit of 640 for the top and bottom IO banks, and for the left and right side, it's the 840 limit.

[BrianHG]

Addition to the above.  With the IOs set to DIFF-SSTL-Class I&II, any n&p IO pair can achieve 840 megabit, but you need the 2 resistor terminator.  When set to LVDS mode, IE 1 single terminator resistor across the n&p output, with AC coupled capacitor support, then the n&p IOs with the 'TX' need to be used for transmitters and the n&p IOs with the 'RX' need to be used for receive.  Note this means the FPGA uses an on-die termination resistor which you can software set to a few values.

So, if you want to use an TX n&p pair as an LVDS RX channel, you can set it to DIFF-SSTL-Class I&II and place a termination 50/100 ohm resistor on your PCB.

The TX io pairs have programmable series resistors for each output pin.
The RX io pairs have programmable parallel resistors between the n&p input lines.
The advantage of using the LVDS & similar buffer settings is traces from point A to point B, no PCB level termination resistors between FPGAs.

[nockieboy]

Parts and PCBs are now on order.

While I'm waiting for the PCBs to be delivered, I guess I should head back and finish that HDL ellipse function.

[BrianHG]

Parts and PCBs are now on order.

While I'm waiting for the PCBs to be delivered, I guess I should head back and finish that HDL ellipse function.

Ok, you need to change 1 thing in the current basic code.  Right now it makes an ellipse inside a box coordinates.
You need to change it so it makes an ellipse from a 'center x,y' coordinate and an 'x,y radius'.
Then it will be ready to convert to HDL.

[asmi]

While I'm waiting for the PCBs to be delivered, I guess I should head back and finish that HDL ellipse function.

Since you guys seems to be dead set on Cyclone V, you can also start working on DDR3 interface schematics and layout

[BrianHG]

While I'm waiting for the PCBs to be delivered, I guess I should head back and finish that HDL ellipse function.

Since you guys seems to be dead set on Cyclone V, you can also start working on DDR3 interface schematics and layout

Nockieboy needs to create a project with his chosen FPGA and place in a configured DDR3 controller with dummy controls and a DVI serializer with 2 configured PLLs.  Set/wire the IOs pins and compile.  The compiler will then tell him if everything is AOK...  He cannot complete this PCB without doing so.

But before that, before entering the DDR3 controller, he need to read it's documentation and see what features and configuration he will want to use.  He also needs to decide whether to tie everything together to the existing GPU via block diagram, or go 100% HDL and drop the block diagram entry he has been using to date and write modules merging his existing HDL cores.