FPGA VGA Controller for 8-bit computer

[asmi]

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. 

If you have some space left on a silkscreen, I'd suggest you to write there which FPGA pins connect to which HDMI lines - this way you won't have to reference schematics too often when you'll be working on HDL design. Mixing up HDMI channels is a pretty easy mistake to make during development, and can leave you scratching your head for hours because each HDMI channel has a specific function, and they are not interchangeable (unlike say DisplayPort lanes). Ask me how do I know this  

[BrianHG]

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

I feel you.  When all else fails, visual proof says something...
You can always slow down your ram clock to 200MHz when debugging.

[asmi]

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.

As I understand, Xilinx controller has internal FIFOs for commands, read and write data (as it supports backpressure), but from what I read on it, it can hold rows open if it sees additional commands that refer to the same row. So it does some internal optimizations, but they are not visible outside and you get your responses in exact same order you've submitted your requests.

[BrianHG]

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.

As I understand, Xilinx controller has internal FIFOs for commands, read and write data (as it supports backpressure), but from what I read on it, it can hold rows open if it sees additional commands that refer to the same row. So it does some internal optimizations, but they are not visible outside and you get your responses in exact same order you've submitted your requests.

I foresee Nockieboy having to implement Z80 read cycle wait states in his Z80 bridge.
And I guess we will separate the ram instruction fetch from the ram data read into 2 separate channels with 1 burst cycle sized cache on each, or whatever size the ram controller can efficiently terminate a DDR3 burst.  This way we wont throw out 8-16 sequential op-code instructuions or data bytes after a read of a new address cutting down repetitious access to the ram controller.

[asmi]

I foresee Nockieboy having to implement Z80 read cycle wait states in his Z80 bridge.
And I guess we will separate the ram instruction fetch from the ram data read into 2 separate channels with 1 burst cycle sized cache on each, or whatever size the ram controller can efficiently terminate a DDR3 burst.  This way we wont throw out 8-16 sequential op-code instructuions or data bytes after a read of a new address cutting down repetitious access to the ram controller.

How long is Z80 memory access cycle? Doesn't it take several clock cycles at 8 MHz (125 ns)? I suspect you will be able read out a whole bunch of data from DDR3 in that time frame
But like I said before, you guys will need to think about implementing a DMA controller. It's just not realistic to use such slow CPU to haul around megabytes of data. A single 32bit true-color image at 720p is about 3.5 MBytes, so just loading resources into memory will take forever unless you offload it to some sort of DMA engine.

[BrianHG]

But like I said before, you guys will need to think about implementing a DMA controller. It's just not realistic to use such slow CPU to haul around megabytes of data. A single 32bit true-color image at 720p is about 3.5 MBytes, so just loading resources into memory will take forever unless you offload it to some sort of DMA engine.

You haven't been reading this thread, have you?
Search for SD-Card hard drive emulator.
What do you think the blitter also does.
Also, the math-co FPU & sound system.
The Z80 will be able to play realtime video from the SD-Card and even decode and encode .mp3 simultaneously in real-time.

Why do you think I need that 'Destination Address' with the read-requests.  With that and nothing more than the existing counters, I can redirect reads into any part of the GPU core, FPGA ram, GPU peripherals/control registers, or even back into the DDR ram controller to write the read data into a new address without any other added logic.

The entire GPU system is a gigantic DMA point A to DMA point B system with the Z80 only setting the equivilant to a start address and length, or you can DMA controls into the DMA controller as well.  Even the currently fully functioning blitter does this today which is 2 loop counters with a 'hop', with a combined scaler which allows you to grow and shrink the resulting copy, perfect for realtime audio resampling playback, IE variable period/pitch.

All reads in the current system have a destination pointer sent with them, whether it is used completely or partially.  I only side-stepped this with the Z80 read req access since it was so infrequent and 1 byte at a time to it's own single destination port.

The MAGGIE just defines 15 rectangular read windows into the FPGA cache, times it's alignment to the VGA sync generator and displays them all at the same time through the BART module and palette mixer.

This was why Nockieboy decided to step up to placing the Hyperram.  Then with a little more push, IE more maggie layers direct from ram and 720p capability, we were able to push him to DDR3 at 16 bit.

[DiTBho]

If you design your layout for such part

That's the point. I am not able to design such a PCB, neither to solder such a component, but I would buy a video-ram module if it existed.

[DiTBho]

the math-co FPU & sound system.

are you going to implement a floating point unit? with basic operations {+,-,*,/,%} or also trigonometric functions {sin,cos,tan,sinch,cosch,tanch,...}?

[BrianHG]

If you design your layout for such part

That's the point. I am not able to design such a PCB, neither to solder such a component, but I would buy a video-ram module if it existed.

You can always use this guy...
https://www.digikey.com/en/products/detail/micron-technology-inc/MT46V32M16P-5B-J-TR/4315379
It will be half speed of the DDR3.  That's still very good.  But which FPGA?  The only FPGA with a TQFP good pin-count is the CycloneIII at 240pin TQFP.  All other Cyclones dropped the 240pin in favor of BGA.  Only the 144 TQFP exists for all the new ones, though, the CycloneIII is basically identical if you aren't using any CPU hard core or high speed serdes, meaning compliant with this project.

[asmi]

That's the point. I am not able to design such a PCB, neither to solder such a component

How do you know that? Have you actually tried?
I was in the same position just 3 or 4 years ago - scared of BGAs and DDRs and didn't even know how to begin tackling them. But here I am now designing DDR3 interfaces and soldering BGAs without any troubles whatsoever. If you want to move past your fear of BGAs and actually design a board, begin a new thread and outline what exactly you want to accomplish. I would be more than happy to help with both schematics and layout if parts you choose to work with will be something I have knowledge about/experience with, as would others I'm sure.
As for soldering - you only need a hot air gun (even cheap-ass one from ebay would do) and some tacky gel flux to successfully solder BGA. That's it! It's a lot simpler than you think. Once you get a little practice, you will be soldering BGAs faster than SOICs and TSSOPs.

[BrianHG]

the math-co FPU & sound system.

are you going to implement a floating point unit? with basic operations {+,-,*,/,%} or also trigonometric functions {sin,cos,tan,sinch,cosch,tanch,...}?

Haven't checked up on the trig functions, but yes on all other floating and 32bit integer math with 4x4 transformation matrix being processed from DMA address A to DMA address B.  Trig exists in Intel's megafunctions, but, I have never used them.  If the trig functions are free, I'll add them as well.  We are currently using 2 hardware multipliers only out of something like 70 units.  So we have room for math processing galore.

This means instead of the current 45 degree and 90 degree rotation & mirror tricks done in the blitter, we should be able to do full rotation and perspective transformation of geometric vertices before feeding the geometry processor.

[asmi]

It will be half speed of the DDR3.  That's still very good.  But which FPGA?  The only FPGA with a TQFP good pin-count is the CycloneIII at 240pin TQFP.  All other Cyclones dropped the 240pin in favor of BGA.  Only the 144 TQFP exists for all the new ones, though, the CycloneIII is basically identical if you aren't using any CPU hard core or high speed serdes, meaning compliant with this project.

The reason QFP is dropped in FPGA world is because you can't achieve good signal integrity with that package. Same reason for memory modules, starting from DDR2 they are BGA-only. Besides BGA versions are usually more compact, which is also important for end applications as space on PCB becomes more valuable as you increase amount of layers, so there is also a financial incentive to make your PCB as compact as you can. Just think for a second what your smart phone would look like if QFPs were the only option!

[asmi]

You haven't been reading this thread, have you?

No, I didn't read entire thread, and I'm sorry that I missed that. I take my words back then - you're way ahead of me here

[nockieboy]

That's the point. I am not able to design such a PCB, neither to solder such a component

In all seriousness, three years ago I started out knowing next to nothing about electronics at all, let alone PCB design.  I started out building my Z80 computer on breadboard, then progressed to PCB when I found out you could design these things and have them made for you - that was a huge step for me, but I was still designing and building with through-hole (TH) components.  By the time I'd progressed to the point that I had a working computer, I was upgrading the designs to use SMD components - albeit the larger ones like SOICS, 0805s and the odd TSSOP here or there.

Then I started on this GPU journey, now I'm confidently designing and soldering a GPU card with an EQFP-144 FPGA at its heart and 0603 components and designing a new GPU card with an FBGA-256 FPGA and DDR3 SDRAM, with 0402 components in places.

You won't know until you try - and if you try, keep pushing the envelope - you'll surprise yourself with what you can learn and what you can do.

[DiTBho]

How do you know that? Have you actually tried?

I have been doing electronics and micro-robotics for 15 years and designed a lot of simple 2 layers SBCs, mostly are 8bit, but there are also a couple of STM32 IMU boards (full smd design), and I have also designed a couple of FPGA boards like the Papilo/Pro (Xilinx XC6, two layers, again full smd design) plus expansions, which I am able to design and to solder myself,  but that's my current limit.

So, How do I know that? Have I actually tried? Yes, I have already tried with BGAs with bad results, and to be honest, now I am thinking about the purchase an IR oven to fix it.

Besides, I tend to avoid Xilinx's IPs, I prefer to have my own HDL code, that's an other limit because you need time to design and test stuff.

[asmi]

So, How do I know that? Have I actually tried? Yes, I have already tried with BGAs with bad results, and to be honest, now I am thinking about the purchase an IR oven to fix it.

Since I started working with BGAs, by now I have soldered hundreds of boards using both reflow oven and hot air gun, and I've never had a single soldering failure with BGAs. Reflow oven makes things easier for sure, but it's definitely not required for successful BGA soldering.
Still, my offer stands, if you want to design your own FPGA board and need some assistance, feel free to start a thread and point us to it. I will be happy to help. Or if you want to have a bit of a head start, you can take my Spartan-7 project sources from the link in my signature, and hack it away to add/remove peripherals as you see fit.

Besides, I tend to avoid Xilinx's IPs, I prefer to have my own HDL code, that's an other limit because you need time to design and test stuff.

I see no reason to reinvent the wheel. Once I understand how IP works internally (and Xilinx user guides are generally very good at explaining that), I have no problem using them as black boxes. For memory controllers MIG (Xilinx Memory Interface Generator) uses some undocumented hard blocks to implement write and read levelling, so you can't really implement your own unless you reverse-engineer their controller. Which is possible, as it generates normal HDL code, but I didn't have a reason to bother with it because what MIG generates is guaranteed to work over full PVT range.
Another Xilinx IP that I use extensively is their Microblaze CPU core. Unlike Altera, Xilinx provides it completely free of charge for any configuration you can think of (even 64 bit core is available!), and it also provides a great software development toolchain so debugging firmware for it is super easy and convenient. It would've taken me years to create such infrastructure myself from scratch.
That said, I don't shy away from designing custom HDL modules when I want to or need to - the latter is the case for example for HDMI/DisplayPort out, as Xilinx IP for that cost money, or was the case for HyperRAM and LPDDR1 memory - I had to design controllers myself because none of them exist in free public access.

[nockieboy]

Just a quick question before I send this PCB off for production - I had 3.3V pull-ups for the I2C lines from the FPGA (SCL_S and SDA_S) - I'm thinking these should be VCCIO pull-ups instead.  Is that right?

If the FPGA is running its IO at 2.5V, then feeding 3.3V into the SDA and SCL lines is going to cause issues?

EDIT: Aaaaaalso, I found a wiring error on the header.  I'd used the wrong pin for one half of one of the wired pairs. 

[BrianHG]

Just a quick question before I send this PCB off for production - I had 3.3V pull-ups for the I2C lines from the FPGA (SCL_S and SDA_S) - I'm thinking these should be VCCIO pull-ups instead.  Is that right?

If the FPGA is running its IO at 2.5V, then feeding 3.3V into the SDA and SCL lines is going to cause issues?

EDIT: Aaaaaalso, I found a wiring error on the header.  I'd used the wrong pin for one half of one of the wired pairs. 

I think you f-ed up your connector.  (It's head banging time again!)
Print your PCB
Rotate your PCB 180 degree and sit it ontop of the connector.
The IOs are now in the wrong place.



The way you have your connector, pin 1 should be bottom left.  Right now, it is top left.



See image, when rotating your PCB, the current pin 1 will move from top left to bottom right, but the dev board has pin 1 in the proper place, top right, not bottom right.

When counting dual-inline pins on these connector, pretend pin 1 is in the same place as a dip IC, except you then zipper count instead of down-up.

[BrianHG]

Do not use IOs ' 38p/39n 38/37 INC-/INC+'.
Look at the PCB, those traces are long and go under and around the ram to the other side.
Move the LVDS IOs up/further right on the connector so that you only end up on the short trace IOs which feed the ram chip.

IO:
49p/50n -> 32/31
52p/53n -> 29/28
are short and ok.

[BrianHG]

Why not place R6, R7 where I placed the white arrow.  No need to make the VCCIO wiggle up to the NXP IC.

[BrianHG]

Also, move pin 17 & 18 down by 1.  We will need to make sure the SDRam controls are in a 'NOP' & disabled state to ensure the data IOs our LVDS wires are tied to have been disabled.

Worst case, you will need to use some kapton tape to protect the connector and hot-air remove the SDRam chip to attempt 720p.  Absolute worst case is if you need to do so just to get 480p working.

[asmi]

Worst case, you will need to use some kapton tape to protect the connector and hot-air remove the SDRam chip to attempt 720p.  Absolute worst case is if you need to do so just to get 480p working.

I doubt it's going to be a problem for 480p - that's like 270 Mbps per data lane? 720p is kind of "getting up there" with 745 Mbps. But I've seen with my own eyes HDMI running at 1080p@60 (1450 Mbps per data lane) with HDMI connector connected to FPGA via bodge-wires. It wasn't very reliable, mind you, but it did kind of work, which was surprising to see. I guess it makes sense that they've added a lot of resilience in the physical layer to allow it to work even with super-crappy HDMI cables, but still - it was weird to see it actually working at all.

[nockieboy]

Uhh that was a silly mistake with the header - I don't know if it was an issue with the type of header I'd used or what, but it was clearly wrong - well done for spotting that one.

Have updated the schematic and PCB with the other changes - should be up to date so far. 

[asmi]

I think you f-ed up your connector.  (It's head banging time again!)

Oh crap, I've lost count on how many times did I make the same mistake!

[BrianHG]

Uhh that was a silly mistake with the header - I don't know if it was an issue with the type of header I'd used or what, but it was clearly wrong - well done for spotting that one.

Have updated the schematic and PCB with the other changes - should be up to date so far. 

Little length and matching cleanup.  We are assuming that this matches the length from the IO pins on the eval board below.  The goal is at the end where the 100ohm termination resistors are located, the overall length of the +&- tracks are identical.

We cant do anything about the differences through the connector itself, only correct after the connector so it will undo the length difference introduced before the first connector on the bottom.