FPGA VGA Controller for 8-bit computer

[asmi]

Okay, I'm going with the MT41J128M16JT DRAM.  Admittedly, for me it's almost a 'pin the tail on the parts list', as I don't really appreciate the nuances of the difference choices.  Just 'more RAM is good'.    Plus, if I have the IOs and can route a 16-bit DRAM up then that should be the goal, really.

I would suggest you to buy this 2Gbit part, but do the routing for the 4Gbit MT41K256M16 part. Their footprints are backwards-compatible (4G part has ball T7 for A14 line, while for 2G this ball is "no-connect"), so that in case you will want to upgrade to 512 Mbytes later on, you would be able to just drop 512 Mbytes part onto existing board and update your FPGA design.

Almost missed this, asmi.  Latest schematic attached.

I don't see anything obviously wrong, but let's wait for BrianHG's final word on this. I don't see a Shottky diode for backpowering protection and static discharge circuit for the connector's shroud, but this is probably fine for a proof-of-concept.
Oh - one thing - I don't know if you really want to bother with this, but HDMI specification demands that no damage should occur if you short any pins in any combination on the connector. In your case I only see a problem if 5V line is shorted to ground.

BTW I really like how you laid out those DC isolation caps and resistors for HDMI lanes. It's beautiful!

[BrianHG]

Found a mistake.  See item in red.  Your using pins 31,30 instead of 32,31.

Look at FPGA pins -> Header P2 pins: (use 4 adjacent pairs for the HDMI digital data)
38p/39n -> 38/37
49p/50n -> 32/31
52p/53n -> 29/28
54p/55n -> 27/26
59p/60n -> 24/23

[nockieboy]

I don't see a Shottky diode for backpowering protection and static discharge circuit for the connector's shroud, but this is probably fine for a proof-of-concept.

Soooo.... I'd need to connect a Schottky diode (would a BAT54S do?) to the 5V plane just back (left) from C12?

ESD protection for the shroud?  Will google this later.

Oh - one thing - I don't know if you really want to bother with this, but HDMI specification demands that no damage should occur if you short any pins in any combination on the connector. In your case I only see a problem if 5V line is shorted to ground.

Again, will have to google this later.

BTW I really like how you laid out those DC isolation caps and resistors for HDMI lanes. It's beautiful!

 

Found a mistake.  See item in red.  Your using pins 31,30 instead of 32,31.

D'oh!  Well spotted, BrianHG.  Fixed. 

[DiTBho]

I haven't got what is a Maggie. Is there any doc?

Can't you implement a simpler SDRAM controller rather than DDR3?

[asmi]

Soooo.... I'd need to connect a Schottky diode (would a BAT54S do?) to the 5V plane just back (left) from C12?

Please excuse my paint.net skills, but it's something like that.

[BrianHG]

I haven't got what is a Maggie. Is there any doc?

Can't you implement a simpler SDRAM controller rather than DDR3?

MAGGIE is our creation.  It stands for

This (multiple) address generator/graphics instruction engine (let's follow in the footsteps of the Amiga architects and call it MAGGIE).

It all began here 1 year ago: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2783972/#msg2783972

It is a part of this VGA controller which generate a display window.
Each 'MAGGIE' layer/display window can be any color bit depth, 1bit, 2bit, 4bit, 8bit, 16 bit color.
Each one can have separate horizontal and vertical pixel zoom sizes, window sizes, horizontal raster sizes (even values larger than the visible screen area), and can point anywhere within system memory.
Each one has a priority, IE 1 window sits on top of another with optional transparent pixels.
When using the 16bit ARGB (alpha blend mix value, R,G,B), a gradient transparency from 1 MAGGIE window layer to the next renders each pixel drawn using the alpha color value to render a true 24bit color blend selection of those 2 pixels color values.
Windows with less than 8bit 256 color can be assigned to different parts of the 2x 256 color palettes.  16bit mode is true-color mode which again can be set to 4444-ARGB color, or 565-RGB color.
The windows have active pixel collision detection.
And a MAGGIE layer can be set to tile/font mode where it's read data points to any other font/tile point in memory with that font being 8x8,8x16,16x8,16x16 pixels & the font/tile memory can also be 1bit, 2bit, 4bit ,8bit, 16 bit color.

Think of it as a hardware accelerated window system where we can display 15 windows simultaneously, each with different video modes & palettes all at once with different transparency features for overlays.

[BrianHG]

Work on MAGGIE began in earnest a month later here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2825238/#msg2825238

First MAGGIE window with bugs: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2827950/#msg2827950

First good MAGGIE window addressed to the 'Font' memory : https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2830236/#msg2830236

First multiple MAGGIES with different bitmaps, different color depths & different palettes: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2831296/#msg2831296

First MAGGIEs with addressed fonts/tile memory & different colors here: https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2843840/#msg2843840

MAGGIE complete : https://www.eevblog.com/forum/fpga/fpga-vga-controller-for-8-bit-computer/msg2849948/#msg2849948


Those were the days...

[asmi]

Can't you implement a simpler SDRAM controller rather than DDR3?

SDRAM will consume almost as many pins as DDR3 will, but will provide about 5 times less bandwidth (400 MHz DDR vs 166 MHz SDR), and several times less capacity for the price. Infact even a single 200 MHz HyperRAM module will outperform 16bit 166 MHz SDRAM. It makes no sense to use SDRAM anymore as HyperRAM controller is going to be simpler than SDRAM controller (because the former doesn't need to concern itself with timing refreshes, while the latter does).

[BrianHG]

Can't you implement a simpler SDRAM controller rather than DDR3?

SDRAM will consume almost as many pins as DDR3 will, but will provide about 5 times less bandwidth (400 MHz DDR vs 166 MHz SDR)

OMG, we really do need 4-5x that bandwidth.  Especially with 8-16 channel high fidelity audio combined with our current geometry unit which needs to be able to repaint a full screen of pixels 4-5x every 1/60th of a second if we want clean full screen geometry or blitter based animation.  (And not go any slower than the current internal FPGA ram...)

[DiTBho]

My MSO is only able to follow signals << 200Mhz. And that's my limit.

[DiTBho]

@BrianHG thank you for you fully detailed explanation

Thinking about the HDL code, from the simplest to the most difficult, I think I can order { SDRAM, HyperRAM, DDR3 }. That's the reason why I asked about SDRAM.

Here I really like to use old PC100 and PC133 ram-modules. I can dis-solder chips from there.

[BrianHG]

@BrianHG thank you for you fully detailed explanation

Thinking about the HDL code, from the simplest to the most difficult, I think I can order { SDRAM, HyperRAM, DDR3 }. That's the reason why I asked about SDRAM.

Here I really like to use old PC100 and PC133 ram-modules. I can dis-solder chips from there.

PC133 ram would work well as the core currently operates at 125/250MHz.  The code we will be generating would allow for any ram controller.  Having 16bit SDR 125MHz, with allowances for RAS/CAS precharge and say a CAS burst size or 16 words to match the DDR3 controller burst size, you can still run at least 1-2 MAGGIE window layers from that ram without impacting the performance anywhere else, including geo/blitter/SD-card/sound with 480p video.  You would still have access to another 15 MAGGIE windows from the core FPGA ram for sprites/multi-playfield windows.

Though, at 720p, 1 layer from the ram at 16bit color with some sacrifice if geometry/blitter performance.  At 8bit 256 color, everything should work fairly fast, maybe enough for hi-res audio as well.  The FPGA ram would shrink down to around 5 MAGGIE window layers.

Now, the geometry/blitter can still copy to and from fpga ram and external SDRAM.

Your SDRAM controller would need to support read & write with write-mask since we may be writing only particular 8 bit words within a 16 word x 16bit burst.

I'd still think about normal DDR ram running at 125MHz to double your data transfer to 250mtps.
Using old laptop SODIM DDR or PC DDR ram modules as a module might even be easier to use if 16bit varieties exist.

[asmi]

My MSO is only able to follow signals << 200Mhz. And that's my limit.

You don't need any oscilloscope to debug memory. If you did your layout right, and your controller is verified in simulation, it will guarantee correct operation.
Besides, at some point you will have to resort to using other debugging techniques than oscilloscope. Even 1080p@60 HDMI is 1450 Mbps per data lane, and I just can't afford a scope that can display such fast signals, not to mention 6 Gpbs for SATA3 for example. Thankfully, Xilinx thought about that and so they offer in-circuit debugging tools that can use the very FPGA you actually run your design on.

Thinking about the HDL code, from the simplest to the most difficult, I think I can order { SDRAM, HyperRAM, DDR3 }. That's the reason why I asked about SDRAM.

I disagree. As someone who actually implemented both HyperRAM and SDRAM controllers myself, I will say that HyperRAM is significantly simpler.
But the simplest option for me is DDR3 controller, because I don't have to design anything - I simply use the one provided by Xilinx for free.

Here I really like to use old PC100 and PC133 ram-modules. I can dis-solder chips from there.

That is way too of a stone age tech to me. Memory capacity typically isn't that big of a deal for my designs, but bandwidth is almost always a limiting factor. And here DDR3 wins big time over SDRAM, this is why I choose it for pretty much all my designs.

[asmi]

Using old laptop SODIM DDR or PC DDR ram modules as a module might even be easier to use if 16bit varieties exist.

SODIMM is always 64 bit (or 72 bit for ECC modules). There are few 32bit DDR3 SODIMM modules, but they are hard to find. Vast majority of modules you can actually buy are 64 bit.

[DiTBho]

Is it possible to have a dedicated small board for just the VideoRAM, and use it as a "synonymous blackbox attached via a high density a connector" in the final project?

This way, you can focus on the DRAM controller, use XILINX's IP or Altera's one, or even your own, and it  even offers the possibility to replace the module if it goes damaged or if you need one with more ram.

If it sounds reasonable, which datalink could be used?

A serial link similar to the hyper ram? Thus a kind of DDR3 controller that talks like an hyper ram module?

For me, such solution would be great and super nice, not only because you can recycle the VideoRam board for other projects without redesigning the whole board (I think the PCB for the VideoRam is critical), but also because it decouples the "implementation" from the project design, making the project more portable, more split-able in a team, and with more possibilities on the simulator side.

What do you think about?

[BrianHG]

My MSO is only able to follow signals << 200Mhz. And that's my limit.

You don't need any oscilloscope to debug memory. If you did your layout right, and your controller is verified in simulation, it will guarantee correct operation.

It took almost half a year to get Nockieboy to simulate-simulate-simulate.  Read back through this thread, there are things which could have never been debugged or optimized by him, or even by myself without simulation.

We even used the antiquated Quartus9.2 built in simulation tool for it's cheap easy and quick drawing waveform entry tool and it has always told the exact truth of the functioning state of our code in functional mode.  And in timing mode, it delivered what would be the actual output timings of the FPGA at the IO pins.

Making an SDR/DDR/DDR2/DDR3 controller means making a code which will generate the outputs just like in the datasheet in functional mode while using timing mode reveals the true IO pin timing which should either be verified visually, or done properly you should set the proper IO timing restrictions in the .sdc file and let the compiler tell you if your functional simulation will be sent to the ram chip without timing violations.

The DDR rams should be as simple to operate as SDRAM, it just the power-up sequence and setting the 4 MR# (mode register) registers which tells the ram how to operate and the burst size.  For the really high speed rams, there is an additional recommended tuning parameter for read timing during this power-up sequence which can complicate things. (Typically needed if you have a motherboard with an unknown number of attached memory modules in parallel creating an unpredictable load on the data lines)  At 400Mhz with a single ram chip, I've ignored this step with DDR2 rams in past without problem by just setting the default.

Once powered up & configured, the DDR rams operate just like SDRAM with 1 or 2 optional features for terminating a read burst.

[BrianHG]

1 last thing about the DRAM/DDR ram memory controller.  It needs a feature to be compatible with this GPU.  When you provide a list of RAM read request addresses, the ram controller will also need to accept a list of 'Destination Address' with the read requests.  Then as valid read data is being returned, the appropriate read request 'Destination Address' needs to be provided in parallel.

2. For write requests, the ram controller will need to accept a write-mask flag which masks out every 8 bits, IE a byte wide write mask enable.

3. It would be nice to have a separate port for read & write, or, when writing, the write data should be taken from the 'Destination Address' channel which usually has the read-request's destination pointer.

If Altera's or Xilinx's ram controller cannot do this, then you will need to engineer this feature around their ram controllers and embed the ram controller into an HDL module which makes the ram controller appear to have this feature.

With these 3 functions, tying any ram controller into the current GPU should be easy after a few ports are added to the current HDL.


Also, allowing access to when the refresh cycle is permitted also a big plus...

[nockieboy]

Latest update for the DVI test card.

[BrianHG]

Just thicken the 3.3v trace and add a 100nf cap to GND at the first via-resistor on the left and another after the last via-resistor on the right.

Everything else is AOK.

I see you went to town on properly protecting the HDMI port's like asmi said.
Ok, fine even though for a test PCB, connecting it to GND should have been ok.

[asmi]

Is it possible to have a dedicated small board for just the VideoRAM, and use it as a "synonymous blackbox attached via a high density a connector" in the final project?

This way, you can focus on the DRAM controller, use XILINX's IP or Altera's one, or even your own, and it  even offers the possibility to replace the module if it goes damaged or if you need one with more ram.

If it sounds reasonable, which datalink could be used?

A serial link similar to the hyper ram? Thus a kind of DDR3 controller that talks like an hyper ram module?

For me, such solution would be great and super nice, not only because you can recycle the VideoRam board for other projects without redesigning the whole board (I think the PCB for the VideoRam is critical), but also because it decouples the "implementation" from the project design, making the project more portable, more split-able in a team, and with more possibilities on the simulator side.

What do you think about?

I see no reason for going into such complexity. I already suggested making a layout for 4 Gbit part, which will give you up to 512 MBytes of RAM, if you really need more, there are 8 Gbit parts out there (though they are a bit pricey, which is why I didn't suggest it), it will give you a full 1 GByte. If you design your layout for such part, you can install any lower capacity part on that footprint because they are designed for that exact scenario (top address lines are "no-connects" on lower capacity devices). Also, if you use a single x16 DDR3 part that is soldered directly onto a board, you can get away without any termination for address/control lines because traces are going to be short, if you want to go through any sort of connector, you will have to implement a proper termination, and that will require another VTT DC-DC converter which will track Vccdq/Vccdqs. Take a close look at the DDR3 memory module (be it UDIMM or SODIMM), and you will see a whole bunch of termination resistors. They are there for a reason. So such solution will be expensive - as you will need high speed connectors, which are expensive, you will also need that memory board to be 4 or even 6 layer board to maintain proper trace impedance as well as breaking out memory devices. And in the real life I doubt you will even actually swap memory as there is no case I can think of when you can have too much memory and will want to reduce it - there is zero downside to having more memory than you need once you actually have it on a board. So if he installs a 2 Gbit module and later decide that he needs 4 Gbit one - he can simply desolder 2G part and solder 4G one in it's place, and that will stay there even if later he realized that he can use less. In the hardware world there is no downside to having more capacity than your design needs. This whole connector approach is a typical case of overengineering.
As for reusability, I've already suggested designing a sort-of breakout board first with some high-speed connectors for stuff like LVDS, HDMI and whatnot, but nockieboy said that he wants to get this GPU board completed first. This GPU board is purpose-designed for a specific application, so there is no need nor there is a possibility for reusing it for something else.

[asmi]

1 last thing about the DRAM/DDR ram memory controller.  It needs a feature to be compatible with this GPU.  When you provide a list of RAM read request addresses, the ram controller will also need to accept a list of 'Destination Address' with the read requests.  Then as valid read data is being returned, the appropriate read request 'Destination Address' needs to be provided in parallel.

2. For write requests, the ram controller will need to accept a write-mask flag which masks out every 8 bits, IE a byte wide write mask enable.

3. It would be nice to have a separate port for read & write, or, when writing, the write data should be taken from the 'Destination Address' channel which usually has the read-request's destination pointer.

If Altera's or Xilinx's ram controller cannot do this, then you will need to engineer this feature around their ram controllers and embed the ram controller into an HDL module which makes the ram controller appear to have this feature.

I can't really speak for Altera's controller as I don't have any personal experience with it (other than quick titbits I've read here and there), but Xilinx controller for DDR2 and DDR3 implements a full AXI4 slave port (though it's possible to bypass that block and use "native" user interface too if you want, and for some other memory types you will have to as they lack AXI adapter, but this is irrelevant here).
1. AXI will not provide you address along with data, but the bus specification guarantees that you will receive your read data in the same order that you've submitted your read requests, so you can add a simple FIFO where you post your read addresses as you submit read requests, and take addresses from it as you receive the read data.
2. AXI fully supported per-byte write masks
3. AXI has separate channels for reading and writing (it actually has 5 channels in total - read address, read data, write address, write data and write response). Now - I haven't actually tried sending read and write request at the same clock cycle, so I don't know what's going to happen, but I assume there is some kind of arbitration logic inside controller for such cases. Gotta check the user guide for the memory controller.

Now, from what I read, Cyclone V hard memory controller internally uses AXI bus too, so it's external Avalon-MM bus probably behaves similar to AXI bus (as it's got AXI-to-AvalonMM adapter facing outside), but I don't know this for sure.

[asmi]

I see you went to town on properly protecting the HDMI port's like asmi said.
Ok, fine even though for a test PCB, connecting it to GND should have been ok.

Schematics from these types of test PCBs often end up simply copy-pasted into final products, which is why I generally try to implement them properly on prototypes - so that I could actually copy-paste them and not think about it too much.

[nockieboy]

Just thicken the 3.3v trace and add a 100nf cap to GND at the first via-resistor on the left and another after the last via-resistor on the right.

Everything else is AOK.

All done - see latest attachments.

I see you went to town on properly protecting the HDMI port's like asmi said.
Ok, fine even though for a test PCB, connecting it to GND should have been ok.

In for a penny, in for a pound...   I'll be needing/wanting to implement these protection measures on the GPU card, so may as well test them out on the test card, too. 

[BrianHG]

1. AXI will not provide you address along with data, but the bus specification guarantees that you will receive your read data in the same order that you've submitted your read requests, so you can add a simple FIFO where you post your read addresses as you submit read requests, and take addresses from it as you receive the read data.

Like I said, place the ram controller in a box & withing that box, handle and pipe through the 'Destination address' with the read data & data-valid flag and we will be set to go.

I hope the ram controller doesn't pause after every single read request.  My old DDR2 ram controller scanned the next read or write req and if it was in the same current access column, it would fly the command through as just a new CAS would be asserted optimizing column access automatically.

A lot of our really fast filled geometry and blitter functions are already optimized sequential reads/writes (we been though hell coding the triangles & quadrilaterals to horizontally fill each line as well as having coded a pixel writer with sub-word caching for pixel writes with less than 16bits per pixel & video scale function on blitter which knows not to repeat read or repeat write pixels when zooming and shrinking an image...)  and I wouldn't want to waste such precious cycles going through a precharge and ras cycle for nothing.

[BrianHG]

Just thicken the 3.3v trace and add a 100nf cap to GND at the first via-resistor on the left and another after the last via-resistor on the right.

Everything else is AOK.

All done - see latest attachments.

I see you went to town on properly protecting the HDMI port's like asmi said.
Ok, fine even though for a test PCB, connecting it to GND should have been ok.

In for a penny, in for a pound...   I'll be needing/wanting to implement these protection measures on the GPU card, so may as well test them out on the test card, too. 

Almost perfect...  You forgot to thicken the 3.3v trace going to the 50ohm pull up resistors as well as the trace underneath.