FPGA VGA Controller for 8-bit computer

[nockieboy]

@nockieboy, how's the DAC's quality?

     There was one thing about the data and clock feeding the DAC's digital inputs which I didn't consider when setting the output pins because of the slow 25MHz speed.

     If you see any pixel glitches, or, when you finally create a 'grey' ramp test pattern with each shade of grey being at least 4 pixels wide, if there are any fine vertical stripes between any 2 grey shade bars, inverting the DAC's CLK output pin will solve the problem.

     (This is due to driving the data lines and the CLK output both from D-flipflops outputs and we may be violating the setup&hold time for the DAC's digital inputs as all the transitions are right at the same time as the rising edge of the clock.)

Hmm.. well, I haven't noticed any graphical glitches or stripes as you've described - the image looks good.  As you point out, though, I haven't set up a greyscale pattern yet and I'm just going by what I can see on the image of the Z80 you created.

I've got some experimenting and learning to do now that I have a stable system to play with (the original prototype suffered greatly from all those wire connections between the uCOM and the level converters on a breadboard, then to the FPGA dev board itself - it was getting more miss than hit as time went by) - I need to refresh my memory on the various MAGGIE colour modes and get a greyscale test image set up.

Quick question - what did you use to create the image of the Z80 chip?  Is there some format option or settings I can use to save an image in a suitable format to dump into the GPU's RAM?

Oh, and of course continue working on the software side for the video output.  I'm tempted to start investigating the graphics modes on the FPGA/MAGGIEs and develop some graphics functions (PLOT, LINE, CIRCLE etc) in software - but I'm wondering if they could be done in hardware somehow, too?

Yes.  You would create a command port address where the Z80 can feed a small FIFO input which would have something like a 16-64 commands x 64 bits (16-64 commands x 8 word x 8bits each).  Something like a 8bit function, pen FG/BG color & fill color, start x,y, end x,y coordinates + a third set of x/y coordinates if you want to make a triangle filling engine.

Now this is where you're going to lose me very quickly again.   So the FIFO would be 16-64 commands deep with each command having space for up to 8 bytes?

On the other side of the command FIFO, you would have your sequencer which would read a 64 bit command from the fifo whenever it is not empty, you will loop the start and end coordinates in the drawing pattern & write to a free memory port since you have 15 read/write ports running at 25MHz.  This would sacrifice 1 maggie channel as it would become a hardware accelerated pixel plotting channel.

Okay, so 1 MAGGIE used for hardware accelerated pixel plotting, writing the output from the sequencer into RAM.

1 more memory channels will be needed if you want to accelerate copy & paste graphics memory.  Something like a software sprite, or accelerated graphical paintbrush or fonts.

A blitter, basically?

Those 15 ports gives you some cool capabilities, not to mention that you can use this engine to feed the main Z80 port as well allowing a drawing engine which can fill up to 125 million pixels a second instead of 25 million pixels a second.

Okay, I feel I did pretty well up to this last sentence.    Feed the main Z80 port?   Even at 25 million pixels a second, isn't that a minimum framerate of over 80 fps at 640x480?  That isn't too shabby.

[nockieboy]

Hmm.. think I have an issue with bit 1 of the green channel?



Not a great picture, but there should be two more black squares to the left of the visible purple ones.  All should be shades of grey.

[BrianHG]

When I say fifo on a Z80 port, I mean a memory address you may choose which allows the Z80 to write to the fifo.
You would also provide a 'fifo' full flag for the Z80.

The fifo actually isn't necessary, but it will allow your Z80 to post multiple drawing commands while the other side of the fifo which seeds the sequencer pixel plotter is busy working plotting pixels.

As for the commands, I would prefer an 8 or 16 bit word system.  1 byte control, 1 byte data.
On your sequencer side (the thing which reads and follows the commands in the FIFO and draws the lines) , your commands would be something like:

set coordinate x1 high byte.
set coordinate x1 low byte.
set coordinate y1 high byte.
set coordinate y1 low byte.
set coordinate x2 high byte.
set coordinate x2 low byte.
set coordinate y2 high byte.
set coordinate y2 low byte.
set foreground color
set background color
set drawing color depth
set graphics destination ram coordinates high byte
set graphics destination ram coordinates low byte
set graphics raster width size
set graphics screen width limit
set graphics screen height limit
run line
run circle
run circle filled
run rectangle
run rectangle filled
run triangle
run triangle filled
run/stop/reset geometry engine (this 1 command may be on it's own dedicated port with immediate action regardless of the FIFO's state.)

That's already 24 commands.
For accelerated graphics, I would pre-compile your graphics generating list and feed the fifo in a straight manner.
I would also double buffer the geometry settings so you may draw new shapes while only updating only the required coordinate changes instead of re-filling all the settings every time.

As for the BW Z80 graphic I made, I loaded and cropped the image into Paint-Shop-Pro 6.
Then made it black and white.
Then saved it as a 'RAW' image data making it 8 bit per pixel, IE: 1 byte per pixel, no header in the file.
Then passed that 'RAW' file through my home-made basic program which can squeeze the image down to 4 bits, 2 bits or 1 bit.
(Obviously, for 8 bit, you don't need any conversion from the 'RAW' format.  Also, if you switch your palette to a MAC default 256 colored palette, using (PSE) Adobe Photoshop Elements 9, that paint software will generate an 8bit  256 color image matching the MAC palette so you may insert full color scan.  The MAC 256 color palette is pretty good for faces and most other photos as the Adobe Photoshop will dither the results to look like a few thousand colors.)

I've attached my bitplane converter.
Note that the 256 output mode actually divides the 256 gray shade image down to 16 shades of grey and places that image on palette color 16 through 32.  (This has nothing to do with the Photoshop true 256 full color image which doesn't need any processing, all you need for that it to adjust your palette to match Photoshop's Palette converter's settings)

Photoshop 24bit color to Paletted image converter: Go to 'Image / Mode / Indexed Color'.  You will also most likely try to google the file format it uses to load and save a palette to convert to you GPU palette generator.  Also, dont forget that your GPU can hold 2 different palettes simultaneously as well as sub 16/4/2 color chunks of both palettes selected for each MAGGIE window.

[BrianHG]

Hmm.. think I have an issue with bit 1 of the green channel?

(Attachment Link)

Not a great picture, but there should be two more black squares to the left of the visible purple ones.  All should be shades of grey.

Check for short/adjacent short/open/dead IO pin.
Chick IO pin table.
Check palette data.

Remember, when using the 4444 palette, you can only have 4bits red,green,blue.
When using the 565 palette, you only have 5 bits red and blue, but only 6 bits green.
I don't remember how we wired the LSB bits in the code, but they may have been tied to the MSB bits to allow full contrast color.

[BrianHG]

Okay, I feel I did pretty well up to this last sentence.    Feed the main Z80 port?   Even at 25 million pixels a second, isn't that a minimum framerate of over 80 fps at 640x480?  That isn't too shabby.

Ooopsie, I forgot you are using bitplanes.  This means to write a pixel, you must read it's data, modify only the bits you are interested in changing, then write that data out.  That is unless we implement the bit-for-bit write mask feature which is available in Intel's dual-port ram megafunction.

This will be up to you.  As for the Z80 port, just use the RS232 debugger channel and you can then write 75 million pixels a second, or around 25 million read-modify-write pixel drawing commands.  This way you will not use up any MAGGIE channels.

[nockieboy]

Ooopsie, I forgot you are using bitplanes.  This means to write a pixel, you must read it's data, modify only the bits you are interested in changing, then write that data out.  That is unless we implement the bit-for-bit write mask feature which is available in Intel's dual-port ram megafunction.

This will be up to you.  As for the Z80 port, just use the RS232 debugger channel and you can then write 75 million pixels a second, or around 25 million read-modify-write pixel drawing commands.  This way you will not use up any MAGGIE channels.

I have no idea what the benefits or drawbacks are of using either system, other than the bit-for-bit write mask feature sounds like it could speed things up a little, not that speed is an issue?

[asmi]

When I say fifo on a Z80 port, I mean a memory address you may choose which allows the Z80 to write to the fifo.
You would also provide a 'fifo' full flag for the Z80.

The fifo actually isn't necessary, but it will allow your Z80 to post multiple drawing commands while the other side of the fifo which seeds the sequencer pixel plotter is busy working plotting pixels.

As for the commands, I would prefer an 8 or 16 bit word system.  1 byte control, 1 byte data.
On your sequencer side (the thing which reads and follows the commands in the FIFO and draws the lines) , your commands would be something like:

Maybe it would be better to do it "the modern way" (how modern video cards do it) - CPU can create however many "command lists" in video memory it wants/needs, and then there is a GPU register which specifies the address of the current command list, and the way it works is that video core only reads it's value once in the beginning of a frame and executes it to the end before it reads the register again. This way a list switchover is guaranteed to be consistent, CPU can take it's time to create a new command list asynchronously from video core, and a video core can also prefetch entire command list from video memory into some kind of queue to improve core's performance.

If you guys have some spare time for reading, I highly recommend to read this blog series about how modern video cards and Graphics API work: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ Even if it won't be directly applicable to this project, it's still a very interesting reading, and can give you some ideas for your own designs.

[BrianHG]

Maybe it would be better to do it "the modern way" (how modern video cards do it) - CPU can create however many "command lists" in video memory it wants/needs, and then there is a GPU register which specifies the address of the current command list,

     Until nockieboy adds DRAM to his GPU or goes to the 4megabit Lattice FPGA (preferably doing both simultaneously during the upgrade), I recommended a 1 to 2 kilobyte fifo since his GPU ram is very limited while his Z80 ram is huge.  It's just a strategy to minimize wasting the core graphics memory.  (With the Cyclone IV ram allocated as large as possible for the video core, there are a spare 2-4 kilobytes of ram which cannot be allocated as that 1 huge chunk, so, this additional fifo/graphics command buffer will end up in those and will actually have 0 penalty on the bulk graphics ram anyways.)

     When I say fifo, well it could just be a ram block with address pointer.  Or, this address pointer just feeds one of his 15 read ports.  With added 16 megabytes dram buffer, which would probably add another 7 MAGGIE ports + 1 Z80 R/W port, the fifo may be replaced with reading directly from one of those DRAM channels while the core memory MAGGIE channels will end up being used as sprite/texture data while the bulk DRAM will contain the full background graphics.

[nockieboy]

Maybe it would be better to do it "the modern way" (how modern video cards do it) - CPU can create however many "command lists" in video memory it wants/needs, and then there is a GPU register which specifies the address of the current command list,

     Until nockieboy adds DRAM to his GPU or goes to the 4megabit Lattice FPGA (preferably doing both simultaneously during the upgrade), I recommended a 1 to 2 kilobyte fifo since his GPU ram is very limited while his Z80 ram is huge.

I don't seem to be able to get a reasonably-priced Lattice dev board from anywhere - unless anyone here can point me in the direction of one around the £30 / $40 USD mark that I haven't been able to find?

But yes, the next step is to start looking at the Lattice chips and building a board with one of those on it.  In fact my success on my first attempt with this video card (delay finding the HDL bug aside) and asmi's blog has almost inspired me to make the jump to BGA - I guess hot air-soldering one isn't impossible?  May as well add a DRAM while I'm at it.

It's just a strategy to minimize wasting the core graphics memory.  (With the Cyclone IV ram allocated as large as possible for the video core, there are a spare 2-4 kilobytes of ram which cannot be allocated as that 1 huge chunk, so, this additional fifo/graphics command buffer will end up in those and will actually have 0 penalty on the bulk graphics ram anyways.)

Yes, I'm making use of the RAM all the way up to 32KB now (leaving the 1KB for the palette at the top, still) - for some reason I've probably forgotten, NUM_WORDS was set to 24,575 (0x5FFF).  With 10 MAGGIEs, I'm at 74% of total logic elements.  The EP4CE10 has another 12KB or so, but I can't make use of it without messing with the RAM HDL and getting waaay out of my depth very quickly, so other uses for that RAM would be welcome.

[asmi]

     Until nockieboy adds DRAM to his GPU or goes to the 4megabit Lattice FPGA (preferably doing both simultaneously during the upgrade), I recommended a 1 to 2 kilobyte fifo since his GPU ram is very limited while his Z80 ram is huge.  It's just a strategy to minimize wasting the core graphics memory.  (With the Cyclone IV ram allocated as large as possible for the video core, there are a spare 2-4 kilobytes of ram which cannot be allocated as that 1 huge chunk, so, this additional fifo/graphics command buffer will end up in those and will actually have 0 penalty on the bulk graphics ram anyways.)

The big advantage of using command lists is that it completely decouples GPU performance from CPU, allowing you to scale them independent of each other. And I don't think they will consume all that much memory, unless you're going to do something really insane like per-pixel drawing (which is always going to be much slower than using primitives).

[SiliconWizard]

I don't seem to be able to get a reasonably-priced Lattice dev board from anywhere - unless anyone here can point me in the direction of one around the £30 / $40 USD mark that I haven't been able to find?

I suppose you're looking for some ECP5 dev board? You'll have a hard time finding one in this price range. The MachXO2/3 boards are around $25, but those FPGAs are probably largely "underpowered" for your requirements?

The official ECP5 eval board is $99.99. Certainly more expensive than your target price, but I couldn't find anything cheaper based on an ECP5. https://www.latticestore.com/products/tabid/417/categoryid/59/productid/122774/default.aspx

There is this open-source project: https://gregdavill.github.io/OrangeCrab/
but: very few IOs broken out, and no ready-made board that I know of.

[asmi]

Yes, I'm making use of the RAM all the way up to 32KB now (leaving the 1KB for the palette at the top, still) - for some reason I've probably forgotten, NUM_WORDS was set to 24,575 (0x5FFF).  With 10 MAGGIEs, I'm at 74% of total logic elements.  The EP4CE10 has another 12KB or so, but I can't make use of it without messing with the RAM HDL and getting waaay out of my depth very quickly, so other uses for that RAM would be welcome.

You're making your own board, right? So what stops you from adding an SRAM/SDRAM chip on it, or HyperRAM chip if your IO pin budget doesn't allow for the former (HyperRAM only uses 12 IO pins and has 64Mbit capacity running up to 100 MHz DDR for 3V and 166 MHz for 1.8V version)? Of those, SRAM is the easiest to implement a controller for (it's literally "place address out, read out the data on the next cycle"), followed by HyperRAM (because it "looks" like PSRAM meaning refresh is taken care of internally, and protocol is very simple, though it has quite a bit of latency from initiating command until first byte out).

[nockieboy]

I suppose you're looking for some ECP5 dev board? You'll have a hard time finding one in this price range. The MachXO2/3 boards are around $25, but those FPGAs are probably largely "underpowered" for your requirements?

The official ECP5 eval board is $99.99. Certainly more expensive than your target price, but I couldn't find anything cheaper based on an ECP5. https://www.latticestore.com/products/tabid/417/categoryid/59/productid/122774/default.aspx

Ah, that's okay then, I was just worried I was missing something somewhere.  Will have to wait a while to get one of those - I think trying to build a video card based on a Lattice FPGA may be a little fraught with problems, but then again I'm not sure what a dev board will do for me.  I've got the HDL, might need to tweak it some for the Lattice environment, all I need really is to get one onto a board so I can program it.

Is the toolchain similar to Altera's?

You're making your own board, right? So what stops you from adding an SRAM/SDRAM chip on it, or HyperRAM chip if your IO pin budget doesn't allow for the former (HyperRAM only uses 12 IO pins and has 64Mbit capacity running up to 100 MHz DDR for 3V and 166 MHz for 1.8V version)? Of those, SRAM is the easiest to implement a controller for (it's literally "place address out, read out the data on the next cycle"), followed by HyperRAM (because it "looks" like PSRAM meaning refresh is taken care of internally, and protocol is very simple, though it has quite a bit of latency from initiating command until first byte out).

Yes, have made my own board - pictured previously.  The biggest problem stopping me from adding SRAM/SDRAM is the lack of free IO.  I've got literally 4 IO pins left free - I can stretch that to 7 if I drop the SD card that I want to include.  This is one of the reasons I'm probably using this platform as a stepping stone to BGA, but I get panicky if I think about that too much at the moment. 

[SiliconWizard]

I suppose you're looking for some ECP5 dev board? You'll have a hard time finding one in this price range. The MachXO2/3 boards are around $25, but those FPGAs are probably largely "underpowered" for your requirements?

The official ECP5 eval board is $99.99. Certainly more expensive than your target price, but I couldn't find anything cheaper based on an ECP5. https://www.latticestore.com/products/tabid/417/categoryid/59/productid/122774/default.aspx

Ah, that's okay then, I was just worried I was missing something somewhere.  Will have to wait a while to get one of those - I think trying to build a video card based on a Lattice FPGA may be a little fraught with problems, but then again I'm not sure what a dev board will do for me.  I've got the HDL, might need to tweak it some for the Lattice environment, all I need really is to get one onto a board so I can program it.

This basic dev board doesn't have SDRAM or DDR RAM so, that might be a problem for you (unless the amount of block RAM is sufficient.) There are other Lattice ECP5 dev boards, just take a look, one of them probably has that.

Is the toolchain similar to Altera's?

I have never really used Altera's tools much, so I can't really comment. But Lattice Diamond is reasonable and easy to use. I rather like it.
Speaking of Diamond, the ECP5 series is actually not supported by the free version, so you'll need an extra license. Lattice dev boards come with a free license (limited to the ECP5 model there is on the board IIRC), but if you don't buy a Lattice dev board, you'll probably have to buy a license. I have no clue about the current pricing. A few years back, it was $99/year, but it may have changed!

[asmi]

This is one of the reasons I'm probably using this platform as a stepping stone to BGA, but I get panicky if I think about that too much at the moment. 

You will come to that eventually, like I did, and so did many others. At least now you've successfully passed the first stage  - "who the f*ck needs so many pins???" - and started to understand exactly why having more pins is good, not bad
Like I said a million times before, your best bet is to give it a try. Begin from the cheapest FPGA in BGA package you can find, design a simple breakout with nothing on it except the bare minimum required to program the chip + some LEDs. My very first FPGA board used the cheapest 7 series chip I could find (at the time it was A15), once I got that working, I felt much more at ease working with more expensive parts. Now I don't shy away from placing $100+ BGAs on my boards.

[NorthGuy]

BGA - I guess hot air-soldering one isn't impossible?

Sure is. The balls are made of solder, so all you need is a little bit of flux which you put on the board. Put it on and start heating. When it moves, pock it gently to make sure it's sitting well, count to 5, then remove the heat slowly.

[nockieboy]

Speaking of Diamond, the ECP5 series is actually not supported by the free version, so you'll need an extra license. Lattice dev boards come with a free license (limited to the ECP5 model there is on the board IIRC), but if you don't buy a Lattice dev board, you'll probably have to buy a license. I have no clue about the current pricing. A few years back, it was $99/year, but it may have changed!

Ah, the licence may be a deal breaker for me.   I'm not building this with making profits in mind, it's a personal project and having to pay a yearly fee so I can use an IDE to program FPGAs sort of flies in the face of my desire to keep this hobby as a hobby.

Mind you, if I'm looking to step up to BGAs, then the options open up further for other makes of FPGA as well.  I could just get an EP4CE10 (or upgrade slightly to the CE15 or beyond) in a BGA package and have access to lots more IO that will let me add an SDRAM etc.

So adding SDRAM would be a definite benefit then?

This is one of the reasons I'm probably using this platform as a stepping stone to BGA, but I get panicky if I think about that too much at the moment. 

You will come to that eventually, like I did, and so did many others. At least now you've successfully passed the first stage  - "who the f*ck needs so many pins???" - and started to understand exactly why having more pins is good, not bad

That is so true.  I had no idea about FPGAs before I started this thread - literally none at all - and now I'm struggling with the limited IO on my FPGA - and that's just interfacing it to an 8-bit microprocessor and VGA video output with a couple of extra addons (SD card, PS/2, LED, speaker).

I'm quite enjoying learning about them and using them, though.  Whilst a lot of these discussions about various components of the video driver are going over my head, I'm also learning so much and loving the versatility of FPGAs.  But now I'm feeling the need.... for moar IOs! 

Like I said a million times before, your best bet is to give it a try. Begin from the cheapest FPGA in BGA package you can find, design a simple breakout with nothing on it except the bare minimum required to program the chip + some LEDs. My very first FPGA board used the cheapest 7 series chip I could find (at the time it was A15), once I got that working, I felt much more at ease working with more expensive parts. Now I don't shy away from placing $100+ BGAs on my boards.

I've spent a little time reading your blog today and I must say it's giving me a little confidence to go and try and make a BGA-based card.  I don't have a reflow oven like you, but I have a cheap hot air gun, lots of flux, some low-temp lead-free solder (now), and a desire to give it a try, so I think I'll take your advice and see what I can do.

Had a quick look for some BGA FPGA packages I could start out on - found this as the cheapest option:

LCMXO2 - a Lattice MachXO2?  I'd rather stick with Intel/Altera as I'm familiar with the toolchain now, but the cheapest EPx FPGA I can find is over £15 for an EP4CE6 from Mouser, or £18 for two EP4CE10F17s from AliExpress.

Those EP4CE10F17s from AliExpress are 256-pin FineLine BGA packages... I've had a quick look to see what their dimensions are, looks like a 1mm pitch??  I'm guessing JLCPCB would be fine with that.

I'm also going to have to go to 4-layer PCB fab as well, I'm guessing?

BGA - I guess hot air-soldering one isn't impossible?

Sure is. The balls are made of solder, so all you need is a little bit of flux which you put on the board. Put it on and start heating. When it moves, pock it gently to make sure it's sitting well, count to 5, then remove the heat slowly.

Thanks NorthGuy.    I guess I just need to give it a go and build my confidence by doing it with smaller, cheaper packages first like asmi has suggested.

[asmi]

Ah, the licence may be a deal breaker for me.   I'm not building this with making profits in mind, it's a personal project and having to pay a yearly fee so I can use an IDE to program FPGAs sort of flies in the face of my desire to keep this hobby as a hobby.

That is one reason I've chosen Xilinx from the get go - they provide a lot of useful stuff for free, as well as give access to a lot of devices, including some really beefy ones like Artix-200 with 200k gates.

Mind you, if I'm looking to step up to BGAs, then the options open up further for other makes of FPGA as well.  I could just get an EP4CE10 (or upgrade slightly to the CE15 or beyond) in a BGA package and have access to lots more IO that will let me add an SDRAM etc.

One thing you need to note is that FPGA lines usually consist of several pin-compatible device subfamilies with different densities, so you can install larger device on your board if smaller isn't enough without board respin (or the other way around), if you designed your board to support the largest device is this pin-compatible subfamily from the get go (usually this means using DC-DC converters capable of providing enough current for the largest device). This is why you can take my Spartan-7 board and install any device in that package, and it will work. There are some gotchas with this approach, but in general it works just fine.

So adding SDRAM would be a definite benefit then?

Having something is always better than not having it But you still got to watch out to not run out of pins - BGAs do have more pins, but you will run out of them just as well

I've spent a little time reading your blog today and I must say it's giving me a little confidence to go and try and make a BGA-based card.  I don't have a reflow oven like you, but I have a cheap hot air gun, lots of flux, some low-temp lead-free solder (now), and a desire to give it a try, so I think I'll take your advice and see what I can do.

Thanks, I wish I would have more time to post stuff there, I got a lot to say, but no time to actually write it up and prepare all related materials (like pictures and stuff).

Those EP4CE10F17s from AliExpress are 256-pin FineLine BGA packages... I've had a quick look to see what their dimensions are, looks like a 1mm pitch??  I'm guessing JLCPCB would be fine with that.

I would recommend you to be careful with those aliexpress chips, especially in the beginning as it's somewhat of a lottery and there is a chance to receive a dud. Imagine that you soldered your first BGA FPGA on, and it's not working. Why? Is it because you screwed something up in schematics, or it's a soldering failure (I'm yet to encounter one, but it is always a possibility), or your FPGA is a dud? How do you figure out which one it is?
This is why I'd suggest you to skip morning coffee for few days (or some beers for one Friday, since you're in UK ), and buy a known-good chip. At least this will all but eliminate one possibility. But be prepared for schematic/layout screw ups - it happens even to the best of us who should know better, and for me my first revision of any project almost never even gets to assembly, as I find some fatal flaw either while waiting for the boards to get manufactured and delivered, or during some basic testing of newly arrived boards.

I'm also going to have to go to 4-layer PCB fab as well, I'm guessing?

Yes, that would be a start. You can do quite a bit with 4 layer boards nowadays, with more and more manufacturers allowing for ever narrower traces without paying through the nose.

Thanks NorthGuy.    I guess I just need to give it a go and build my confidence by doing it with smaller, cheaper packages first like asmi has suggested.

If you don't mind working with older FPGAs, you can try getting your hands on some FBGAs with leaded solder balls instead of usual lead-free stuff. Yes, you can still find them even on Digikey, here is one example: https://www.digikey.com/products/en?keywords=XC6SLX25-2FT256I
Also make sure you place your BGA devices far enough apart from other parts to make hot air gun assembly easier as you won't have to worry about blowing some nearby parts off board.

[NorthGuy]

the cheapest EPx FPGA I can find is over £15 for an EP4CE6 from Mouser, or £18 for two EP4CE10F17s from AliExpress.

XC7S6-1FTGB196C is less than US $15 from Mouser.

[nockieboy]

I would recommend you to be careful with those aliexpress chips, especially in the beginning as it's somewhat of a lottery and there is a chance to receive a dud. Imagine that you soldered your first BGA FPGA on, and it's not working. Why? Is it because you screwed something up in schematics, or it's a soldering failure (I'm yet to encounter one, but it is always a possibility), or your FPGA is a dud? How do you figure out which one it is?

Already been there with the current batch of EP4CE10 TQFP-144's I got from there.  Thing is, I intentionally got them from AliExpress knowing (or suspecting) that they may not be fully functional, but I did it because I needed practice soldering TQFP packages - I'd never done anything like that before, especially not with the exposed ground pad underneath.  Now I'm happy I can solder them reliably, the next batch I would get would be from somewhere like Mouser or Digikey.  So far, the success rate for the 3 FPGAs from AliExpress are 2 with a single dud IO, 1 working just fine.  But I'll update that once I get the third card fully built (though it's working fine so far).

This is why I'd suggest you to skip morning coffee for few days (or some beers for one Friday, since you're in UK ), and buy a known-good chip. At least this will all but eliminate one possibility. But be prepared for schematic/layout screw ups - it happens even to the best of us who should know better, and for me my first revision of any project almost never even gets to assembly, as I find some fatal flaw either while waiting for the boards to get manufactured and delivered, or during some basic testing of newly arrived boards.

Running my schematics and PCB design past you guys here seems to have ironed out most of the critical errors - the only issue I've found with the PCB so far is that I think I messed up the PS/2 socket wiring, but everything else is just fine.   

If you don't mind working with older FPGAs, you can try getting your hands on some FBGAs with leaded solder balls instead of usual lead-free stuff. Yes, you can still find them even on Digikey, here is one example: https://www.digikey.com/products/en?keywords=XC6SLX25-2FT256I
Also make sure you place your BGA devices far enough apart from other parts to make hot air gun assembly easier as you won't have to worry about blowing some nearby parts off board.

So what are the issues with lead-free stuff?  Are all the newer BGA FPGAs with lead-free solder balls?  In theory (and from what I remember of your blog!!) then an ENIG finish on the PCB would give better soldering results if I have lead-free BGA balls?

[asmi]

Already been there with the current batch of EP4CE10 TQFP-144's I got from there.  Thing is, I intentionally got them from AliExpress knowing (or suspecting) that they may not be fully functional, but I did it because I needed practice soldering TQFP packages - I'd never done anything like that before, especially not with the exposed ground pad underneath.  Now I'm happy I can solder them reliably, the next batch I would get would be from somewhere like Mouser or Digikey.  So far, the success rate for the 3 FPGAs from AliExpress are 2 with a single dud IO, 1 working just fine.  But I'll update that once I get the third card fully built (though it's working fine so far).

You're talking about logic, while I'm talking about perception. Your very first try would better be a success as it would provide insane morale boost, so even if you will see a failure down the road, it won't be that big of a deal.

Running my schematics and PCB design past you guys here seems to have ironed out most of the critical errors - the only issue I've found with the PCB so far is that I think I messed up the PS/2 socket wiring, but everything else is just fine.   

Unfortunately since I focus pretty much exclusively on Xilinx 7 series devices, I can't help much with other devices. That's why I was kind of nudging you towards these devices, as I know them fairly well so I can say something actually useful and helpful Specialization has some bad sides as well as some good ones.

So what are the issues with lead-free stuff?  Are all the newer BGA FPGAs with lead-free solder balls?  In theory (and from what I remember of your blog!!) then an ENIG finish on the PCB would give better soldering results if I have lead-free BGA balls?

Most modern chips are lead-free. But to be honest, I tried pretty much all combinations (LF balls with leaded paste, LF balls/LF paste, HASL/HALFSL/ENIG), and all worked OK. I still recommend ENIG because it provides flat surfaces and protects pads for a long time from corrosion. ENIG is compatible with both leaded and LF solder, infact I'd argue leaded solder provides stronger bond.
The reason I suggested using BGA with leaded balls is because they melt at lower temperature, so it's easier to solder using hot-air gun (for ovens it doesn't matter at much).

[nockieboy]

You're talking about logic, while I'm talking about perception. Your very first try would better be a success as it would provide insane morale boost, so even if you will see a failure down the road, it won't be that big of a deal.

True, fair point.  Well, it seems if I want to practice on an FPGA that is in the same family as the Intel/Altera ones I've been using, I'm looking to spend about $12 each on BGA packages (obviously excluding PCB fab costs too).  I don't mind too much learning another toolchain (I actually have an unused Spartan FPGA board on a shelf and the programmer to go with it), so do you have any recommendations on a cheaper option I can practice with?

Most modern chips are lead-free. But to be honest, I tried pretty much all combinations (LF balls with leaded paste, LF balls/LF paste, HASL/HALFSL/ENIG), and all worked OK. I still recommend ENIG because it provides flat surfaces and protects pads for a long time from corrosion. ENIG is compatible with both leaded and LF solder, infact I'd argue leaded solder provides stronger bond.
The reason I suggested using BGA with leaded balls is because they melt at lower temperature, so it's easier to solder using hot-air gun (for ovens it doesn't matter at much).

Ah okay, I hadn't thought there'd be a difference in melting point, but that's logical.  Do you need additional solder (i.e. a solder mask) for BGAs, or can you just drop one onto a PCB (tacked in place with some sticky flux), and heat it up?

[asmi]

True, fair point.  Well, it seems if I want to practice on an FPGA that is in the same family as the Intel/Altera ones I've been using, I'm looking to spend about $12 each on BGA packages (obviously excluding PCB fab costs too).  I don't mind too much learning another toolchain (I actually have an unused Spartan FPGA board on a shelf and the programmer to go with it), so do you have any recommendations on a cheaper option I can practice with?

Like I said, the only practical experience I have is with 7 series devices because quite frankly they cover pretty much entire range of my immediate and potential near-to-midterm needs, allowing designs from very simple glue logic at the small end all the way to 933 MHz DDR3 memory and 10+ Gpbs transceivers for pretty much any modern hi-speed interconnect I can think of from HDMI/DVI to PCI Express 3.0 and 10G Ethernet.
That said, if you want to practice BGA soldering (not necessarily FPGAs), buy a bunch of QSPI flash chips in BGA-24 package (for example this), get an FTDI's 3.3V MPSSE cable (or any 3.3V microcontroller you have which has an SPI port available), design a small breakout (this chip can be broken out on regular 2 layer board), and get on with your practice! Once you solder the chip down, you can use SPI master device (be in an MCU, or MPSSE cable) to verify that soldering was a success and you can communicate with the chip.

Ah okay, I hadn't thought there'd be a difference in melting point, but that's logical.  Do you need additional solder (i.e. a solder mask) for BGAs, or can you just drop one onto a PCB (tacked in place with some sticky flux), and heat it up?

Solder and solder mask are two different things, the purpose of the latter is to prevent former from getting into places where it isn't supposed to go
If you use a hot air gun and ENIG (or any other flat) finish, you can go either way with or without additional paste on BGA pads, if using something like HASL, then you don't need to use solder paste as HASL already IS a solder With ENIG, advantage of soldering with solder paste on pads is that after soldering the device is sitting higher off board, which, for example, makes washing off remaining flux residue as well as small solder droplets (these quite often form in the oven) from under the package easier.
So I'd recommend sticking to ENIG, and not adding solder paste onto BGA pads before soldering unless you have a stencil and print solder onto entire board at once. Just add a good amount of tacky flux, and go for it. One thing - as flux heats up it loses viscosity and becomes more liquid, so if you put a bit too much of it, the part may shift a little (not a problem at all for reasonable pitch BGAs say 0.6+mm, but can be a big problem for microBGAs with <0.5mm pitch). As for package alignment - as you may or may not know, molten solder has very high surface tension (easy way to see it is to progressively add solder onto soldering iron tip - you will see that you can add A LOT before it drips, and the reason such big ball still hangs onto the tip is the surface tension), so BGAs tend to self-align if misalignment is less than half of the ball pitch, but if it's more, they can self-align into the wrong pads (off by 1), so you need to make sure misalignment doesn't exceed pitch/2 (again, this is typically not a problem for 1 and 0.8 mm pitch devices which you likely will be working with).

[NorthGuy]

Ah okay, I hadn't thought there'd be a difference in melting point, but that's logical.  Do you need additional solder (i.e. a solder mask) for BGAs, or can you just drop one onto a PCB (tacked in place with some sticky flux), and heat it up?

Since you do not have good control over placement when you do this manually, you're risking smashing the solder paste and perhaps short something inside (although a chance of this is not that big). Thus, it looks more reliable to me not to use any solder paste, only flux. This lets you move the FPGA freely and thus you can achieve better placement prior to heating.

When you don't use solder paste, it is more important to have a flat surface. I've never used anything but ENIG, so I cannot comment on other surfaces.

The amount of solder added by the solder paste is small compared to the amount of solder in the balls, so it doesn't affect the quality of the connection much, for prototyping anyway.

Don't use too much flux, or it may start bubbling and bubbles will start escaping from under FPGA lifiting it up which may screw up the alignment.

[nockieboy]

That said, if you want to practice BGA soldering (not necessarily FPGAs), buy a bunch of QSPI flash chips in BGA-24 package (for example this), get an FTDI's 3.3V MPSSE cable (or any 3.3V microcontroller you have which has an SPI port available), design a small breakout (this chip can be broken out on regular 2 layer board), and get on with your practice! Once you solder the chip down, you can use SPI master device (be in an MCU, or MPSSE cable) to verify that soldering was a success and you can communicate with the chip.

Righto, will take a look at those QSPIs, they sound like a good way to practice. 

Ah okay, I hadn't thought there'd be a difference in melting point, but that's logical.  Do you need additional solder (i.e. a solder mask) for BGAs, or can you just drop one onto a PCB (tacked in place with some sticky flux), and heat it up?

Solder and solder mask are two different things, the purpose of the latter is to prevent former from getting into places where it isn't supposed to go

Well done, you spotted my deliberate mistake.    Of course I meant an SMT stencil. 

If you use a hot air gun and ENIG (or any other flat) finish, you can go either way with or without additional paste on BGA pads, if using something like HASL, then you don't need to use solder paste as HASL already IS a solder

I've been using HASL all along so far - haven't really had enough there to solder anything to it without requiring additional solder, though.  I think I had one TSSOP pin actually tack down with no additional solder, but it needed some more before I was happy with the electrical connection.  I suppose what little is there would help a BGA ball to melt/attach, though.

With ENIG, advantage of soldering with solder paste on pads is that after soldering the device is sitting higher off board, which, for example, makes washing off remaining flux residue as well as small solder droplets (these quite often form in the oven) from under the package easier.
So I'd recommend sticking to ENIG, and not adding solder paste onto BGA pads before soldering unless you have a stencil and print solder onto entire board at once. Just add a good amount of tacky flux, and go for it. One thing - as flux heats up it loses viscosity and becomes more liquid, so if you put a bit too much of it, the part may shift a little (not a problem at all for reasonable pitch BGAs say 0.6+mm, but can be a big problem for microBGAs with <0.5mm pitch). As for package alignment - as you may or may not know, molten solder has very high surface tension (easy way to see it is to progressively add solder onto soldering iron tip - you will see that you can add A LOT before it drips, and the reason such big ball still hangs onto the tip is the surface tension), so BGAs tend to self-align if misalignment is less than half of the ball pitch, but if it's more, they can self-align into the wrong pads (off by 1), so you need to make sure misalignment doesn't exceed pitch/2 (again, this is typically not a problem for 1 and 0.8 mm pitch devices which you likely will be working with).

Yes, I'm intending to start with 1mm pitch BGAs.  Aware of the self-alignment due to surface tension - have found it very useful when soldering the 3225 oscillator to the video card. All sounds very promising - I'm eager to get started, now!