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).
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.
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.
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.
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?
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.
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...
[ Attachment Invalid Or Does Not Exist ]
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.
I'm thinking this would be an okay PCB stack-up?
In the meantime - is there anything I can do with the remaining IOs in Bank 7A?
Remember, you still have a lot of pin-swapping to do to straighten out those ram signals.
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.
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.
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.)
Making slow progress - must admit, I'm having difficulty routing those DRAMs.
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!)
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.
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).
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.
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.
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.