I am using a Cyclone V 5CEBA2F23C8 in my design for an Atari XL recreation - the EclaireXL.
The Cyclone V has been excellent and I am very impressed with the technology. The fractional PLLs are really great, you should include them in the smaller FPGA families too! If there was a 5V tolerant version that would be even better.
Anyway to the point. I have now filled up the block memory and after some recent changes, when I compile my design I see that a block is inferred for the 6502 CPU and ALSO used explicitly for the zpu memory. Using the block twice is clearly a great efficiency if it can be done and still work. However the issue I have with this is: the block gives incorrect data where it is inferred for the CPU!
I was hoping this would be solved in the next Quartus versions but after a few iterations it has not been addressed. I'm not on Quartus Lite 20.1.1. So I thought it may be something that Intel is not aware of.
In order to workaround this bug, is there a way to tell Quartus not to use memory blocks twice when synthesizing the design?
To restate the issue more simply to increase changes of a reply.
I have a design that used to work well for the Cyclone V 5CEBA2F23C8. As the FPGA filled up Quartus decided to share the same block ram between parts of the design.
For some reason, a bug in the design, or a bug in Quartus, the sharing of block ram does not work correctly.
Is there a way to disable sharing block ram between multiple parts of the design?
Without seeing the design, it's hard to understand what you mean. Are you saying that you've inferred or instantiated a RAM and the same physical RAM block is being shared using multiple ports? Can you show some code or what you're seeing in the RTL viewer or the Technology Map Viewer?
There are packing and merging options you could check in Assignments menu -> Settings -> Compiler Settings -> Advanced Analysis & Synthesis Settings, but they're mostly for registers.
I see the same port of an M10K ram block used in two places. In my most recent build this is M10K_X38_Y11_N0 as seen here in the memory use summary - filtered to the duplicate:
In the technology map viewer I see this in the 6502 cpu:
... and the supporting zpu processor rom:
When this occurs I get the wrong results from the op code decoder in the 6502 cpu.
The code is online:
In the table in the 6502 code it says:
"0100" & "100010" & implied & aluInX & aluInc, -- E8 INX
Which is supposed to be:
0x002020000112 (i.e. 0100 is 2, then 1000, then 10... )
However because of this ram I end up with
But only when I add some unrelated video logic using other block ram and start getting this block memory shared. So the stack pointer is hanged on opcode E8 (increase X) when it shouldn't be.
The project is all open so I can share the whole build. Its attached, though needs compiling - load the project atari800core_eclaireXLv1.qpf from the attached.