FPGA VGA Controller for 8-bit computer

[nockieboy]

Latest project update after rotating the FPGA and re-assigning IOs accordingly.  Hopefully I've not introduced any more errors.  The 'diagram' sheet in the spreadsheet shows the physical layout of the IOs.

[BrianHG]

That seems to have cleared up the RAM issue, I'm now getting this bizarre set of errors:


Error (16722): The SEU internal scrubbing feature is only supported for select Cyclone V and Cyclone V SoC devices. Contact your Intel sales representative for information on these devices and access to the SEU internal scrubbing feature.
Error (11802): Can't fit design in device. Modify your design to reduce resources, or choose a larger device. The Intel FPGA Knowledge Database contains many articles with specific details on how to resolve this error. Visit the Knowledge Database at https://www.altera.com/support/support-resources/knowledge-base/search.html and search for this specific error message number.


Analysis & Synthesis completes and the Flow Summary shows 24% logic utilisation and 11% of memory bits used, so I suspect the second error to be an error in itself.  The first one, though, is proving troublesome for me to find a solution to.  (Compilation fails on the Fitter (Place & Route) stage).

Just turn off the 'The SEU internal' 'Enable Internal Scrubbing' feature in the 'Device and pin options' / 'Error detection CRC'.

Also, you need to define all the IO.
Also, that 250MHz for larger core ram will be a little difficult to obtain.  We'll need to add code.  Also, unfortunately, that timing is still tight, so I recommend using a -C7 even though you may be mounting a -C8.

[BrianHG]

Latest project update after rotating the FPGA and re-assigning IOs accordingly.  Hopefully I've not introduced any more errors.  The 'diagram' sheet in the spreadsheet shows the physical layout of the IOs.

DDR pinouts:
Move DDR_D6 off of pin G12.
All the DDR_D# signals need to be on ####,DQ2R pins.
Place DDR_RWDS signal needs to be on a #####,DQS pin.
CS#, RST, can go anywhere.
Obviously, the CK# need to be on the PLL pins.

[nockieboy]

Just turn off the 'The SEU internal' 'Enable Internal Scrubbing' feature in the 'Device and pin options' / 'Error detection CRC'.

How did I miss that?  That 'Device and pin options' button is too easily missed.   It compiles now.

Also, you need to define all the IO.
Also, that 250MHz for larger core ram will be a little difficult to obtain.  We'll need to add code.  Also, unfortunately, that timing is still tight, so I recommend using a -C7 even though you may be mounting a -C8.

I just wanted to see if it would compile first - will assign all the IO to pins when we're comfortable with the layout, otherwise I'll be updating schematics, spreadsheets and the Quartus project for every pin change I make.

DDR pinouts:
Move DDR_D6 off of pin G12.
All the DDR_D# signals need to be on ####,DQ2R pins.
Place DDR_RWDS signal needs to be on a #####,DQS pin.
CS#, RST, can go anywhere.
Obviously, the CK# need to be on the PLL pins.

All done. I'd been focusing on trying to make the routing as simple as possible - well, relatively speaking.  I'm a little anxious about trying to get this all connected up.

That said, I'm also aware there I've got spare IOs left over - two in Bank 3B at the bottom edge, 1 in 8A on the top and 13 in 7A on the top edge (ignoring the two in 5B as they're 1.8V and that's dedicated to the DRAMs - I guess, in theory at least, I could add another two DRAMs using those last two IOs as chip selects).

Any ideas what I could use the remaining IO for?  (Bearing in mind I'm likely to have the Cyclone V assembled on the PCB at the factory, rather than do it myself, so I'm hoping I won't need spare IOs 'just in case'.)  Hmm... what about EEPROM, or some other non-volatile memory?  Could use that as a drive, or bootstrap ROM for a soft-core CPU.  It could then almost literally be a standalone system on a PCB (still needs power via the system bus). Hmmm...

[BrianHG]

Again:
Place DDR_RWDS signal needs to be on a #####,DQS pin.

Also, find out why pin J16 is red.  You may not be able to place pin D4 on it...

Separate VCC_AUX and VCC_FPLL.  The VCC_AUX are digital power and the VCC_FPLL powers the analog PLL circuitry.

Also, the power to pin H14 is wrong.  Shouldn't it be going to VCC_DDR?

VCC_DDR needs another 3 100nf decoupling caps for the FPGA power pins.

Also, place CLKUSR to CLK10p/n on bank 7A.

Move DAC_CLK to a dedicated PLL CLK output pin.  Down 2-3 pins...

Are you sure you do not want to power your 245's with the VCCIO?

Also, why aren't you using SCK for the audio DAC?
You also hardwired the DAC features, are you sure this is what you want?

Next step, paint a grid of vias inbetween all the BGA pins, make 45 degree connections outwards to all pins.   This is unless you have a pre-made 'FAN-OUT' structure which draws out all the IOs on 4 layers.

[nockieboy]

Again:
Place DDR_RWDS signal needs to be on a #####,DQS pin.

Also, find out why pin J16 is red.  You may not be able to place pin D4 on it...

Sorry, missed that.  As for J16, no idea why it's red, other than perhaps it needs configuration in Quartus to set its function as an IO?  It dual-purpose - I/O or a Configuration via Protocol status output.

Separate VCC_AUX and VCC_FPLL.  The VCC_AUX are digital power and the VCC_FPLL powers the analog PLL circuitry.

When you say 'separate', you mean want another linear regulator supply or some other (less traumatic) change? 

Also, the power to pin H14 is wrong.  Shouldn't it be going to VCC_DDR?

Apparently not.  I've checked and double-checked.  According to the Altera docs and pin connection guide, if a bank's VCCIO is below 2.5 volts, its VCCPD should be 2.5V.  So instead of connecting VCCPD5B to VCC_DDR, I've connected it to VCC_FPLL.  It should probably be connected to VCC_AUX instead, actually...

Also, place CLKUSR to CLK10p/n on bank 7A.

Okay, done that - what's the thinking behind this move though?  CLKUSR was on the dedicated CLKUSR input pin.  I assume there won't be any issues with the 50 MHz clock input going in via the new pin in Bank 7A?

Move DAC_CLK to a dedicated PLL CLK output pin.  Down 2-3 pins...

Done.

Are you sure you do not want to power your 245's with the VCCIO?

Hadn't really thought about it to be honest.  I've got a 3.3V supply on the system bus, I was just making use of it.  I suppose from a power-rail-consolidation point of view, it'd be good to use VCCIO instead.  Or I could use VCCIO to power the two 245's on the right hand side of the board to save routing another 3.3V net across the board...

Also, why aren't you using SCK for the audio DAC?
You also hardwired the DAC features, are you sure this is what you want?

Not using SCK to save IOs (I made that decision before I knew that I'd have nearly a whole bank of free IOs) and to simplify the interface to the PCM5101.  Clearly, IO usage is not a problem now so if you think using SCK would make for an easier HDL interface, I'll add it in.

As for hardwiring the features - that was purely because I didn't think that I'd want to change features, or have room to add in lots of configuration links.

Next step, paint a grid of vias inbetween all the BGA pins, make 45 degree connections outwards to all pins.   This is unless you have a pre-made 'FAN-OUT' structure which draws out all the IOs on 4 layers.

Just normal through vias, yes?  What about the last row on the right and bottom?  I guess I'll get rid of vias around the edges where the first and maybe second rows into the FPGA can be connected on the surface?

[BrianHG]

Again:
Place DDR_RWDS signal needs to be on a #####,DQS pin.

Also, find out why pin J16 is red.  You may not be able to place pin D4 on it...

Sorry, missed that.  As for J16, no idea why it's red, other than perhaps it needs configuration in Quartus to set its function as an IO?  It dual-purpose - I/O or a Configuration via Protocol status output.

Separate VCC_AUX and VCC_FPLL.  The VCC_AUX are digital power and the VCC_FPLL powers the analog PLL circuitry.

When you say 'separate', you mean want another linear regulator supply or some other (less traumatic) change? 

No, You have a LC filter on your power supply so the PLLs do not inject a signal backwards, or the digital won't send EMI back into the PLL power input.  Just use the 2 you supplies you already created.  You even labeled the 2 yourself.

Also, the power to pin H14 is wrong.  Shouldn't it be going to VCC_DDR?

Apparently not.  I've checked and double-checked.  According to the Altera docs and pin connection guide, if a bank's VCCIO is below 2.5 volts, its VCCPD should be 2.5V.  So instead of connecting VCCPD5B to VCC_DDR, I've connected it to VCC_FPLL.  It should probably be connected to VCC_AUX instead, actually...

[ Attachment Invalid Or Does Not Exist ]

Ok.

Also, place CLKUSR to CLK10p/n on bank 7A.

Okay, done that - what's the thinking behind this move though?  CLKUSR was on the dedicated CLKUSR input pin.  I assume there won't be any issues with the 50 MHz clock input going in via the new pin in Bank 7A?

A CLK# input pin on bank A7...  I think CLKUSR is for a custom bootprom clock speed.

Move DAC_CLK to a dedicated PLL CLK output pin.  Down 2-3 pins...

Done.

Are you sure you do not want to power your 245's with the VCCIO?

Hadn't really thought about it to be honest.  I've got a 3.3V supply on the system bus, I was just making use of it.  I suppose from a power-rail-consolidation point of view, it'd be good to use VCCIO instead.  Or I could use VCCIO to power the two 245's on the right hand side of the board to save routing another 3.3V net across the board...

Use the VCCIO for all of them.  If the FPGA has no power and you send 3.3v to the 245, they will push voltage into the 'expensive' FPGA IOs.

Also, why aren't you using SCK for the audio DAC?
You also hardwired the DAC features, are you sure this is what you want?

Not using SCK to save IOs (I made that decision before I knew that I'd have nearly a whole bank of free IOs) and to simplify the interface to the PCM5101.  Clearly, IO usage is not a problem now so if you think using SCK would make for an easier HDL interface, I'll add it in.

As for hardwiring the features - that was purely because I didn't think that I'd want to change features, or have room to add in lots of configuration links.

Use SMD jumpers for the features...

[BrianHG]

Ok, for the PCB, take a look at the first image.  Here is what I want you to do.

Taking a look at my second image, this is also a 1mm BGA, except 484pin.  As you can see I started with the 'VIA Grid', then erased the signals I was able to feed out on the top layer alone while erasing the vias which were no longer needed.
Pay attention to the VIA properties.  Use the same & verify that JLPCB can build these with their basic bottom end 4 Layer technology.  I made the power & GND are using .25mm tracks while the signals use 0.101mm tracks.  As you can see, you can fit 2 tracks between pads with .101mm and only 1 with 0.25mm.

Looking at my third image, you can see the clearance constraints I used which should allow those 2- 0.101mm tracks between pads and also I use a larger spacing for the GND fill to ease PCB copper spacing where not needed.  Again verify with JLPCB.

I do not know if the smallest cheap PCB JLPCB tracks & spacing would allow for 3 tracks between pads, but if it does, this could simplify quite a bit.  But stretching for the tightest tolerances isn't always the best solution manufacture-ability or having the most sturdy design...

Note that the decoupling caps are 0402 on the bottom of the PCB.
Also, I do not have as many for the VCCINT as you have.
However, you will need to see your FPGA power layout to decide where to place these caps.
It may just be a decision on which 4 possible directions the VIAS go leaving a channel / room underneath for the 0402 caps to be lined up under the FPGA.  something like a + pattern through the middle and also a box around the outside of those core PWR/GND vias.

[nockieboy]

Okay, so my takeaway from your post is to use vias and traces that are almost at the limits of what JLCPCB can do with a 4-layer PCB with a safety margin (I've used 5 mil to connect the BGA pads with the vias, but the vias are minimum size for the PCB manufacturing tech) and start routing the FPGA to the rest of the board.

Two questions - in terms of routing, is it best to start at the centre and work my way out?

Secondly, should I do the same thing with the DRAMs (with vias etc) or should I just route these on the top layer?

Third (bonus) question - I'm starting the routing on the top layer?  Currently the PCB design only has two layers.  I've used the top layer exclusively so far (except where two power traces cross).  I was considering using the top layer to route power and initial 5V signals from the bus headers, and maybe to route signals as far as I can?

I'm thinking this would be an okay PCB stack-up?

TOP:       Power/some signals
LAYER 2: GND
LAYER 3: GND
BOTTOM: Power/some signals

Attached is the base FPGA breakout plan on the PCB.  I've divided it into four quadrants, as per your example, and will start routing out in the next day or two.

In the meantime - is there anything I can do with the remaining IOs in Bank 7A?

[BrianHG]

I'm thinking this would be an okay PCB stack-up?

Use my first illustration as it creates that big + shaped void inside the FPGA once you remove the unused vias in the middle.  You can place core 0402 decoupling caps inside the + channel under the FPGA.  Also, once the unused outer vias around the center are removed, you can place more decoupling caps around that border.  You can change all the 100nf and 4.7nf to 100nf.  Your app wont need so much filtering + add a few 10uf 0603/0805 around the FPGA, like 4 of them.

TOP :       signals - maybe odd/single outer edge PCB power trace if needed to jump for 1 of the multiple internal power.
LAYER 2: GND, ALL GND
LAYER 3: Multiple Power, an odd data signal, best avoided.
BOTTOM: signals - maybe odd/single outer edge PCB power trace if needed to jump for 1 of the multiple internal power.

For the ram, you want the same VIA count for every signal going to and from the FPGA to both ram chips.
If this can be done all on the top layer without running rings around the ram, then fine.  I suspect you will need to go from the FPGA to the bottom layer once (or a mid layer), then, to the top layer once between the 2 chips.  The only signal you can get away with poor routing is the reset signal.  You want to keep everything short and equal number of vias between the FPGA and RAM so you will not need to do sophisticated time-delay corrections due to unusual signal paths.  You will be operating the ram at 250MHz max and we are just below the border where adding length corrections to each trace will become necessary.  Having 1 IO only feed 2 IC data IO have kept this short and sweet which will let you get away with this.  Without a good fast logic analyzer or scope on your side, you will be slave to simulation, simulation, simulation, tune PLL output CLK phase and tune PLL read CLK phase, adjusting voltages and temperature, re-tune the PLL CLK phase...

Remember, you still have a lot of pin-swapping to do to straighten out those ram signals.

[BrianHG]

In the meantime - is there anything I can do with the remaining IOs in Bank 7A?

You can add a second serial boot-prom, which is basically a gigantic flash ram.
Maybe use it as an onboard Z80 OS, or HD.
Power-up graphics & fonts for the GPU outside the 256kb inside-FPGA GPU ram.
Audio clips/fonts.
At 1-3$, it's kind of worth it.

Maybe, with some 74HC logic (parallel to serial and 8bit ADC to read the old Atari/Comodore style Joysticks), you can add 2-4 joystick ports.
Ok maybe find a USB host IC so you can attach simple HID devices like USB KB, Mouse, Game-pad.

[nockieboy]

Remember, you still have a lot of pin-swapping to do to straighten out those ram signals.

Ah, I forgot to upload the latest schematic!

You can add a second serial boot-prom, which is basically a gigantic flash ram.
Maybe use it as an onboard Z80 OS, or HD.
Power-up graphics & fonts for the GPU outside the 256kb inside-FPGA GPU ram.
Audio clips/fonts.
At 1-3$, it's kind of worth it.

Maybe, with some 74HC logic (parallel to serial and 8bit ADC to read the old Atari/Comodore style Joysticks), you can add 2-4 joystick ports.
Ok maybe find a USB host IC so you can attach simple HID devices like USB KB, Mouse, Game-pad.

Well, that's what I was thinking - using a flash RAM or something as a drive of some kind.  I like the USB host IC idea though - a lot.  Any suggestions on what IC to look at for that functionality?

EDIT: MAX3421E looks good, if a little expensive.

[BrianHG]

[nockieboy]

   Ah, that's what you meant by separating the FPLL and IO nets... 

(Ignore the MAX3421E on the Peripherals page - I've not finished wiring it up and am not 100% I'll use it yet...)

[BrianHG]

You cannot short the SDA and SCL of the HDMI & VGA port.  The 2 different EDID proms will interfear with each other.  Since you are only using 640x480, just ignore the VGA port's EDID lines.

[BrianHG]

Your SDA & SCL also seem to go to the Z80 bus.  Careful, the EDID usually is handled through the HDMI transmitter.  And, if your HDMI TFP410 has an I2C port with controls in it, it may be a different SDA & SCL.  Especially if you need to set I2C controls for the TFP410, if should be driven by the FPGA and have no connection to the EDID lines as those are 5v signals and need protection.  If the TPF410 has no I2C controls and the SDA/SCL is intended for the HDMI port, then those need to be wired there exclusively.

[asmi]

LOL It's been a while since I looked a this thread. But it turns out I was right that this is not going to be a "get it done and go home" kind of project, but rather perpetual WIP Too bad you're still choosing crappy Antel FPGA instead of real deals, which is what Xilinx devices are. But you will get there eventually This will save you about 100500 pins and TFP410 because real FPGAs can drive HDMI out directly with no crutches required.

[BrianHG]

LOL It's been a while since I looked a this thread. But it turns out I was right that this is not going to be a "get it done and go home" kind of project, but rather perpetual WIP Too bad you're still choosing crappy Antel FPGA instead of real deals, which is what Xilinx devices are. But you will get there eventually This will save you about 100500 pins and TFP410 because real FPGAs can drive HDMI out directly with no crutches required.

At 250MHz HDMI for VGA, so can the Intel.  Every single IO bank on the entry CycloneV has enough LVDS transmitters for HDMI up to 600-800MB/S, or 3-6gb/sec on fewer dedicated channels.  Nockieboy wants both analog VGA and HDMI (so, more pins, not less) and he doesn't want to debug any third party DVI transmitter code.  (Yes, Since Altera was bought by Intel, their devices have stagnated.  Soon, with AMD's purchase of Xilinx, they will slow down as well but remain ahead as Intel flounders.)

[nockieboy]

Making slow progress - must admit, I'm having difficulty routing those DRAMs.  I've only done the basics so far, trying to stick to the top layer, but can't see how I can go further without going down to the bottom layer for crossing signal nets which - if I've understood previous posts correctly - means I have to do the same for ALL of the data lines?



I've routed the Z80 data bus - that seems to be a success, hopefully.  I'm using 5mil traces at the moment, with 10mil traces for GND and all the VCC### nets.



0402 caps? Can they even be hand-soldered?!   Looks like another opportunity to push the limits of my soldering skills (and I thought 0603 was small!) 

LOL It's been a while since I looked a this thread. But it turns out I was right that this is not going to be a "get it done and go home" kind of project, but rather perpetual WIP Too bad you're still choosing crappy Antel FPGA instead of real deals, which is what Xilinx devices are. But you will get there eventually This will save you about 100500 pins and TFP410 because real FPGAs can drive HDMI out directly with no crutches required.

Intel/Altera was the first manufacturer of FPGAs (and the Cyclone range) that I became aware of when I learned of their existence shortly before starting this thread, as Grant Searle used one for his multicomp project.  That was then reinforced by the wealth of help and assistance on offer from BrianHG who clearly has a lot of experience using Cyclones, so I've stuck with them not for any reason other than (now) familiarity and they allow me to make the most of BrianHG's knowledge and support.

There are undoubtedly better FPGAs out there - even in the Intel\Altera lineup - but I'm not precious about squeezing every last feature and drop of power out of the best FPGA I can get my hands on.  I'm just happy with enough RAM for a frame buffer and everything else is a bonus. 

[asmi]

At 250MHz HDMI for VGA, so can the Intel.  Every single IO bank on the entry CycloneV has enough LVDS transmitters for HDMI up to 600-800MB/S, or 3-6gb/sec on fewer dedicated channels.  Nockieboy wants both analog VGA and HDMI (so, more pins, not less) and he doesn't want to debug any third party DVI transmitter code.  (Yes, Since Altera was bought by Intel, their devices have stagnated.  Soon, with AMD's purchase of Xilinx, they will slow down as well but remain ahead as Intel flounders.)

Lol. 7 series can officially do 1250 Mbps on every single diff pair, and almost 1500 Mbps HDMI unofficially (I'm yet to see a device that can't actually do that, but it's beyond datasheet values), it's BRAM are faster, and DSP tiles are over 2 times faster. But it's also about software. What about free DDRx controller from Antel? DMA controller (with or without SG support)? Softcore (NIOS is only free it's most useless configuration, so it doesn't count)? What about other 100+ IPs which are available for free from Xilinx?
Sorry, but from my experience the only people who use Antel devices are those who never used 7 series. I've never met a designer that used Xilinx FPGA and then voluntarily went back to Antel. Xilinx devices are just better in every single possible way.
And I don't understand your passage about third party DVI transmitter code. Writing your own basic RGB24->HDMI for 7 series takes about 30 minutes from scratch, so there is no point in using someone else's code (unless you really want to).

[asmi]

Making slow progress - must admit, I'm having difficulty routing those DRAMs. 

Hyperbus clock line is a differential pair and must be routed as such. On your picture it looks like it's routed as two independent traces.
Also a bunch of long parallel traces so close to each other is crosstalk magnet. Try spreading them around.
Do you do your layout in KiCAD? If so, do you have your project published anywhere? I can take a look and help if necessary/desired. I love routing. It's my favorite part of the design process.

0402 caps? Can they even be hand-soldered?!   Looks like another opportunity to push the limits of my soldering skills (and I thought 0603 was small!) 

Don't worry, if you've got proper equipment (microscope), you can manually solder even 0201. I've done quite a bit of them, though I prefer reflowing.

Intel/Altera was the first manufacturer of FPGAs (and the Cyclone range) that I became aware of when I learned of their existence shortly before starting this thread, as Grant Searle used one for his multicomp project.  That was then reinforced by the wealth of help and assistance on offer from BrianHG who clearly has a lot of experience using Cyclones, so I've stuck with them not for any reason other than (now) familiarity and they allow me to make the most of BrianHG's knowledge and support.

That is consistent with the point I made above. The only people who choose Antel voluntarily are those who never used Xilinx 7 series. Once you do, you will never want to go back.

[BrianHG]

Ok, some hints about the ram.  Since the ram has 5 columns across and you cannot squeeze more than 2 traces between pads and you need at least 4, you need to approach this differently.

Step 1, remove the traces you have.
Step 2, make the ram like the FPGA with a via-grid, removing the power pins vias and NCs.
Step 3, on the bottom layer, parallel the left side of the 2 rams.
Step 4, on the power layer, parallel the right side of the rams.
Step 5, (vias replaced for FPGA which you now have routed on the top of the PCB), route the left side of the rams to the FPGA through the bottom layer.
Step 6, Route the right side of the rams to the FPGA on the power layer.

Now, I know that only 1 trace can only fit between vias, this is why you need to use 2 signal layers.  Always use a via from FPGA to new layer, then new layer to ram chip so that each ram IO signal always goes through 2 vias from FPGA to each RAM IC pin.

Step 7, on top layer, wire the ram power and decoupling caps and associated VIAS which will be outside that small island of signal traces you had to make on the power layer.  Look at the FPGA as it also has 2 power pins shared with the ram.  Make sure you can route a thick trace for this, thick meaning 50-150mil.

I hope this helps.

EDIT: Yes, the differential clock trace pair needs to be parallel and equal length to maximize signal quality and integrity throughout the system.  These 2 signals may also be wired exclusively on the top layer if you like as well as the reset and RDWS signal.  This will help clear up the middle layers as there are only 9 traces left.  Everything else may now fit on the bottom layer.

[BrianHG]

And I don't understand your passage about third party DVI transmitter code. Writing your own basic RGB24->HDMI for 7 series takes about 30 minutes from scratch, so there is no point in using someone else's code (unless you really want to).

Yes, me, if I had a board here and I built it, no problem.  I know how to work on these things.  Nockieboy has an analog 25MHz scope and a single computer monitor and FPGA code is a brand new type of development for him as he learned some bottom end basics through this project as it has now rocketed to a point he never imagined that not only he now has a blitter, but it can combine any mirror/flip/rotate 90 & 45 degrees while up-sampling and down-sampling the image with programmable transparency stencils, pixel collision counter and testers all with a geometry shape engine with support and smart testing & memory write protection for pixel areas off screen.  (Well, he still need to add the last shape, filled ellipse)

I did push awhile back for home-made DVI transmitter, but Nockieboy felt at better ease using the TFP410.
Look way back on this thread and I found a public domain HDMI transmitter with audio support written in Verilog for both Intel and Xilinx.

[asmi]

The way I like to do routing is as follows:
1. Fanout the chips into a bunch of parallel tracks close to the chip going in the general direction of the target.
2. Bring both bunches of tracks close to each other.
3. Utilize pin swapping to get those bunches to match each other and connect them together, starting from clock and DQS lines if present (as these are the most critical). If for some reason that is not fully possible - for example, there are some hardwired pins involved which can't be swapped around, you can typically see how do you need to change a fanout on one or both sides to get tracks to align.
4. Spread parallel tracks around a bit and do the length matching if required.

Clock (and DQS if present) lines usually needs to be the longest lines in a match group, so leave plenty of space for them. You can tighten up layout later if desired.

Now, I know that only 1 trace can only fit between vias, this is why you need to use 2 signal layers.  Always use a via from FPGA to new layer, then new layer to ram chip so that each ram IO signal always goes through 2 vias from FPGA to each RAM IC pin.

Isn't it 1mm pitch BGA? If so, and you guys plan to use JLCPCB to manufacture boards, you can easily fit two tracks between vias in a 1 mm grid. Use 0.2/0.45 via and 0.1 mm tracks/spacing, or - better yet - 0.09 mm tracks/spacing and center two tracks closer to the middle of the channel between vias, this way you will make manufacturing easier as even if drill misses a bit, there will be enough clearance between via and tracks to not cause any problems.

EDIT: Yes, the differential clock trace pair needs to be parallel and equal length to maximize signal quality and integrity throughout the system.  These 2 signals may also be wired exclusively on the top layer if you like as well as the reset and RDWS signal.  This will help clear up the middle layers as there are only 9 traces left.  Everything else may now fit on the bottom layer.

You will also need to calculate proper line dimensions (and gap size for diff. pairs) if you care about signal integrity. And at 200 MHz DDR, you probably should. Again, if you plan to use JLCPCB, they've got a calculator on their website. I recommend using their JLC2313 stackup as it's much better for high-speed designs (prepreg is thinner and so 50 Ohm impedance lines can be narrower).

[asmi]

Yes, me, if I had a board here and I built it, no problem.  I know how to work on these things.  Nockieboy has an analog 25MHz scope and a single computer monitor and FPGA code is a brand new type of development for him as he learned some bottom end basics through this project as it has now rocketed to a point he never imagined that not only he now has a blitter, but it can combine any mirror/flip/rotate 90 & 45 degrees while up-sampling and down-sampling the image with programmable transparency stencils, pixel collision counter and testers all with a geometry shape engine with support and smart testing & memory write protection for pixel areas off screen.  (Well, he still need to add the last shape, filled ellipse)

You will probably be surprised to hear that, but I've developed my very first DVI TX module that output 720p without any scope. And even now I only have a 200 MHz scope, which is utterly useless for debugging HDMI (1450 Mhz for data lines at FullHD). And that also was back in time when my experience with FPGAs was very rudimental. Now, I did have a formal training for HDLs back at university (about 15 years ago), so that helped in a sense that I was familiar with the design process, but I never had any formal training using FPGAs (we used ASIC tools back at UNI).

I did push awhile back for home-made DVI transmitter, but Nockieboy felt at better ease using the TFP410.
Look way back on this thread and I found a public domain HDMI transmitter with audio support written in Verilog for both Intel and Xilinx.

Do you happend to have a link? I would be curious to see the one for Antel devices.