Author Topic: FPGA VGA Controller for 8-bit computer  (Read 416336 times)

0 Members and 3 Guests are viewing this topic.

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1075 on: June 24, 2020, 02:43:49 pm »
My second video board is up and running with 10 MAGGIEs currently, no dead IOs found so far, nice clean grey scale bar show all RGB outputs are working:



The picture isn't great - my phone has a potato camera - but all 15 shades are visible (there's two blacks).  Working on the PS/2 interface now.
 
The following users thanked this post: BrianHG

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1076 on: June 25, 2020, 01:39:14 pm »
Okay, more of a general electronics question now.

I've noticed that the 1.2V regulator (AMS1117-1.2) is getting very hot - around 60 degrees Celsius (140 degrees Fahrenheit) which I'm attributing to that fact it's running from a 5V source rather than the amount of current being drawn by the FPGA (it's all running fine from a USB cable).

I've been working on a v.2 board design for a little while, incorporating improvements to the power routing (widening traces where possible) and so on and I've changed the power to the AMS1117-1.2 from 5V to the 3.3V source,  believing (rightly or wrongly - let me know!) that dropping from 3.3V to 1.2V should create less thermal load than from 5V.

Is that right?  Will I have other problems (not enough power in the 1.2V rail, for example) though if I do this?
 

Offline JagV12

  • Contributor
  • Posts: 25
  • Country: fr
Re: FPGA VGA Controller for 8-bit computer
« Reply #1077 on: June 25, 2020, 01:55:27 pm »
AMS1117 is a 'linear voltage regulator' which means that its power dissipation is (Vin - Vout)*Iin. So, the lower the input voltage, the better as long as drop out voltage is above 1.3V. This means the minimum input voltage should be 2.5V for a 1.2V regulator. 3.3V should then be OK
 
The following users thanked this post: nockieboy

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1078 on: June 25, 2020, 02:17:03 pm »
Or do it the proper way - replace linear regulator with switched-mode buck converter.

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1079 on: June 25, 2020, 04:33:09 pm »
Or do it the proper way - replace linear regulator with switched-mode buck converter.
Right now, lowering the regulator's source to 3.3v will be borderline for your EP4CE10E22C8N.  If you spend the 1$ extra and go to the larger EP4CE15E22C8N (Yes, there is a 1 dollar price difference to get 50% more logic gates), you will need to go to the switched-mode buck converter as the larger core draws will draw more current as soon as you increase the 10 maggie layers in Quartus to 15 layers.

Make sure the regulator is set to 1.2v out.  Using it you default 1.3v causes an excessive amount of current draw from the Cyclone core.
« Last Edit: June 25, 2020, 04:34:58 pm by BrianHG »
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1080 on: June 25, 2020, 04:54:30 pm »
Right now, lowering the regulator's source to 3.3v will be borderline for your EP4CE10E22C8N.  If you spend the 1$ extra and go to the larger EP4CE15E22C8N (Yes, there is a 1 dollar price difference to get 50% more logic gates), you will need to go to the switched-mode buck converter as the larger core draws will draw more current as soon as you increase the 10 maggie layers in Quartus to 15 layers.

Hmm.. the only issue with the EP4CE15 is that it doesn't have the required IO pins for my project (it drops from 91 to 81 IO pins).  To use a more powerful FPGA I'll need to switch to a BGA package as we've been discussing recently, in which case I'm looking to go to the EP4CE22 which has an increase in RAM as well and will require a complete redesign of the PCB.  I'm in the initial stages of creating the schematic for it, but I'm all ears for suggestions on how to improve any aspect of the design, including the power supply.  So switch-mode buck converters on the 1.2V AND 2.5V?  Will I need to beef up the 3.3V supply too or is that just used for the IO?

Make sure the regulator is set to 1.2v out.  Using it you default 1.3v causes an excessive amount of current draw from the Cyclone core.

My first video card had the regulator set to 1.3V, but I've since changed it to 1.2V and the second video card is a straight 1.2V regulator.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1081 on: June 25, 2020, 05:30:29 pm »
Right now, lowering the regulator's source to 3.3v will be borderline for your EP4CE10E22C8N.  If you spend the 1$ extra and go to the larger EP4CE15E22C8N (Yes, there is a 1 dollar price difference to get 50% more logic gates), you will need to go to the switched-mode buck converter as the larger core draws will draw more current as soon as you increase the 10 maggie layers in Quartus to 15 layers.
The thing to watch out for with bucks is Vout ripple. I skimmed through Cyclone IV datasheet but couldn't find any specs for it. For reference Spartan-7/Artix-7 have requirement of <50 mVpp @20MHz BW, which is very generous and is rather easy to achieve with multiple MLCC caps at the output. Most modern-ish buck ICs are designed to work with MLCCs (which are unique due to their ultra-low ESR), but some older devices will be unstable.
As for specific devices, my favorite low-ish current buck is TLV62130, which accepts up to 17 V (so I can use 9-12-15 V walwarts, which I'm sure we all accumulated aplienty of from all kinds of electronic devices bought over years), is fairly cheap and can output up to 3 A of current. Right now I'm evaluating AOZ2151 IC, which accepts up to 28 V (so I can use up to 20 V rail coming from USB-C PD directly), provides up to 4 A of current, and is more precise (1.5% over PVT vs 2.5% for TLV62130), while still being cheap. Both are available in QFN-ish packages, and so ground plane can be used as heatsink (super important when you have several such devices close by, as they collectively can generate quite a bit of heat).

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1082 on: June 25, 2020, 06:31:23 pm »
The thing to watch out for with bucks is Vout ripple. I skimmed through Cyclone IV datasheet but couldn't find any specs for it. For reference Spartan-7/Artix-7 have requirement of <50 mVpp @20MHz BW, which is very generous and is rather easy to achieve with multiple MLCC caps at the output. Most modern-ish buck ICs are designed to work with MLCCs (which are unique due to their ultra-low ESR), but some older devices will be unstable.
As for specific devices, my favorite low-ish current buck is TLV62130, which accepts up to 17 V (so I can use 9-12-15 V walwarts, which I'm sure we all accumulated aplienty of from all kinds of electronic devices bought over years), is fairly cheap and can output up to 3 A of current. Right now I'm evaluating AOZ2151 IC, which accepts up to 28 V (so I can use up to 20 V rail coming from USB-C PD directly), provides up to 4 A of current, and is more precise (1.5% over PVT vs 2.5% for TLV62130), while still being cheap. Both are available in QFN-ish packages, and so ground plane can be used as heatsink (super important when you have several such devices close by, as they collectively can generate quite a bit of heat).

Okay, so it looks like I'm going to have to review my power supply if I'm going to go to a larger BGA FPGA.

My system has a 5V primary power rail powering everything, which is sourced from either the USB cable providing the serial connection with my desktop PC or a wall-wart DC input via a 7805.  An AMS1117 provides the 3.3V rail from the 5V supply.  The system as a whole currently pulls about 0.04A according to an imprecise USB voltage measuring tool I've just tried on it.

I based the FPGA design on a schematic for the dev board I was using to prototype the video card - so the power rails are identical to the ones in my dev board.  I've hunted down a schematic for a dev board using the EP4CE22F17 as well (the DE0-Nano) and was intending to use that as a reference when designing the supporting circuits and power supplies.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1083 on: June 25, 2020, 07:10:47 pm »
I based the FPGA design on a schematic for the dev board I was using to prototype the video card - so the power rails are identical to the ones in my dev board.  I've hunted down a schematic for a dev board using the EP4CE22F17 as well (the DE0-Nano) and was intending to use that as a reference when designing the supporting circuits and power supplies.
That schematics has 1.5 A LDO for the Vccint rail :palm:
See attachment for the schematic of the buck that you need (taken straight out of device datasheet). As you can see, there are only 3 extra components compared to typical LDO implementation - one 3.3 nF cap to set up soft start (can be omitted if you don't particularly care about slowing down startup), 100K resistor for "power good" signal (again optional, can leave unconnected if you aren't going to use this signal) and inductor, so really only inductor is mandatory. Everything else (input/output caps, Vout setting resistor divider) is the same for buck and LDO. This circuit will give you 90+% efficiency almost across entire range output current when powered by 5 V, and so it probably won't be even warm at full 3 A current.
« Last Edit: June 25, 2020, 07:15:25 pm by asmi »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1084 on: June 25, 2020, 07:28:08 pm »
If you are going BGA, maybe taking a look at the Lattice 15$ fpga with 2 megabits ram may be useful.

I would also add 2x of the 'S70KS1281DPBHV020' 16 megabyte ram chips, each on their own 10/11 wire buss while only sharing their differential PLL clock outputs.  This would allow 2 separate banks of operation.  Though, you will need to wire 1 IO bank at 1.8v to get the full 250MHz speed of your core PLL clock.

At 2.15$ a chip, not as cheap as strict DDR ram, but it has a built in ram controller.  And Maggie can only address 16 megabytes anyways, maybe 32 megabytes with some modding.

Unfortunately, the good price of the 'S70KS1281DPBHV020'  is like that because it is being discontinued.  You need to go with the smaller 8 megabyte newer 'S27KS0642GABHI030' at 4.35$.  You need to wire 2 of them on 1 bus with separate CS# to match the S70K....  But in this configuration, during the 'additional latency', if setup properly, you can run 2 of these in a dual bank mode.

These are normal DDR2 rams and are much more available and cheaper per MB, but you need a DDR2 controller:
W9725G6KB-25
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1085 on: June 25, 2020, 10:37:12 pm »
Look at what I found, DIY reballing.  You will need a dummy stencil for reballing, solder paste & a hot air gun, bu here is someone doing it: (Begins at 5:45) (IE, you can now remove and re-position/mount a failed mounted BGA IC again and again.)



Since these stencils are cheap, then it is worth it if you have everything else:
Reballing Stencil
« Last Edit: June 25, 2020, 11:23:06 pm by BrianHG »
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1086 on: June 26, 2020, 01:27:49 am »
Look at what I found, DIY reballing.  You will need a dummy stencil for reballing, solder paste & a hot air gun, bu here is someone doing it: (Begins at 5:45) (IE, you can now remove and re-position/mount a failed mounted BGA IC again and again.)
I've been working with BGAs for over 3 years now, and I have never had a soldering issue, and so never had to reball anything. But I only use chips purchased via official channels, so I'm not sure how things would go if I were to buy them off aliexpress et al.

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1087 on: June 26, 2020, 02:06:54 am »
If you are going BGA, maybe taking a look at the Lattice 15$ fpga with 2 megabits ram may be useful.
Lattice devices suck in a sense that they usually come in small pitch packages. And zero free IPs - you're on your own. If he changes vendor, he might as well go Xilinx as they are the best anyways.

I would also add 2x of the 'S70KS1281DPBHV020' 16 megabyte ram chips, each on their own 10/11 wire buss while only sharing their differential PLL clock outputs.  This would allow 2 separate banks of operation.  Though, you will need to wire 1 IO bank at 1.8v to get the full 250MHz speed of your core PLL clock.

Unfortunately, the good price of the 'S70KS1281DPBHV020'  is like that because it is being discontinued.  You need to go with the smaller 8 megabyte newer 'S27KS0642GABHI030' at 4.35$.  You need to wire 2 of them on 1 bus with separate CS# to match the S70K....  But in this configuration, during the 'additional latency', if setup properly, you can run 2 of these in a dual bank mode.
You need to use 1.8 V Vccio and differential clock to get 166 MHz (or 200 MHz on newest HyperRAM 2 devices), at 3 V they only go up to 100 MHz. But the interface is DDR, so you get two transfers per clock. One thing that suck abouts them (aside from smallish capacity of only 8 Mbytes per die) is the latency is rather high, especially for dual-die ones (S70 series), so you will need to make sure your application takes advantage of their long burst ability in order to amortize initial latency. I actually have a simple FPGA devboard with a couple of these memory chips in parallel (this was my very first Xilinx FPGA devboard BTW!), and I found that single-die devices can work with singular latency most of the time, which is good if your access pattern is more random and you don't want to completely pipeline memory access for double-latency. Cool thing about using static double-latency though is that it allows to easily place multiple memory devices in parallel and get double (or more) bandwidth this way.

These are normal DDR2 rams and are much more available and cheaper per MB, but you need a DDR2 controller:
W9725G6KB-25
Again, the question here is of tradeoff between simplicity, capacity and bandwidth. If you need capacity and bandwidth, you need to use DDR3(L) memory because they provide highest capacity and bandwidth for price (MT41J128M16JT-125 is about 4.5$ and has capacity of 256 MBytes with 16bit data bus running up to 800 MHz!).
If he only needs like 1 Mbytes or less, I'd use regular SRAM as it's the simplest solution in terms of controller implementation, as well as it provides the smallest latency possible, so it's the best for truly random access.
As a middle ground, I would recommend looking at SDRAM or LPDDR1 modules - they provide between 16 and 256 MBytes of capacity, while still having rather small access latency. Also - Micron provides free simulation models for all of it's memory modules (from SDRAM all the way to DDR4), so designing controller is much easier because you can actually run full end-to-end simulations to check that controller works like it should. And these models are provides in full source code, so you can figure out some finer points in modules functionality in case datasheet is unclear on something.

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1088 on: June 26, 2020, 09:06:55 am »
Look at what I found, DIY reballing.  You will need a dummy stencil for reballing, solder paste & a hot air gun, bu here is someone doing it: (Begins at 5:45) (IE, you can now remove and re-position/mount a failed mounted BGA IC again and again.)

Good find.  :-+  That makes me more confident in giving it a try - if I do mess up for whatever reason, it isn't a complete lost cause and I could recover the BGA to try again. Nice.  :)

If you are going BGA, maybe taking a look at the Lattice 15$ fpga with 2 megabits ram may be useful.

I seem to recall us talking about the Lattice recently and discovering there could be licensing issues?  $99 a year for the IDE is beyond my meagre hobby budget.  If we're going the route of external RAM though, the internal RAM (or lack of) won't be an issue.

I would also add 2x of the 'S70KS1281DPBHV020' 16 megabyte ram chips, each on their own 10/11 wire buss while only sharing their differential PLL clock outputs.  This would allow 2 separate banks of operation.  Though, you will need to wire 1 IO bank at 1.8v to get the full 250MHz speed of your core PLL clock.

At 2.15$ a chip, not as cheap as strict DDR ram, but it has a built in ram controller.  And Maggie can only address 16 megabytes anyways, maybe 32 megabytes with some modding.

Unfortunately, the good price of the 'S70KS1281DPBHV020'  is like that because it is being discontinued.  You need to go with the smaller 8 megabyte newer 'S27KS0642GABHI030' at 4.35$.  You need to wire 2 of them on 1 bus with separate CS# to match the S70K....  But in this configuration, during the 'additional latency', if setup properly, you can run 2 of these in a dual bank mode.

These are normal DDR2 rams and are much more available and cheaper per MB, but you need a DDR2 controller:
W9725G6KB-25

Okay, well moving to BGA does mean I can add some external memory which is a big bonus (even if it's just SDRAM) - I'm assuming then that all the video RAM could be moved out to the external memory and there'd no longer be an issue with the limited size of RAM inside the FPGA?  Didn't you mention there'd be speed issues / complexity in the interface previously?

Remember that I don't need masses of RAM.  I'd be perfectly happy with 512 KB to fill the hole in the system memory that the FPGA creates, but I understand that with extra MBs I could get higher screen resolutions?  There's also the potential to build the MMU into the FPGA and remove the need for a memory card in my system altogether - all the system RAM could be hosted on the FPGA card.

The other proviso with all this is that I haven't a clue what I'm doing.  I've gotten this far on the goodwill of this forum and masses of support from BrianHG, but this next step to BGA and using external SDRAM/DDR/whatever seems like a pretty big step for me (though I'm sure it's dead easy for you guys experienced with this stuff) and I'd need guidance and instruction to get it right (esp. with the HDL).  I don't want to make a nuisance of myself.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1089 on: June 26, 2020, 02:30:44 pm »
DRAM consists of two-dimensional arrays of very small capacitors. The capacitors are feeble, and need lots of special care.

Reading is done one row at a time. The row is read from the matrix into a buffer. The capacitors are so small that the read destroys the charges and memory is lost. Therefore, it is necessary to write the buffer back, even if its content doesn't change. The reading process is called "Activation". Write back is called "Precharge".

Now imagine you want to read something, but a different row is activated. This row now has to be precharged, new row activated and then your read performed. This produces substantial latency. So, truly random access is not very fast.

Worse yet, the capacitors lose charge over time. The content of a capacitor survives only tens of ms. Therefore, you must activate every row and discharge it every so often, or you'll lose the memory. This is called "Refresh". The memory chip may keep track of refreshes and maintain the counter which row must be refreshed next, so you only need to sent it a refresh commands every so often and it will refresh a rows at a time. The chip automatically cycles through all the rows making sure all are refreshed. With others, you may need to supply the address of the row being refreshed. If you suddenly decide to read something during refresh, your latency suffers - you now need to want until the end of refresh, then activate your row, then read. If you activate each and every row regularly (as may be the case with video buffer), you do not need refreshes.

The memory consists of one or more banks, each with its own memory array and IO buffer, all connected in parallel. You need to select which bank you read/write, but the operations which do not need IO (such as activations, precharges, and refreshes) can be done by every bank independently. Your controller must take care of every bank. All this requires certain complexity in the controller. Your choice is to either use a stock controller or write your own which is designed specifically for video buffer.

Or, you can take SRAM, which doesn't require any of that and has fixed latency (around 10 ns). The problem is it's many times more expensive than DRAM.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1090 on: June 26, 2020, 04:33:58 pm »
Okay, well moving to BGA does mean I can add some external memory which is a big bonus (even if it's just SDRAM) - I'm assuming then that all the video RAM could be moved out to the external memory and there'd no longer be an issue with the limited size of RAM inside the FPGA?  Didn't you mention there'd be speed issues / complexity in the interface previously?

Remember that I don't need masses of RAM.  I'd be perfectly happy with 512 KB to fill the hole in the system memory that the FPGA creates, but I understand that with extra MBs I could get higher screen resolutions?  There's also the potential to build the MMU into the FPGA and remove the need for a memory card in my system altogether - all the system RAM could be hosted on the FPGA card.

The other proviso with all this is that I haven't a clue what I'm doing.  I've gotten this far on the goodwill of this forum and masses of support from BrianHG, but this next step to BGA and using external SDRAM/DDR/whatever seems like a pretty big step for me (though I'm sure it's dead easy for you guys experienced with this stuff) and I'd need guidance and instruction to get it right (esp. with the HDL).  I don't want to make a nuisance of myself.

8 or 16 bit SDRAM and DDR1/2/3 Ram will be too slow for the MAGGIE system other than having 1-2 dumber linear MAGGIE background graphics layers.  All tile/font/sprite images will need to be stored in the FPGA + you will need an extra 1-2kb FPGA cache to stream the DRAM video.

To replace the core and storing everything in DRAM, you would need 1GHz 32bit DDR3 controller which is beyond the CycloneIV.  You would also have to use all of the core ram to create a smart read ahead cache since DDR ram reads bytes in bursts where you need only single bytes from.  The development cycle to accomplish this is beyond our time and scope.

Hence, with the DDR ram, you will only get 2 raster MAGGIE layers which may pass raster video through, or each feed 1 of the 15 core MAGGIE layers to address tiles/fonts/sprites stored in the core ram.  The other 50% access time of the DDR ram will be for the Z80 and pixel drawing engine.

Now, I say 16 megabytes since the address pointer in the MAGGIE is currently 24 bits, ie 16 megabyte pointer.  I do not know about the Z80 paging capabilities, but, if you are limited to 512kb, including graphics memory, there are other smaller 512kb static rams which are still 2-4$, but have much faster row access times which may have less of a driver interface issue and a smaller ras/cas penalties and no sequential burst requirements.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2728
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1091 on: June 26, 2020, 04:54:34 pm »
8 or 16 bit SDRAM and DDR1/2/3 Ram will be too slow for the MAGGIE system other than having 1-2 dumber linear MAGGIE background graphics layers.  All tile/font/sprite images will need to be stored in the FPGA + you will need an extra 1-2kb FPGA cache to stream the DRAM video.

To replace the core and storing everything in DRAM, you would need 1GHz 32bit DDR3 controller which is beyond the CycloneIV.  You would also have to use all of the core ram to create a smart read ahead cache since DDR ram reads bytes in bursts where you need only single bytes from.  The development cycle to accomplish this is beyond our time and scope.
You've got to be kidding! 16 bit DDR3 even running at 400 MHz gives you enough bandwidth to stream and double-buffer (meaning you read and write in parallel) a 1080p/32bpp/60Hz video stream in real time with some bandwidth to spare! And this video card has a resolution of what? 640x480/8bpp/60Hz? You should be able to push at least 50 these streams in parallel with no problems whatsoever!

But if you for some bizzare reason need more, what stops you from implementing wider bus, up to 64bit SODIMM?

Something doesn't sound right here.
« Last Edit: June 26, 2020, 05:05:22 pm by asmi »
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1092 on: June 26, 2020, 06:05:16 pm »
8 or 16 bit SDRAM and DDR1/2/3 Ram will be too slow for the MAGGIE system other than having 1-2 dumber linear MAGGIE background graphics layers.  All tile/font/sprite images will need to be stored in the FPGA + you will need an extra 1-2kb FPGA cache to stream the DRAM video.

To replace the core and storing everything in DRAM, you would need 1GHz 32bit DDR3 controller which is beyond the CycloneIV.  You would also have to use all of the core ram to create a smart read ahead cache since DDR ram reads bytes in bursts where you need only single bytes from.  The development cycle to accomplish this is beyond our time and scope.
You've got to be kidding! 16 bit DDR3 running at 400 MHz gives you enough bandwidth to stream and double-buffer (meaning you read and write in parallel) a 1080p/32bpp/60Hz video stream in real time with some bandwidth to spare! And this video card has a resolution of what? 640x480/8bpp/60Hz? You should be able to push at least 50 these streams in parallel with no problems whatsoever!

But if you for some bizzare reason need more, what stops you from implementing wider bus, up to 64bit SODIMM?

Something doesn't sound right here.
Your figures are correct for 'bandwidth to stream' IE sequential burst-efficient access, 2 pictures simultaneously...

   You haven't followed the project, the MAGGIE system has 16 translucent video window layers (16 pictures), 16 bits each, at 25 million pixels a second.  HOWEVER, each MAGGIE layer can tell the next adjacent MAGGIE layer to address individual 16 bit pixels from anywhere else in ram on a pixel/pixel basis, no sequential multiple pixel reads, hence the realtime pixel zooming and skipping feature.

   All this means is that exactly like a said, running a single 125MHz or 250MHz DDR2/3 ram chip at 16 bits.  Since you cannot address single bytes/words and have those redirect to a point elsewhere in ram without waiting for a ras/cas/4-8 clk burst/terminate cycle, all being said and done, an over 35ns turnaround for each random byte access, you cannot achieve the 25MHz pixel speed * 15 pixels which sit on-top of each pixel, each which may randomly point to anywhere else in ram for an associated font/tile which can be also 16bits/pixel or pointer to another font/tile.

   However, just having 2 sequential 16bit/pixel raster layers with a small pixel cache is doable with a simple ram controller, + having another graphics geometry engine random read/write access port plus another port with 0 (ZERO) wait state at Z80 speed weaved in will be feasible with some simple HDL code.

Squeezing out the Drams approximate full 750MB/sec is doable with 16 random access ports, only half of them somewhat sequential can be done, all read ahead in time to generate each 16 layer finished pixel, however I want nockieboy to be able to finish the project.

Now, if 512kb is a limit on the Z80, maybe nockieboy should consider ZBT-SRAM.  It has access exactly like a static ram chip, but when swapping from reading to writing and back, the ram chip will have 0 wait states, or Zero Bus Turnaround.  A 250Mhz ZBT sram, 256K x 18bit (512 kilobytes).  The ram controller HDL code is non-existent other than a latch and IO pins set to the tightest timing tolerances.  Now the memory density is less, but it will perform almost identical to a core signle-port ram operating at 250MHz and 0 coding experience is needed.

For some reason, the 256kx18bit 200MHz is a cheap sweet spot for ZBT ram at 2$ each (maybe obsolete).
ZBT 250Mhz = $8.40.
Sync SRAM 250MHz = $5.53.  I need to read more on this as the interface is a little more complex as the first read/write can take 2 cycles.


I would say if the Z80 can access more than 2 megabytes, go for a single 16bit ddr ram chip.  If it can only access 512kb, a more expensive but more HDL friendly solution would be the ZBT ram.
« Last Edit: June 26, 2020, 06:11:30 pm by BrianHG »
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1093 on: June 26, 2020, 07:54:13 pm »
Now, if 512kb is a limit on the Z80, maybe nockieboy should consider ZBT-SRAM.  It has access exactly like a static ram chip, but when swapping from reading to writing and back, the ram chip will have 0 wait states, or Zero Bus Turnaround.

Aren't all asynchronous SRAM chips like that?
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1094 on: June 26, 2020, 08:12:26 pm »
I would say if the Z80 can access more than 2 megabytes, go for a single 16bit ddr ram chip.  If it can only access 512kb, a more expensive but more HDL friendly solution would be the ZBT ram.

My Z80 system can address 4 MB of memory (in 16 KB banks) with the current MMU I have.  As luck would have it, that equates to 8 sockets on two memory PCBs (with each taking up to a maximum 512 KB chip).  The second PCB is optional, so with one PCB you've got 2 MB.  For sheer ease of interfacing the FPGA to the Z80's memory space, it inserts its core memory into the 512 KB 'window' that the 3rd socket would otherwise occupy (the first having to be RAM and the fourth needing to be the ROM OS).  So if I have a video card on the system, the 3rd memory socket has to be empty.  Currently, in place of the 512 KB of memory that could have been a chip in the 3rd socket, instead it is the 32 KB of core RAM the FPGA makes accessible to the Z80.



There's nothing stopping me using a 16 MB chip on the video card and allowing the FPGA to handle memory management and give the Z80 access to all of that RAM.  I've just been talking about 512 KB not as a hard limit, but merely to make up the 512 KB that could have been in the 3rd socket instead of the FPGA.  All RAM on the system is SRAM and I've got no objection to using SRAM on the FPGA instead of DRAM, considering its benefits with this design's random memory access characteristics.
« Last Edit: June 26, 2020, 08:15:14 pm by nockieboy »
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1095 on: June 26, 2020, 09:12:41 pm »
There's nothing stopping me using a 16 MB chip on the video card and allowing the FPGA to handle memory management and give the Z80 access to all of that RAM.  I've just been talking about 512 KB not as a hard limit, but merely to make up the 512 KB that could have been in the 3rd socket instead of the FPGA.  All RAM on the system is SRAM and I've got no objection to using SRAM on the FPGA instead of DRAM, considering its benefits with this design's random memory access characteristics.

16MB SRAM would be more expensive. The cheapest I can see on DigiKey (2 x 64Mb chips) is $40. That is compared to $2 for a DRAM chip.
 

Offline BrianHG

  • Super Contributor
  • ***
  • Posts: 7660
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1096 on: June 26, 2020, 09:35:04 pm »
Now, if 512kb is a limit on the Z80, maybe nockieboy should consider ZBT-SRAM.  It has access exactly like a static ram chip, but when swapping from reading to writing and back, the ram chip will have 0 wait states, or Zero Bus Turnaround.

Aren't all asynchronous SRAM chips like that?
SRAM and Synchronous SRAM are 2 different things.  Pure SRAM, IE no clock interface, comes in a number of sizes and speeds, like 70ns, 35ns, 15ns... As the speed goes up, the price and size increases.

The Synchronous SRAM comes in 2 variants, the normal and ZBT.  These rams have a clock and cleanly latch the address and data on the rising edge, or for the data, on both clock edges for the DDR variant.  The advantage of the Synchronous types is clocks up to 250 MHz for SDR, 400MHz DDR (800MHz data), and a cheaper price or larger size.  The non ZBT variant relies on 1 additional clock cycle when switching from a read to a write as the latched 'Write Enable' control which is clocked requires that 1 additional clock for the data line drivers to switch direction.

(Now we are talking only 1 chip, 512 kilobytes, his Z80's memory window size.  If nockieboy wants more ram, he'll go with DDR Ram)

Example:
https://www.rocelec.com/part/IDTIDT71V3558S200PFG?utm_medium=buyNow&utm_source=findChips
200MHz sync ZBT SRAM - 71V3558S200 datasheet - https://www.idt.com/document/dst/71v3556-58ssa-data-sheet
(This one operates identically to a Quartus Memory IP block, but, external as it has a fixed pipeline delay of 2.  Since writes are also on a delayed pipeline of 2, there is no turn-around time for switching between write and read on the command input as 2 clocks later, you would have the IO direction swap & write data ready to go inside the FPGA.)

https://www.arrow.com/en/products/is61nlp25618a-200tqli/integrated-silicon-solution-inc?utm_term=backorder&utm_campaign=arrow_findchips_2019&utm_currency=&utm_medium=aggregator&utm_source=findchips&utm_content=inv_listing
200MHz sync SRAM - IS61NLP25618A-200TQLI datasheet http://www.issi.com/WW/pdf/61-64LPS_VPS12832EC-12836EC-25618EC.pdf
(This one when sending a write, the write data is taken immediately.  But when reading, the read comes in on the next clock.  So, when switching from the previous read, then going to a write, you need to wait that additional clock for the last read to be returned to you before swapping the IO direction to make an immediate write.  ZBT type sram doesn't have this issue and is easy-peasy to interface with as yo never need to add that 1 clock delay/pause.)

Normal SRAM, well, $1.20 for 256Kx16/18, but, 10ns access time.  And there are still write penalties in the timing diagrams as some models have a 15-20ns write cycle time while still claiming 10ns access.  You would want the 10 write cycle, 10ns access version for full 100MHz support.
(This one is simple, but, too slow operating at half speed, or even less.  But, it's great for battery retention memory.)
« Last Edit: June 26, 2020, 10:20:26 pm by BrianHG »
 

Offline gcewing

  • Regular Contributor
  • *
  • Posts: 197
  • Country: nz
Re: FPGA VGA Controller for 8-bit computer
« Reply #1097 on: June 27, 2020, 12:32:00 am »
Write back is called "Precharge".
That's not quite right -- "precharge" refers to charging the bit lines coming in to the sense amplifiers up to 1/2 Vcc in preparation for reading a row. Writing back is called "refresh" (and kind of happens as a side effect of reading -- this Wikipedia article explains it quite well: https://en.wikipedia.org/wiki/Dynamic_random-access_memory).
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: FPGA VGA Controller for 8-bit computer
« Reply #1098 on: June 27, 2020, 01:08:24 am »
Write back is called "Precharge".
That's not quite right -- "precharge" refers to charging the bit lines coming in to the sense amplifiers up to 1/2 Vcc in preparation for reading a row. Writing back is called "refresh" (and kind of happens as a side effect of reading -- this Wikipedia article explains it quite well: https://en.wikipedia.org/wiki/Dynamic_random-access_memory).

This makes sense. I always wondered why such a strange choice of the word.

At any rate, from the controller viewpoint, you activate the row, work with it, then when you're done you issue the precharge command, at which point your data are written back and the row is deactivated. Apparently it also precharges amplifiers. Between activate and precharge commands, you can exchange the data with the buffer - read or write. The refresh command refers to maintenance refreshes which must not happen between activate and precharge commands. These refreshes are reads followed by writes.
 

Offline nockieboyTopic starter

  • Super Contributor
  • ***
  • Posts: 1812
  • Country: england
Re: FPGA VGA Controller for 8-bit computer
« Reply #1099 on: June 28, 2020, 11:30:05 am »
Okay, I can work on the BGA design whilst I do other stuff - in the meantime, what to get started on next with the HDL side?  The graphics accelerator?  How is this going to work (in a mid-level overview sort of way)?

BrianHG mentioned previously a list of commands/functions that the module would perform and I have a basic checklist myself, like CIRCLE, LINE, FILL, etc and even perhaps basic sprite collision - how would this be implemented and where do I start?  :scared:
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf