Planning/design/review for a 6-layer Xilinx Artix-7 board for DIY computer.

[asmi]

Oh, so you don't believe we could operate the frame buffer and render in 422 YUV mode.

I said what I said. Let's move on from this to discussing the actual board.

[nockieboy]

1080p is more than good enough for me - 4K output is beyond the scope of the GPU project and certainly isn't something I need or want, but it makes for interesting 'pushing the envelope' discussions.

Unless the Xilinx's controller gives you 16 configurable read/write ports, you will probably will be using my controller's multiport front-end interface as it is doing a shit load of heavy lifting for you.  My multiport uses the user interface command clock from Xilinx's DDR3 controller unless you want to manually configure your own PLL.  In the Max10-6, it's upper limit was ~200Mhz, but your current project is running it at 100MHz.  The Spartan7 should achieve 200Mhz with ease.  (Actually I think the only reason we went 100MHz instead of 200Mhz was the ellipse line generator was too complex.)  This will double the speed of all the rest of your GPU modules, IE:Geometry renderer.  The new data buss' double width, going from 128 bit to 256 bit will once again potentially double your maximum throughput speed, though except for my display raster generator, you have yet to code anything else which will make full use of this true 4x top speed.

I think it's a given that I'll be using the multiport front-end interface in conjunction with Xilinx's controller, apologies if I caused confusion referring to your DDR3 controller, I meant it as a 'catch all' term to refer to the proposed multiport front-end/Xilinx controller combo.

If I were you, you should already be working on coding and simulating this part.

I'm working on learning Vivado and setting up a DDR3 simulation, but progress is glacially slow at the moment due to work commitments and little free time.

Alternatively you can use 200 MHz LVDS clock generator connected to DDR3's bank pins, controller will output 100 MHz UI clock which you use to drive the interface, and place an additional 27 MHz clock just for the video out - these clock gens are cheap (about $1), so it shouldn't be that big of a deal. Or instead of 27 MHz fixed frequency you can use a programmable clock generator like SI5351A-B-GT which has 3 outputs each of which can be programmed to a wide range of frequencies via I2C interface for ultimate flexibility. That device is about $3 (+ some cents for the 25 or 27 MHz crystal), so quite a reasonable price.

Ooh that looks like a pretty cool gadget.  Didn't even know they existed!  Would that have to be used in addition to a fixed system clock, or could it replace the system clock entirely? Presumably it needs to be configured at power-on via I2C, so the FPGA would require some sort of fixed system clock source to set it up as intended.  Would be handy if it passed through the 25/27MHz reference clock by default on one of the outputs to allow the FPGA to set it up with a faster/alternative clock frequency.  I've looked at the datasheet (not in massive detail, admittedly) and I couldn't find anything to help with those questions.

[dolbeau]

Would be handy if it passed through the 25/27MHz reference clock by default on one of the outputs to allow the FPGA to set it up with a faster/alternative clock frequency.

Those devices can have a configuration pre-programmed in their NVM (non-volatile-memory) to output needed frequencies at boot time. You can generate custom configuration with Skyworks' tool 'ClockBuilder Pro'. I don't know a way to 'decode' the order code Bxxxxx into a configuration, though (as there's some pre-programmed device in stock at e.g. mouser).

[BrianHG]

The Spartan7 has a fractional divider PLL, you do not need an external PLL generator.  There may be a rare circumstance if you want to generate huge fraction low phase reference frequency to create every single 1-10hz step reference clocks, like some of those old multiple variable VGA modes, but for the basic 1080p through 480p plus a few old generic VGA 60hz / 72hz, the Spartan7 should be able to do it all internally.  Though, it does mean learning to setup a reconfigurable PLL for the Spartan.

[asmi]

The Spartan7 has a fractional divider PLL, you do not need an external PLL generator.  There may be a rare circumstance if you want to generate huge fraction low phase reference frequency to create every single 1-10hz step reference clocks, like some of those old multiple variable VGA modes, but for the basic 1080p through 480p plus a few old generic VGA 60hz / 72hz, the Spartan7 should be able to do it all internally.  Though, it does mean learning to setup a reconfigurable PLL for the Spartan.

Why do you keep talking about Spartan-7? That's not the device we're going to use.

And we still don't seem to have a decision regarding the kind of memory we're going to implement...

[nockieboy]

The Spartan7 has a fractional divider PLL, you do not need an external PLL generator.  There may be a rare circumstance if you want to generate huge fraction low phase reference frequency to create every single 1-10hz step reference clocks, like some of those old multiple variable VGA modes, but for the basic 1080p through 480p plus a few old generic VGA 60hz / 72hz, the Spartan7 should be able to do it all internally.  Though, it does mean learning to setup a reconfigurable PLL for the Spartan.

Why do you keep talking about Spartan-7? That's not the device we're going to use.

And we still don't seem to have a decision regarding the kind of memory we're going to implement...

We're using the Artix-7, not the Spartan - specifically, the XC7A100T-2FGG484.

As far as the memory discussion is going, unless I hear otherwise, I'm going to stick with two of these: MT41K256M16TW-107:P.  If anyone has a compelling reason for me to use some other setup or parts, I'll be glad to hear it!

[asmi]

As far as the memory discussion is going, unless I hear otherwise, I'm going to stick with two of these: MT41K256M16TW-107:P.  If anyone has a compelling reason for me to use some other setup or parts, I'll be glad to hear it!

That's what I assumed too, but BrianHG made it sound like 32 bit interface is not going to be enough, and he would rather have 64 bit one...

[nockieboy]

As far as the memory discussion is going, unless I hear otherwise, I'm going to stick with two of these: MT41K256M16TW-107:P.  If anyone has a compelling reason for me to use some other setup or parts, I'll be glad to hear it!

That's what I assumed too, but BrianHG made it sound like 32 bit interface is not going to be enough, and he would rather have 64 bit one...

This is probably a silly question, so put it down to lack of electronics experience on my part;  the switch from 32-bit to 64-bit would just require doubling the number of DDR3 chips and data signal traces, right?  And obviously a commensurate massive increase in routing complexity on the PCB?  Length-matching all those data lines is going to be no mean feat?  How do they do it on graphics cards where you have banks of memory chips and they're not all the same distance from the GPU chip?  They must be very proficient at hiding cm's of snaking traces to match line length?

In terms of project progress, I've spent the last week trying to get through the most evil cold I've ever caught (and I'm still in the middle of it) - it's not Covid, but it may as well be.  Once I'm feeling better I need to get started on design and simulation of the memory - that's my next step - so all this discussion of memory bandwidth and interface types is timely and relevant.

[BrianHG]

This is probably a silly question, so put it down to lack of electronics experience on my part;  the switch from 32-bit to 64-bit would just require doubling the number of DDR3 chips and data signal traces, right? 

The other reason I said to use a SODIMM module is that you do not have to worry about PCB routing the 4 DDR3 chips together.  It is done on each SODIMM module.  All you need to concern yourself is with the routing and length matching of the FPGA to the SODIMM's connector.  Making your own 2 DDR3 ram chips on PCB isn't too bad.  4 of them, well, let the ones who made the SODIMM module worry about the chip-chip control and address lines shared between the 4 DDR3 chips.

Also, no BGA mounting for the 4 DDDR3 chips.  And if you ever get a fast oscilloscope, you can probe the SODIMM connector.

[nockieboy]

The other reason I said to use a SODIMM module is that you do not have to worry about PCB routing the 4 DDR3 chips together.  It is done on each SODIMM module.  All you need to concern yourself is with the routing and length matching of the FPGA to the SODIMM's connector.  Making your own 2 DDR3 ram chips on PCB isn't too bad.  4 of them, well, let the ones who made the SODIMM module worry about the chip-chip control and address lines shared between the 4 DDR3 chips.

Also, no BGA mounting for the 4 DDDR3 chips.  And if you ever get a fast oscilloscope, you can probe the SODIMM connector.

Well, you're certainly making a good case for SODIMM.  Ease of construction is a big draw, plus flexibility in choosing whatever size memory stick you need for your project.  The size of the connector is an issue though, and I believe the biggest problem is that it will literally eat up the vast majority of IOs on the FPGA, to the point where I've seen forum posts about how to connect SODIMMs to Artix-7s and work around the configuration bank-sharing issue.  Apparently it IS possible, but the lack of remaining IOs may be a deal breaker.  I'll take a closer look at SODIMM just to give it a fair chance, though.

EDIT:  I've just inserted a SODIMM-204 connector into the PCB design (it's not designed yet, just a rough idea of sizing and initial component layout) and it's actually not much wider than the mezzanine connectors we're using to attach the core board to the carrier.  Might need some fine tuning so that the memory stick itself sits within the outline of the core board, but that's not essential.  So realistically, the only negatives for SODIMM are its IO resource demands.  I'll look at that in more detail later.

[BrianHG]

EDIT:  I've just inserted a SODIMM-204 connector into the PCB design (it's not designed yet, just a rough idea of sizing and initial component layout) and it's actually not much wider than the mezzanine connectors we're using to attach the core board to the carrier.  Might need some fine tuning so that the memory stick itself sits within the outline of the core board, but that's not essential.  So realistically, the only negatives for SODIMM are its IO resource demands.  I'll look at that in more detail later.

See if vertical SODIMM connectors exist.  IE: The memory stick mounts vertically like in a home PC motherboard.

[nockieboy]

Okay, so my next question is probably more for asmi as it's Vivado MIG-related, but relates to SODIMM selection.

At the moment I'm just using Mouser to get an idea of compatible parts, but it seems that none of the SODIMMs are actually what I'd class as cheap.  I don't need gigabytes of memory, one would be more than enough.  Prices on Mouser soon hit £70-£90 and beyond for SODIMMs.

I'd (naively, perhaps) assumed that pretty much any SODIMM could be slotted-in and used - refurbished 1GB SODIMMS on eBay, for example, retail for less than the price of a coffee.  The Vivado MIG is still asking for specific memory parts - how much does the part selection affect the resulting memory controller that's produced by the MIG?  Is it really limited to working with just one part number of DDR3 chip?  Does this specificity affect sourcing SODIMMs or am I worrying too much about it and should just select any option for the memory part?

[BrianHG]

Search on Amazon.com or similar:
'Laptop DDR3 ram'

2 modules for 19$, and they are dual-rank.  IE: 16 ram chips in total for 20$.
Name brands like Samsung go for 24$ for 2 modules, but only single rank 4GB each instead of dual rank 8gb each.
You do not need Dual Rank.  12$ for 4gb of Samsung memory, well you get 2 for 24$ is good as 3$ per ram chip.

Basically go for the name brand new Samsung or Micron.
Do not buy ram modules at Digikey or Mouser.  Now-a-days, they are a commodity item sold anywhere.  Even at my local grocery store and pharmacy.

[BrianHG]

https://www.amazon.com/s?k=laptop+ddr3&i=electronics&rh=n%3A172500%2Cp_n_feature_four_browse-bin%3A2253866011%2Cp_n_feature_seven_browse-bin%3A24084330011%2Cp_36%3A-3500%2Cp_n_feature_browse-bin%3A23964008011&dc&crid=1GZWPTZK89GQ4&qid=1674132688&rnid=23963802011&sprefix=laptop+ddr3%2Caps%2C217&ref=sr_nr_p_n_feature_browse-bin_2&ds=v1%3AJVmM%2Fwvl3D6LVCoRXkt%2BA28d5A%2F6AxNHFEVX6okd9jo

Example good modules:
https://www.amazon.com/Samsung-memory-PC3-12800-1600MHz-Macbook/dp/B078HXSRXS/ref=sr_1_13?crid=1GZWPTZK89GQ4&keywords=laptop+ddr3&qid=1674133067&refinements=p_n_feature_four_browse-bin%3A2253866011%2Cp_n_feature_seven_browse-bin%3A24084330011%2Cp_36%3A-3500%2Cp_n_feature_browse-bin%3A23964008011&rnid=23963802011&s=pc&sprefix=laptop+ddr3%2Caps%2C217&sr=1-13

[BrianHG]

There is also Newegg...

[nockieboy]

Yes there's loads of sources to get SODIMMs from, I'm just hoping that the MIG in Vivado is able to create a memory controller that can handle the variety.  The MIG UI seems to require a very specific chip type to be input as part of the controller setup.

[BrianHG]

Use my example 'Good Module' from Amazon.  In the photo, they give you a Samsung part number.  Unless you go with the slowest possible DDR3 memory, all other single rank 4gb modules should work.  Changing the module to a smaller one should only reconfigure your controller setup and possibly make the upper address lines tied to GND.

[nockieboy]

Use my example 'Good Module' from Amazon.  In the photo, they give you a Samsung part number.  Unless you go with the slowest possible DDR3 memory, all other single rank 4gb modules should work.  Changing the module to a smaller one should only reconfigure your controller setup and possibly make the upper address lines tied to GND.

How do they work it in laptops and desktop computers that use SODIMM and DIMM modules with wildly varying capacities?  I have four 8GB sticks in my desktop, but could just as easily have used two 16GB sticks, or four 4GB sticks or whatever.  There must be some 'on-the-fly' configuration of the memory interface done by the BIOS?

EDIT: That 'Good Module' part number isn't listed in the MIG, so I'll have to create a custom part for it.  My question for asmi (or anyone else in the know) really was that if I do that, and I (or someone else) uses a different SODIMM with different part-numbered chips on it, will that break the interface or require adjustment of the Verilog and a recompile?

EDIT2: The M471B5173QH0-YK0 chips used on that 'Good Module' part are DDR3L, if that makes a difference.  At least with the datasheet, I can make an effort to create a custom part.

[BrianHG]

Try this part number: MT8KTF51264HZ-1G6E1

https://www.ebay.ca/p/215839569

It should match the Samsung module.
I wonder if these modules are just too fast to have an entry in your memory controller.
IE: if we just use the same module, but with a suffix for 1333Mhz, or 1066Mhz.

Also try:
MT8KTF51264HZ-1G9    1866MHz...

[asmi]

OK, so here is "everything you always wanted to know about memory but was afraid to ask":
1. DIMM modules contain a small EEPROM non-volatile memory which is called SPD (for "Serial Presense Detect", a name is a bit of a historical misnomer because there used to be a PPD - Parallel Presense Detect), which contain information about the module - supported mode, timings, voltage, etc. It uses an SMBus protocol, which is a variant of I2C bus. This is why DIMM requires 3.3 V power in addition to regular DDRx power like 1.5 V - that EEPROM device is powered by 3.3 V.
2. PCs and high-end SoCs read the SPD during early startup (when BIOS/UEFI is executing), and reconfigure memory controller to these specifications. Starting from DDR3, it includes a phase of "memory training", which adjust signal timings to ensure the best signal quality. However since that memory training can take a while (in case of DDR5 it can be minutes!), PCs typically save connected modules' "fingerprints" along with trained delay adjustments in the battery-backed memory - CMOS, this way after a power cycle they can check if connected DIMMs are still the same, and if so - they simply load and apply saved parameters, which is orders of magnitude faster than doing the training.
3. In contrast to PCs, FPGA systems typically don't presume changing DIMMs, and so they don't read SPD because it would be a waste of FPGA resources, instead all nessesary timings and delays are built into the controller HDL when it's configured for specific DIMM module.
4. As a result of (3), whenever you swap a module for another one, you will need to reconfigure your controller and generate a new bitstream, which would contain parameters of that new module.
5. The problem with modules you can buy in computer parts stores is that it's typically impossible to get your hands on datasheets for modules, and for memory devices used on that module, which makes it hard to figure out what timing parameters to use with an FPGA memory controller. Exception to this is Crucial, as it's wholly-owned by Micron and so all their modules use Micron's memory devices, datasheets for which are publicly available on a Micron's website. Micron itself also produces memory modules, but they are typically on a pricey side, though they do have a good reputation on a market.

Now onto specifics of our project:
1. Because of limitations on a MIG pinout for the part we have chosen, we can only use banks 16, 15 and 14 to implement a 64 bit memory controller.
2. However a byte group 0 of the bank 14 also contains pins used by FPGA during configuration - specifically pins D0-D3, and a chip select (CS) of a QSPI flash memory, which is where a bitstream is stored. And since flash memory which can be powered by 1.5 V does not exist, we will have to use a 1.8 V QSPI flash device and a voltage translators to convert between 1.5 V and 1.8 V. We can not use 3.3 V QSPI flash in this case.
3. As memory interface will consume pretty much the entirety of banks 14, 15 and 16, we will only have about 130 pins available from banks 34, 35 and partially-bonded out 13 for everything else. That is not a lot of pins.
4. Due to the large size of a resulting board (SODIMM is rather long, and needs to be placed far enough from FPGA to ensure sufficient clearance for a heatsink and a fan), and not many IO pins remaining available, I'm not really convinced that it's worth making it a module, as opposed to adding all peripherals with their interface connectors on that board, and only having a low-ish speed connector for other peripherals via regular 0.1" headers. That is something that we need to weigh against the costs of making a large baseboard/carrier which would accomodate such large module and some high-speed interfaces.
5. I have never personally implemented such a scheme with SODIMM and voltage translators, so there is an increased design risk that something can go wrong. I'm not saying it will, but I can't be 100% sure due to the lack of personal experience.

[nockieboy]

Try this part number: MT8KTF51264HZ-1G6E1

https://www.ebay.ca/p/215839569

It should match the Samsung module.
I wonder if these modules are just too fast to have an entry in your memory controller.
IE: if we just use the same module, but with a suffix for 1333Mhz, or 1066Mhz.

Also try:
MT8KTF51264HZ-1G9    1866MHz...

Both those chips are in the MIG controller setup and it would appear that creating a custom entry with timings from a datasheet is also pretty easy to do.

OK, so here is "everything you always wanted to know about memory but was afraid to ask":

Thanks for this asmi.   That makes a lot of sense having an I2C (or similar) chip on the SODIMM to tell the host what the memory timings are.  Also explains the I2C connections on the SODIMM connector.

Now onto specifics of our project:
1. Because of limitations on a MIG pinout for the part we have chosen, we can only use banks 16, 15 and 14 to implement a 64 bit memory controller.
2. However a byte group 0 of the bank 14 also contains pins used by FPGA during configuration - specifically pins D0-D3, and a chip select (CS) of a QSPI flash memory, which is where a bitstream is stored. And since flash memory which can be powered by 1.5 V does not exist, we will have to use a 1.8 V QSPI flash device and a voltage translators to convert between 1.5 V and 1.8 V. We can not use 3.3 V QSPI flash in this case.

Yes, that's a kick in the teeth.

3. As memory interface will consume pretty much the entirety of banks 14, 15 and 16, we will only have about 130 pins available from banks 34, 35 and partially-bonded out 13 for everything else. That is not a lot of pins.

Depends what you want to use on the carrier board.  My primary use-case and purpose for creating this board is to use it as a graphics card for a host computer, so 130 pins available for IO will just about do the job, I think.  70 for the host itself will still leave around 60 for other peripherals, such as USB, HDMI, audio codec, etc.

I could always create a core card without SODIMM for those that want something less memory-bandwidth and more IO orientated.

4. Due to the large size of a resulting board (SODIMM is rather long, and needs to be placed far enough from FPGA to ensure sufficient clearance for a heatsink and a fan), and not many IO pins remaining available, I'm not really convinced that it's worth making it a module, as opposed to adding all peripherals with their interface connectors on that board, and only having a low-ish speed connector for other peripherals via regular 0.1" headers. That is something that we need to weigh against the costs of making a large baseboard/carrier which would accomodate such large module and some high-speed interfaces.
5. I have never personally implemented such a scheme with SODIMM and voltage translators, so there is an increased design risk that something can go wrong. I'm not saying it will, but I can't be 100% sure due to the lack of personal experience.

After looking at the PCB initially, it doesn't appear that it will make a lot of difference to the size of the core card.  I haven't considered mounting points or clearance for a heatsink or fan yet, but a vertical SODIMM connector (or even a right-angle one if you're not worried about the SODIMM extending past the edge of the core card) shouldn't affect the layout too badly.

For me the biggest concern right now are making sure there's enough IO to go around.  SODIMM pros and cons:

Pros:
1. 64-bit interface instead of 32-bit with the alternative.
2. Ready-made cheap packages.
3. Simple connector to solder.  No extra BGAs to solder and termination and decoupling is a lot simpler.

Cons:
1. Say buh-bye to lots of IO.
2. Increased complexity in config circuit with level translators required for QSPI chip.
3. SODIMM's a bit on the big side.

The primary con (#1 - loss of IO) is negated primarily because you're trading IO for that 64-bit wide interface.  I don't know how #2 will bite until I look into that specific issue in more detail, and #3 is only of limited impact as the core card is already of a size to fit its essential components and the mezzanine connectors, which means it either doesn't need increasing in size at all, or only by a small margin, to fit the SODIMM socket.

I doubt I'll every be running Quake or Crysis on the thing using my Z80 system, but the further down this project I'm going, the more I'm considering using a soft-core processor to replace the 'host system' entirely, as I'm really enjoying learning about FPGAs and their flexibility; far more so than designing and putting together PCBs based on old/ancient technology from the 80's and 90's.

[nockieboy]

@asmi - what settings should I be specifying here?  I presume the Memory Options remain at default settings:




What about System Clock and Reference Clock?  Are these both single-ended or should I leave them set to 'Differential'?




Internal Termination for High Range Banks - guessing 50 Ohms is okay?

Here's the Bank Selection:




And finally System Signals Selection.  Not sure what do with Reference Clock Pin Selection - I can't select 'Use System Clock' for it and am unsure of the best selection if I'm going to run a separate reference clock in.  Presumably all the System Signals will run from the easiest-to-access pins in the same bank as the control signals?

[asmi]

After looking at the PCB initially, it doesn't appear that it will make a lot of difference to the size of the core card.  I haven't considered mounting points or clearance for a heatsink or fan yet, but a vertical SODIMM connector (or even a right-angle one if you're not worried about the SODIMM extending past the edge of the core card) shouldn't affect the layout too badly.

Take a look at banks layout in attachment. As you can see, SODIMM will need to be placed vertically along the right side of FPGA (because that's where banks 14, 15 and 16 are). Now let's figure out where board-to-board connectors are going to be. We have banks 34, 35 (on the left side), bank 13 (on the bottom), and the MGT bank 216 (on the top). So where would you place those connectors? The logical place seems to be along the top and bottom sides. But in this case right sides of those connectors might have trouble finding space because DDR3 layout typically takes up a lot of space. It also means that the board needs to be at least ~75 mm tall to accomodate SODIMM connector (it's footprint is 75x36 mm with memory module connected and secured), and at least 53 mm wide to accomodate board-to-board connectors, in reality likely significantly wider than that so as for connectors to not interfere with DDR3 layout. Leaving SODIMM hanging off the edge is a bad idea mechanically. With added margins to both sides of SODIMM connector (you will probably have some traces there as well), the board size is going to encroach onto the "magic" size of 10x10 cm, which is the point at which the cost of manufacturing will start raising quite a bit. This also increases the size of a carrier board, which will need to have at least 4 layers because of impedance requirements for high-speed lines, so manufacturing cost for it is going to be significant (even if it's going to be a one-time investment as they can be reused).

I doubt I'll every be running Quake or Crysis on the thing using my Z80 system, but the further down this project I'm going, the more I'm considering using a soft-core processor to replace the 'host system' entirely, as I'm really enjoying learning about FPGAs and their flexibility; far more so than designing and putting together PCBs based on old/ancient technology from the 80's and 90's.

That is a long overdue in my opinion
Besides, you can design your own softcore CPU for lots of additional fun! Even if you only manage to make it run at "pedestrian" 50 MHz, that is still head and shoulders above what Z80 can do.

[asmi]

Please select the "SODIMMs" -> "MT16KTF1G64HZ-1G6" as you module of choice. This is an 8GB dual-rank module, which will be pretty much the maximum possible configuration, and we should do a layout for that. As smaller modules are backward-compatible, you can use pretty much any other 64bit non-ECC module by just updating MIG configuration for a specific one you happen to have, and layout will still work.

@asmi - what settings should I be specifying here?  I presume the Memory Options remain at default settings:

Nope - select "5000 ps (200 MHz)" option.

What about System Clock and Reference Clock?  Are these both single-ended or should I leave them set to 'Differential'?

Leave "differential" for the system clock, and select "Use System Clock" option for the reference clock - this option will appear once you set Input Clock Period to 200 MHz on a previous page.

Internal Termination for High Range Banks - guessing 50 Ohms is okay?

Yes it is.

Here's the Bank Selection:

That's a good initial selection. We might need to swap byte groups around later for layout reasons.

And finally System Signals Selection.  Not sure what do with Reference Clock Pin Selection - I can't select 'Use System Clock' for it and am unsure of the best selection if I'm going to run a separate reference clock in.  Presumably all the System Signals will run from the easiest-to-access pins in the same bank as the control signals?

If you do everything exactly as I said above, you will have only one option for the System Clock Pin Selection in bank 15 - K18/K19, which is what you should select, and the "Reference Clock Pin Selection" controls will be greyed out, so you don't have to select anything there.

[nockieboy]

Take a look at banks layout in attachment. As you can see, SODIMM will need to be placed vertically along the right side of FPGA (because that's where banks 14, 15 and 16 are). Now let's figure out where board-to-board connectors are going to be. We have banks 34, 35 (on the left side), bank 13 (on the bottom), and the MGT bank 216 (on the top). So where would you place those connectors? The logical place seems to be along the top and bottom sides. But in this case right sides of those connectors might have trouble finding space because DDR3 layout typically takes up a lot of space. It also means that the board needs to be at least ~75 mm tall to accomodate SODIMM connector (it's footprint is 75x36 mm with memory module connected and secured), and at least 53 mm wide to accomodate board-to-board connectors, in reality likely significantly wider than that so as for connectors to not interfere with DDR3 layout. Leaving SODIMM hanging off the edge is a bad idea mechanically. With added margins to both sides of SODIMM connector (you will probably have some traces there as well), the board size is going to encroach onto the "magic" size of 10x10 cm, which is the point at which the cost of manufacturing will start raising quite a bit. This also increases the size of a carrier board, which will need to have at least 4 layers because of impedance requirements for high-speed lines, so manufacturing cost for it is going to be significant (even if it's going to be a one-time investment as they can be reused).

Okay, so mezzanine connectors top and bottom, SODIMM socket to the right.  I'm thinking a vertical SODIMM is best due to space constraints.  Until I know the final BOM for the core card and start routing it all on the PCB, it's hard to put an exact estimate on the finished PCB's size, but there's no parts-based reason why the core card can't be less than 100x100mm - in fact, 90x70mm is looking generous at this very early stage.

I doubt I'll every be running Quake or Crysis on the thing using my Z80 system, but the further down this project I'm going, the more I'm considering using a soft-core processor to replace the 'host system' entirely, as I'm really enjoying learning about FPGAs and their flexibility; far more so than designing and putting together PCBs based on old/ancient technology from the 80's and 90's.

That is a long overdue in my opinion
Besides, you can design your own softcore CPU for lots of additional fun! Even if you only manage to make it run at "pedestrian" 50 MHz, that is still head and shoulders above what Z80 can do.

Indeed.  Well, it's all this talk from BrianHG about what we could do with a 16-bit (or better) CPU at the helm.  I've had a very enjoyable stroll down memory lane designing, building and even teaching myself assembly for my Z80 DIY computer, but it seems this GPU project has taken on a life of its own, with an awful lot of potential.  My biggest concern at the moment is that its capabilities are already outstripping my programming skills - and certainly my free time - to do it justice.  So switching to a more generic 'development board' PCB and eliminating the need for specialist hardware (my uCOM Z80 host) means anyone could create a board, download the project and have a working games machine of some description.

Nope - select "5000 ps (200 MHz)" option.

Hmm - I can't.  The highest value allowed is 3,300 ps.  If I switch to DDR2 SDRAM in the memory selection, it will allow a value of 5,000 ps, but I thought we were looking at DDR3 SODIMMs?