FPGA VGA Controller for 8-bit computer

[BrianHG]

Remember, the ram needs access to the dedicated differential PLL outputs.
Also, you need to squeeze everything into 1 IO bank since it will be run at a lower voltage.  You need to check, the PSRAM may work on 2.5v when operated at 250MHz, otherwise, you will want 1.8v.
This means the same IO bank with the dedicated PLL outputs will also need to be at the lower voltage.

Make sure the other 11 data lines are on DDR-DQ IO pins.

First, find a 250MHz PSRAM hyperbus or similar ram chip.

Some hyperbus rams allow interleaving on 1 bus, for those, you only need 14 IOs total saving a bunch...
Look for those so everything can fit in 1 bank.

[nockieboy]

Remember, the ram needs access to the dedicated differential PLL outputs.
Also, you need to squeeze everything into 1 IO bank since it will be run at a lower voltage.  You need to check, the PSRAM may work on 2.5v when operated at 250MHz, otherwise, you will want 1.8v.
This means the same IO bank with the dedicated PLL outputs will also need to be at the lower voltage.

Make sure the other 11 data lines are on DDR-DQ IO pins.

First, find a 250MHz PSRAM hyperbus or similar ram chip.

Some hyperbus rams allow interleaving on 1 bus, for those, you only need 14 IOs total saving a bunch...
Look for those so everything can fit in 1 bank.

Thought I'd have a quick look as I have a spare 5 minutes for these RAM chips you've mentioned, but damned if I can find anything relevant anywhere other than on DigiKey.   

Do you mean something like this S27KL0642GABHI030?

[BrianHG]

Yup, this is the cheapest and it's available everywhere:

https://www.arrow.com/en/products/s27ks0642gabhi030/cypress-semiconductor
Everyone has it, not just Digikey, see here:
https://www.findchips.com/search/S27KS0642
NOTE: The S27KS0642xxx020 variant is usually cheaper and available at more distributers...  Use that one instead.  There will be slight firmware changes depending on how you write the controller.

200 MHz is the limit and that's fine since the Cyclone V has enough PLLs, however your core multiport ram clock is 250MHz and it would be nice to run these at 250MHz.  You will need to add a linear 1.8v regulator as they require this voltage.  Make it adjustable as I believe we will be running them at ~2v-2.25v to squeeze out that 250MHz error free.

8bit bus at 500MTPS = 16bit data at 250MHz, same width and speed of your core ram meaning a 1:1 transfer rate.

You will probably configure this ram as 8 or 16bit graphics background screen only.  Meaning the 15 MAGGIE layers will be above it's display while this ram will be Maggie layer 16.  You will be able to use the blitter for text on this layer and have 15 dedicated sprite layers which will have access to the core 350Kb.

Audio will also be stored on this ram.  You will have 16 megabytes to play with using 2 chips.

If you make a smart flash DMA controller, I do not know about the flash speed, but you should be able to fill this ram at around 50 megabytes a second.  This means uncompressed 320x240 16bit avi @60fps video with sound playback is possible so long as the flash can keep up.  Almost no CPU overhead.  30fps will be easy-peasy.


Looking at the numbers, with the worst possible delay, you will just make it clear to guarantee that Z80 access will never have any wait states no matter what else the ram will be doing in the system, however, just like the pixel writer, you will need to write an equivilant, not 1 word, but 1 burst smart cache of 32 bytes to ease things along.  And you will need one for every sub-section of access which will need integration into the current pixel writer as it is the most demanding access port second to the video display, DMA flash reader/writer, then sound system, then Z80, except, any Z80 read transactions will need to interupt and take immediate action on the next read cycle if the contents are not in the cache, otherwise a read error will take place, or we will need to implement Z80 wait states.  Avoiding this means the Z80 will have the equivilant of 16 megabytes of static ram.  Assembly code should run with perfect repetitious predictable timing.

[nockieboy]

200 MHz is the limit and that's fine since the Cyclone V has enough PLLs, however your core multiport ram clock is 250MHz and it would be nice to run these at 250MHz.  You will need to add a linear 1.8v regulator as they require this voltage.  Make it adjustable as I believe we will be running them at ~2v-2.25v to squeeze out that 250MHz error free.

8bit bus at 500MTPS = 16bit data at 250MHz, same width and speed of your core ram meaning a 1:1 transfer rate.

There's some big figures there.  I'm going to have a headache working out how to get the IOs together for these chips, though - or placement headaches on the PCB, in any case.

You will probably configure this ram as 8 or 16bit graphics background screen only.  Meaning the 15 MAGGIE layers will above it's display while this ram will be Maggie layer 16.  You will be able to use the blitter for text on this layer and have 15 dedicated sprite layers which will have access to the core 350Kb.

So I could use the external RAM for the text screen (basically what I have now, but a higher resolution due to the extra RAM space) and use the internal RAM for sprites?

Audio will also be stored on this ram.  You will have 16 megabytes to play with using 2 chips.

My intention for the audio is to use an HDL synthesis of the classic AY-3-8910 PSG.  At least initially.  I guess having the flexibility to store samples and so on will just expand the possibilities.

If you make a smart flash DMA controller, I do not know about the flash speed, but you should be able to fill this ram at around 50 megabytes a second.  This means uncompressed 320x240 16bit avi @60fps video with sound playback is possible so long as the flash can keep up.  Almost no CPU overhead.  30fps will be easy-peasy.


Looking at the numbers, with the worst possible delay, you will just make it clear to guarantee that Z80 access will never have any wait states no matter what else the ram will be doing in the system, however, just like the pixel writer, you will need to write an equivilant, not 1 word, but 1 burst smart cache of 32 bytes to ease things along.  And you will need one for every sub-section of access which will need integration into the current pixel writer as it is the most demanding access port second to the video display, DMA flash reader/writer, then sound system, then Z80, except, any Z80 read transactions will need to interupt and take immediate action on the next read cycle if the contents are not in the cache, otherwise a read error will take place, or we will need to implement Z80 wait states.  Avoiding this means the Z80 will have the equivilant of 16 megabytes of static ram.  Assembly code should run with perfect repetitious predictable timing.

Yikes, it's looking like the RAM is a must-have rather than a nice-to-have with these possibilities.  So, assume I will be using the DRAM chips we've identified above - I'll need two of them, the 1.8V rail (variable to allow 'overclocking'), what sort of consideration will I need to make for IO selection, PCB placement etc?  I guess I'm going 4-layer, so I could use the space to the left and right of the FPGA as the address and data/control buses will pass the RAM chips in a signal layer beneath them?

[BrianHG]

There's some big figures there.  I'm going to have a headache working out how to get the IOs together for these chips, though - or placement headaches on the PCB, in any case.

Hun? Read the datasheet, it's 13 IOs for 1 chip, 1 more IO for the second as everything is in parallel except for CS# pin.

So I could use the external RAM for the text screen (basically what I have now, but a higher resolution due to the extra RAM space) and use the internal RAM for sprites?

It will be accessible as any 1 MAGGIE layer tied into the ram address.  The only issue is for access time allocation, only 1 MAGGIE can address the DRAM at a time as you will need to implement a special read-ahead cache for the DRAM as the ram access is on the order of 10-20 125MHz clocks unlike the FPGA ram which is immediate.  How you use the memory is completely up to you.  The blitter wont have this restriction between the fpga ram and DRAM, and as you know, you can simulate fonts/tiles with it supporting multiple colors and odd sizes which don't divide into widths of 8.

My intention for the audio is to use an HDL synthesis of the classic AY-3-8910 PSG.  At least initially.  I guess having the flexibility to store samples and so on will just expand the possibilities.

It may be OK if you have functional HDL code already, however, I recommend reconstructing an advanced version of an Amiga Paula audio system.  It is half as complicated as the geometry unit, but you can expect 8 channel sound, each channel with stereo, each with a volume and pitch table samples, all 16 or 8 bit.

Yikes, it's looking like the RAM is a must-have rather than a nice-to-have with these possibilities.  So, assume I will be using the DRAM chips we've identified above - I'll need two of them, the 1.8V rail (variable to allow 'overclocking'), what sort of consideration will I need to make for IO selection, PCB placement etc?  I guess I'm going 4-layer, so I could use the space to the left and right of the FPGA as the address and data/control buses will pass the RAM chips in a signal layer beneath them?

Begin with the IO.  To get the 500MTPS, you must use a top or bottom IO bank on the FPGA.  It must have PLL output pins to feed the CLK & CLK# signals.  It needs to be 1 IO bank since you need to change the VCCIO for that bank to 1.8v.  I already looked at your current layout.  You have 1 obvious choice and it will be an easy swapping of only a few IOs in your current design as soon as you clear up your schematic which seems to have a few unused additional labels.

For the regulator, you will add a small SMD trimpot tuned with an output range from 1.7v to 2.3v.  If there are no errors during tests at 1.7v, then you know you can keep running it at 1.8v.  I do not expect the entire 1.8v side to consume more than 80ma max when over-clocked.  So, you may relax and feel safe with the same linear regulators you are currently using.

You have other minor errors in your schematic, but I'm waiting until you finish things up.
1 thing, for the DAC's audio output DC filter caps, please change them to the 10uf non-polarized ceramic ones.  Remember, part consolidation...

[BrianHG]

No matter how you slice it, if you use a tiled MAGGIE text front layer, this will make the fastest text output no matter what for the Z80 as only 2 bytes are needed for each character.  You can even use the blitter to perform a screen carriage return and screen clear on the text data memory space.

Using the biltter to emulate ASCII text may be faster than the Z80 can write down 2 bytes, however, there are a few additional controls the Z80 must set and check every time it paints 1 letter.  You need to decide due to case use, if you want blitter text which offers a lot of fancy features and possibilities VS old fashioned dumb text mode.  Remember, you are still running at a max res of 640x480, it's just that the blitter text allows for any foreground/background color instead of 16fg x 16bg colors.

[nockieboy]

Okay, it's been a busy couple of weeks for me and I've not had any time other than a couple of hours today to look at the schematic and your previous replies.  I've done what I can.  I've had to remove a lot of decoupling for the TFP410 because I don't think I'll have the room for it all, to be honest.  I'm happy to give the setup a try without the reference design power supply isolation and decoupling, especially as it has been used the way I've done it (in fact, with even less decoupling) to good effect in other published designs.

I've re-jigged some of the FPGA connections to get the two DRAMs onto the board - hopefully I've done what you had in mind.  The schematic is updated but I haven't yet connected up the 1.8V power supply to the FPGA's IO bank for the DRAMs.  I also haven't designed the variable-voltage output from the AMS-1117 (U19) for the DRAM yet.  I'd be happy for some more info on that before I try - I guess I'll be using an SMD potentiometer in series with one of the resistors that sets the output voltage, but I'd probably be guessing at values at this stage without taking a closer look and spending some more time on that part of the schematic.

I've also updated the DAC to the suggested one and tucked its circuit up in the corner by the headphone socket to keep it out of the way as much as possible.  Believe it or not, I know even less about analogue electronics than I do digital, so I've just gone with the reference schematic as close as possible from the datasheet.  I've connected it up to Bank 2A.

My intention for the audio is to use an HDL synthesis of the classic AY-3-8910 PSG.  At least initially.  I guess having the flexibility to store samples and so on will just expand the possibilities.

It may be OK if you have functional HDL code already, however, I recommend reconstructing an advanced version of an Amiga Paula audio system.  It is half as complicated as the geometry unit, but you can expect 8 channel sound, each channel with stereo, each with a volume and pitch table samples, all 16 or 8 bit.

I wouldn't have a clue where to begin with that and I'm mindful that I'm highly dependant on your help when your time is very restricted.  I do have an HDL version of the AY-8910 already that would work with my existing software in CP/M, so in theory it's just a case of adding an interface in the Z80_bridge and an interface from the 3-channel output of the HDL AY-8910 to the DAC.  In theory I should be able to manage that myself - so I'll give that a shot first before starting on something like the Paula chip.

Begin with the IO.  To get the 500MTPS, you must use a top or bottom IO bank on the FPGA.  It must have PLL output pins to feed the CLK & CLK# signals.  It needs to be 1 IO bank since you need to change the VCCIO for that bank to 1.8v.  I already looked at your current layout.  You have 1 obvious choice and it will be an easy swapping of only a few IOs in your current design as soon as you clear up your schematic which seems to have a few unused additional labels.

Well, I've added the memory chips - not sure about the CLK & CLK# output pins - have picked pins marked 'p and 'n on the pin planner - so I'm hoping I've got that right.

For the regulator, you will add a small SMD trimpot tuned with an output range from 1.7v to 2.3v.  If there are no errors during tests at 1.7v, then you know you can keep running it at 1.8v.  I do not expect the entire 1.8v side to consume more than 80ma max when over-clocked.  So, you may relax and feel safe with the same linear regulators you are currently using.

Excellent.  Well, 1.8v power supply is in the schematic - you won't see it on the PCB design as it's out of shot because I haven't placed it yet, I'm waiting to finish the variable output design first.

You have other minor errors in your schematic, but I'm waiting until you finish things up.

There's probably loads of errors - I do the best I can, but I really rely on everyone's help here to spot the obvious errors I sneak in to test you all. 

1 thing, for the DAC's audio output DC filter caps, please change them to the 10uf non-polarized ceramic ones.  Remember, part consolidation...

That was for the old DAC - the new one pumps out a proper AC signal so there's no need for DC filters, hence you won't find any polarised caps in the new design. 

[BrianHG]

Bugs part #1.

Audio DAC - Place those 10uf or 22uf ceramics back in place and place 100k or 47k pull-downs on the headphone jack.
You never know when bad firmware or bad coding will drive DC out of the DAC.  The series caps will protect your DAC and audio hardware from that.

U19, change that to the adjustable version and add a trimpot.  You want the pot on the output - resistor - feedback pin, then feedback pin - resistor - GND.
Resistor calculator : https://circuitdigest.com/calculators/lm317-resistor-voltage-calculator
Make R2 = 560 Ohm, make R1 a 560Ohm resistor + a 1K pot in series.
This will allow adjustment from 1.7v to 2.5v.

Micro-SD Card: 2 of those resistors are 'BOGUS'.

DDR-RAM - Place the DDR_CKp and DDR_CKn IOs onto the dedicated PLL outputs.
It's written there right on the IO bank labels.
Remember, these 2 pins cannot be moved around, they must be on the PLL outputs.
You may only swap the 'n' & 'p'.

Add another RS232 header with 4 wire protocol/handshaking.  Make it compatible with a 3.3v TTL USB-RS232 header which has DTR & CTS, see attached image.  Do not connect the VCC.  Unless you want a DB9 and want a generic full RS232 port, not just a PC interface for the Z80 separate of the debugger.

Also expect to draw out a few unused IOs as emergency/surplus features.

[mariush]

You should maybe consider placing 2-4 resistors in series instead of a potentiometer, and using a jumper to short out resistors, reducing the total resistance, therefore different output voltage.
Set the 1.8v as default (no jumpers needed), adding jumpers raises in 0.1v increments or something like that.

[nockieboy]

Audio DAC - Place those 10uf or 22uf ceramics back in place and place 100k or 47k pull-downs on the headphone jack.
You never know when bad firmware or bad coding will drive DC out of the DAC.  The series caps will protect your DAC and audio hardware from that.

Okie dokie, have added non-polarised 10uF caps back in there and 100K pull-downs at the headphone jack.

U19, change that to the adjustable version and add a trimpot.  You want the pot on the output - resistor - feedback pin, then feedback pin - resistor - GND.
Resistor calculator : https://circuitdigest.com/calculators/lm317-resistor-voltage-calculator
Make R2 = 560 Ohm, make R1 a 560Ohm resistor + a 1K pot in series.
This will allow adjustment from 1.7v to 2.5v.

That's done.  I do like mariush's suggestion of using a set of resistors to provide preset values, but I'm not sure I'll have the room for something like that on the PCB.  I haven't checked to see where I'll put the trim pot or additional resistors yet, but I'm expecting a lot more movement on the PCB before I hit the final layout.

Micro-SD Card: 2 of those resistors are 'BOGUS'.

As soon as you mentioned them I thought, "no, surely I wouldn't have", but I had.   Well spotted. 

DDR-RAM - Place the DDR_CKp and DDR_CKn IOs onto the dedicated PLL outputs.
It's written there right on the IO bank labels.
Remember, these 2 pins cannot be moved around, they must be on the PLL outputs.
You may only swap the 'n' & 'p'.

Okay, no problem - I was rushing yesterday to get something done in the time I had.  Hopefully using the right pins now.

Add another RS232 header with 4 wire protocol/handshaking.  Make it compatible with a 3.3v TTL USB-RS232 header which has DTR & CTS, see attached image.  Do not connect the VCC.  Unless you want a DB9 and want a generic full RS232 port, not just a PC interface for the Z80 separate of the debugger.

Ah okay, that's a good use for some of the remaining free IOs.  Is there any way the configuration ROM could be updated via that serial connection, I wonder?

Also expect to draw out a few unused IOs as emergency/surplus features.

I'll add some of them in at the very end when I know I've definitely got spares. 

[BrianHG]

Fixes, part 1B...

Ok, the VCCPGM going to the FPGA is all messed up.
You should have IO and PGM separate,

On trimpot R51, swap pin 1&3 so the rotating counter-clockwise lowers voltage and clockwise increases voltage.

Disconnected VCCA from VCCIO and connect it to 3.3VA.  Or, make a 2 pin header jumper to select between the 2.

Do you have 3.3v protection diodes for the 4x PS2_xxx signals?  I recommend using 4 single or 2 dual schottky diodes tied to VCCIO.  If you want full VCCIO & GND protection, then use 4 dual diodes.

For the MSEL#, maybe it would be good to make them config jumpers, or resistors...

I don't know about the Cyclone5, but, you can make code which will self-program the boot prom.  I've done so on the CycloneIII.
You would need to verify that the nCSO, DATA0-3 & DCLK can be configured into regular IOs.  If not, then an IO tied to each one through series resistor with a DISABLE-Jumper (breaks the IO feeding DCLK) may be added to your design.  Then the Z80 or RS232-port/debugger may be used to change the firmware.

[nockieboy]

Ok, the VCCPGM going to the FPGA is all messed up.
You should have IO and PGM separate,

But page 5 in the Cyclone V Device Datasheet specifies maximum voltages for VCCIO and VCCPGM as 3.90V, and the Cyclone V E Power Supply Sharing Guidelines states they can be shared if the same voltage:

On trimpot R51, swap pin 1&3 so the rotating counter-clockwise lowers voltage and clockwise increases voltage.

Disconnected VCCA from VCCIO and connect it to 3.3VA.  Or, make a 2 pin header jumper to select between the 2.

All done.

Do you have 3.3v protection diodes for the 4x PS2_xxx signals?  I recommend using 4 single or 2 dual schottky diodes tied to VCCIO.  If you want full VCCIO & GND protection, then use 4 dual diodes.

No, I don't - the design works okay on the Cyclone IV board, but if you think I should add in some better protection, I can add in something like the BAT54S?

For the MSEL#, maybe it would be good to make them config jumpers, or resistors...

Perhaps, but I'm not likely to want to change these values, am I?  I've checked and double-checked the configuration section of the Cyclone V datasheet.  Will I need to be able to change these settings?

I don't know about the Cyclone5, but, you can make code which will self-program the boot prom.  I've done so on the CycloneIII.
You would need to verify that the nCSO, DATA0-3 & DCLK can be configured into regular IOs.  If not, then an IO tied to each one through series resistor with a DISABLE-Jumper (breaks the IO feeding DCLK) may be added to your design.  Then the Z80 or RS232-port/debugger may be used to change the firmware.

Hmmm, most of them seem to be bidirectional in the connection guide, but I'll need to look at the datasheet more closely to see if I can configure them as regular IO.  Something for me to research when I have more time, perhaps. 

[BrianHG]

Ok, the VCCPGM going to the FPGA is all messed up.
You should have IO and PGM separate,

But page 5 in the Cyclone V Device Datasheet specifies maximum voltages for VCCIO and VCCPGM as 3.90V, and the Cyclone V E Power Supply Sharing Guidelines states they can be shared if the same voltage:

(Attachment Link)

If you are going to share the power, then use 1 power bus, do not feed an extra filtered 3.3v with separate caps for the FPGA section.  Consolidate that power section, otherwise, you have too many power buses all over the place messing with you power plane design.  Again, fix this....

MSEL J2 is not good.  Replace it with 4 series 0603/0402 resistors with optional shorts underneath, going to your mode selection GND/VCC???

BAT54s series is fine.

Power the TFP410 from the VCCIO.  It can withstand a little digital noise from before it's L1 filter and it draws a little too much current from the linear regulator.  DVDD may be unfiltered.

[nockieboy]

If you are going to share the power, then use 1 power bus, do not feed an extra filtered 3.3v with separate caps for the FPGA section.  Consolidate that power section, otherwise, you have too many power buses all over the place messing with you power plane design.  Again, fix this....

Always happy to reduce nets and components.  I haven't attempted to place decoupling caps yet and it's already looking like it's going to be a nightmare to route.

MSEL J2 is not good.  Replace it with 4 series 0603/0402 resistors with optional shorts underneath, going to your mode selection GND/VCC???

Okay, I've done it for MSEL0 and MSEL1.

Power the TFP410 from the VCCIO.  It can withstand a little digital noise from before it's L1 filter and it draws a little too much current from the linear regulator.  DVDD may be unfiltered.

So long as the TFP410 is happy, I'm fine with DVDD using the filtered input as it seems to give the simplest PCB routing.

[BrianHG]

You are missing 100nf decoupling caps for every VCC_DDR pin.

What's happening with pin VCCPGM C6?

What do the 'VCCPD#B#A' pins do?

Aren't VCC_AUX and VCC_FPLL supposed to be separate?

[nockieboy]

You are missing 100nf decoupling caps for every VCC_DDR pin.

What's happening with pin VCCPGM C6?

This is why I don't do this stuff for a living.

Aren't VCC_AUX and VCC_FPLL supposed to be separate?

As far as I can tell, they don't have to be.  The Cyclone V documentation I'm using (Cyclone V Device Family Pin Connection Guidelines PCG-01014-2.8) indicates they can be shared:



And here in this Altera dev board schematic:

What do the 'VCCPD#B#A' pins do?

Oooooh.... how could I miss that?   



Okay, that poses a serious (I guess?) problem, as it means that Bank 7A must operate at 1.8V as well, as it shares VCCPD pins with Bank 8A and both must use compatible VCCIO voltages for the shared VCCPD voltage, if I'm reading that right.

So that means I have to clear out the 11 Z80 data and control signals from Bank 7A and move them to the few remaining spare IOs in Banks 2A and 4A?

[BrianHG]

I believe both DACs and TFP410 can be run their DVDD at 1.8 through 2.5v as well.  This means you may pass the 24 bit video dac and audio I2S through bank 7 and one of bank 5.  This leaves everything else at 3.3v.
Careful, you will want a dedicated separate 3.3v copy of HS&VS to drive U4 sync boost.

If you are using bank 5B, you also get the dedicated PLL CLK output to clock the video data.


***Don't forget decoupling caps for VCC_DDR for the FPGA supply pines as well, not just the memory.

[nockieboy]

I believe both DACs and TFP410 can be run their DVDD at 1.8 through 2.5v as well.  This means you may pass the 24 bit video dac and audio I2S through bank 7 and one of bank 5.  This leaves everything else at 3.3v.
Careful, you will want a dedicated separate 3.3v copy of HS&VS to drive U4 sync boost.

If you are using bank 5B, you also get the dedicated PLL CLK output to clock the video data.


***Don't forget decoupling caps for VCC_DDR for the FPGA supply pines as well, not just the memory.

This is causing me a headache.  Changing the DVDD supply to the PCM5101 isn't an issue, looks like it's fine with that according to the datasheet.  Where the problem arises is with the TFP410 and ADV7125 DACs.  Both use the 24-bit RGB bus, pixel clock and display enable from the FPGA - so that's 26 IO pins on the FPGA I'd need to make 1.8V, which is more than one bank.  I'd be losing more IO's to 1.8V than I am already right now?  That's without worrying about the HS and VS signals too - they'd need to be 1.8V for the TFP410 if it's running on a 1.8V bus?

What about if I use Bank 3A for the DRAM?  I can assign just Bank 3A to 1.8V as it has its own VCCPD pin, it doesn't share it with any other banks. It just means moving the SD card and low Z80 address pins to Bank 2A, or shuffling everything around a bit.  Would that work?  The only (possible) issue I can see immediately is that CLKUSR goes into Bank 3A, but that must be able to operate at 1.8V as well as at 3.3V?  I'd just need to change the supply to X1?

EDIT:  Bank 3A doesn't have FPLL_CLKOUT pins, though. 

EDIT 2: Bank 5B has its own VCCPD pin AND FPLL_CLKOUT pins, however.....?

[BrianHG]

Ok, you can use bank 5B.  CycloneV doesn't have the row VS column speed limitations like the older Cyclones.  In fact, it can do with wisely chosen pins and 303MHz/606MTPS using any soft core memory controller.  You will be running your controller at 250MHz max, IO 500MTPS, well within IO Bank 5B's speed.

You may want to rotate the chip and fix up the IO so the PSRAM end up in the same current space on your PCB.

And, you may want to update a version of your project to a CycloneV and enter the IO pins to see if it compiles...
Also, enter dummy pins for the PSRAM, and add the final IO pins for any other new IOs.  Just add them in the top block diagram & tie them to GND, or leave open if they are dedicated inputs.

[nockieboy]

And, you may want to update a version of your project to a CycloneV and enter the IO pins to see if it compiles...

I've tried that already so that I can use the Pin Planner.  It won't compile - something about the async RAMs. Thought I'd worry about that later, but I guess now is as good a time as any...

*loads up Quartus to check*

It doesn't like the RAM primitives - complains about bidir_dual_port using an unsupported value for parameter port_x_read_during_write_mode...

Code: [Select]

Error (14000): WYSIWYG RAM primitive "ram_block1a1" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a1" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a2" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a2" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a3" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a3" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a4" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a4" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a5" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a5" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a6" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a6" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a7" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a7" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a8" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a8" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a9" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a9" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a10" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a10" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a11" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a11" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a12" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a12" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a13" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a13" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a14" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a14" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a15" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a15" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a16" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a16" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a17" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a17" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a18" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a18" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a19" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a19" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a20" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a20" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a21" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a21" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a22" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a22" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a23" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a23" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a24" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a24" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a25" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a25" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a26" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a26" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a27" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a27" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a28" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a28" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a29" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a29" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a30" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a30" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a31" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a31" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a32" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a32" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a33" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a33" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a34" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a34" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a35" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a35" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a36" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a36" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a37" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a37" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a38" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a38" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a39" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a39" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a40" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a40" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a41" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a41" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a42" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a42" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a43" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a43" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a44" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a44" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a45" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a45" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a46" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a46" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a47" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_a_read_during_write_mode"
Error (14000): WYSIWYG RAM primitive "ram_block1a47" in operation mode "bidir_dual_port" uses an unsupported value for parameter "port_b_read_during_write_mode"
Error (12152): Can't elaborate user hierarchy "vid_osd_generator:inst9|sixteen_port_gpu_ram:gpu_RAM|gpu_quad_port_ram:gpu_RAM|gpu_dual_port_ram_INTEL:dual_port|altsyncram:altsyncram_component|altsyncram_hvr2:auto_generated"
Info (144001): Generated suppressed messages file G:/fpga/Projects/GPU/GPU_5CEBA2F17/output_files/GPU.map.smsg
Error: Quartus Prime Analysis & Synthesis was unsuccessful. 97 errors, 86 warnings
Error: Peak virtual memory: 4830 megabytes
Error: Processing ended: Tue Nov 03 08:22:00 2020
Error: Elapsed time: 00:00:28
Error: Total CPU time (on all processors): 00:00:50
Error (293001): Quartus Prime Full Compilation was unsuccessful. 99 errors, 86 warnings


Will reply to the rest of your post shortly, once I've had a look at the project and moved some pins about. 

[BrianHG]

Patched the ram definition, see the attached .v file.

The change was in these 2 configuration lines, OLD:

Code: [Select]

altsyncram_component.read_during_write_mode_port_a = "OLD_DATA",
altsyncram_component.read_during_write_mode_port_b = "OLD_DATA",
NEW:

Code: [Select]

altsyncram_component.read_during_write_mode_port_a = "NEW_DATA_NO_NBE_READ",
altsyncram_component.read_during_write_mode_port_b = "NEW_DATA_NO_NBE_READ",

Based on our design, these changes should not affect any functionality.
The change should be backwards compatible, IE safe to use in your CycloneIV code.  You should update your CycloneIV design with the new 2 lines to test.  Let me know if everything runs AOK.

(How I found the bug)
I basically added a new core-memory from the basic functions IP catalog and made an equivalent ram block, 2 read, 2 write dual port ram as identical to our core-Intel ram as possible.  This was the only new spec in the CycloneV ram which could not be selected as 'OLD DATA' after the don't care.  So I modified only those 2 lines in our existing code and it compiled fine with a CycloneV selected FPGA.  The CycloneV core memory doesn't support the 'OLD DATA' read data out during write data into ram.

[nockieboy]

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).

[BrianHG]

Compiles fine on my system.  Using Prime 18.1 Lite Edition.
Though, I have not defined the IOs, so they are being automatically being randomly distributed...
Which CycloneV have you selected?

[nockieboy]

Compiles fine on my system.  Using Prime 18.1 Lite Edition.
Though, I have not defined the IOs, so they are being automatically being randomly distributed...
Which CycloneV have you selected?

5CEBA4F17C8.  I've just switched to the 5CEBA2F17C8 and got the exact same errors. 

[nockieboy]

Here's my project - not sure what's going on and why I'm getting that error, but it's probably something wrong with the project settings.  Other than changing the device and setting some voltages, I don't think I changed anything else?