I don't understand this at all. Using the same frameBuffer definition, I made my top level module fill the frame buffer with values as a test. The entire screen was filled with colour as I expected. In fact, I used to have frameBuffer defined like this:
bit[3:0] frameBuffer[33792];
This worked perfectly fine. I had an entirely working screen - and that was 4bits.
I have a 3-bit frameBuffer now (as shown in the original post) and even reducing this to 16k results in the same problem:
bit[2:0] frameBuffer[16384];
If your code doesn't register at least frameBufferReadIndex, it can't infer RAM. Best to follow RAM code template in Quartus.
I don't understand what you are saying, sorry. What do you mean by "code doesn't register"? Is there something wrong with the below definition?
bit[16:0] frameBufferReadIndex;
Why did it work before I changed my logic around? I really don't understand why a design can work fine for ages and then it won't compile when some things are reorganised. I have had a frame buffer like this in other projects too. Maybe I have had that "Info (276007): RAM logic "frameBuffer" is uninferred due to asynchronous read logic" warning all along but it has still worked?
Update: I just checked the compiler output for the previous version that works. It has this to say about frameBuffer instead:
Warning (276027): Inferred dual-clock RAM node "frameBuffer_rtl_0" from synchronous design logic. The read-during-write behavior of a dual-clock RAM is undefined and may not match the behavior of the original design.
Just a bit of additional info - I have frameBuffer being read by a 25MHz VGA clock. At various times, it will be written to using a 28MHz clock. I was worried about this from the start and I originally tried using the same 28MHz clock for VGA but that wouldn't work. So is there now an issue with async read and write because the logic has changed - and therefore the timing? I'm not sure how to get around this. Was I just lucky when it worked and generated the above warning? Why is it not inferring a dual-clock RAM node this time around?
Can I force usage of a dual-clock RAM node somehow?
Is it simply a matter of making a module as described here: https://www.intel.com/content/www/us/en/docs/programmable/683082/22-1/simple-dual-port-dual-clock-synchronous-ram.html ?
Contributor
