User Profile
User Widgets
Contributions
Re: Error (276003): Cannot convert all sets of registers into RAM megafunctions when creating nodes.
I am always happy to share full code but there's always the danger of losing IP when publicly shared. Thank you. I'll accept your answer as the solution since it has pointed me in the right direction and made me learn a bit more. 🙂1.2KViews0likes0CommentsRe: Error (276003): Cannot convert all sets of registers into RAM megafunctions when creating nodes.
Well.. I implemented my frameBuffer as a separate module as suggested here: https://www.intel.com/content/www/us/en/docs/programmable/683082/22-1/simple-dual-port-dual-clock-synchronous-ram.html ..and that is compiling and "working" once again. Now I have this warning, so I assume all is OK and back to normal? Warning (276027): Inferred dual-clock RAM node "FrameBuffer:frameBuffer|ram_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.1.2KViews0likes2CommentsRe: Error (276003): Cannot convert all sets of registers into RAM megafunctions when creating nodes.
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 ?1.2KViews0likes0CommentsError (276003): Cannot convert all sets of registers into RAM megafunctions when creating nodes.
Error (276003): Cannot convert all sets of registers into RAM megafunctions when creating nodes. The resulting number of registers remaining in design exceeds the number of registers in the device or the number specified by the assignment max_number_of_registers_from_uninferred_rams. This can cause longer compilation time or result in insufficient memory to complete Analysis and Synthesis I started doing some overhaul on the logic in my project today and I got this error. I've made too many changes to incrementally back-step to see what caused this. How can I identify what the offending code, logic or register usage actually is? I can't see what my total register usage is yet. I'm using my trusty Cyclone IV EP4CE6 FPGA. I know I have been close to exhausting resources on this device for a while. I have the below array which has usually been a problem, but even when I reduce the size right down it isn't making any difference so it must be something else. bit[2:0] frameBuffer[49920]; I have been trying to work through resolving all of my truncation warnings etc today but still no joy. I did however see this in the log: Info (276014): Found 1 instances of uninferred RAM logic Info (276007): RAM logic "frameBuffer" is uninferred due to asynchronous read logic What does this mean? I am only reading frameBuffer in one place as far as I can tell: bit[16:0] frameBufferReadIndex; bit [3:0] frameBufferByte; bit vgaReading; assign frameBufferByte = vgaReading ? frameBuffer[ frameBufferReadIndex ] : 4'h0; Ignore the 'byte' reference - I have been making the 'byte' smaller and smaller since I began running out of resources.Solved1.4KViews0likes5CommentsRe: Making Nodes visible to SignalTap
I tried (* preserve_for_debug *) in VgaDisplay.sv but that still won't show vic_screen_lines in STP. I tried "Design Filter (all names)" as well - it still doesn't appear when I click List. It is not listed in the 2 optimization result reports for removal, I can't find it in the compilation output, and I certainly can't see it in the RTL Viewer so it must have been removed somehow. BUT.. I have just this minute tried searching for *vic_screen_lines* - and it appears! So I will have to remind myself to always use the asterisks either side of the node. I feel so stupid now - thank you for joining on me on this journey. 🙂 Always surround with asterisks, Sparky! Always!1.9KViews0likes0CommentsRe: Making Nodes visible to SignalTap
Oh, so if the registers aren't modified on a clock cycle (ie. within an always block or state machine), then maybe registers are not inferred? Is it possibly because I have "continuous" logic here rather than clocked (flip-flop) logic? Please excuse my limited experience - I'm still a beginner/dabbler. Maybe it would be good for me to scale down a smaller project and see what is actually produced in the RTL Viewer.2KViews0likes0CommentsRe: Making Nodes visible to SignalTap
When you say "registering those signals", what do you actually mean, sorry? Here's another case for example: bit [7:0] vic_screen_lines; assign vic_screen_lines = vicScreenCharHeight << 3; I have other assign statements that use vic_screen_lines but I cannot view them in SignalTap. I tried this too but it made no difference: (* noprune *) reg [7:0] vic_screen_lines;2.1KViews0likes2CommentsRe: Making Nodes visible to SignalTap
The only reason I mentioned Notepad is that I find editing text faster than going into the Quartus UI screens. Just saying that if I can "decorate" registers/nodes withing the Verilog text, that's easier than fiddling with the Assignment Editor.. However.. I do seem to have hit the pin limit where I may need to do what you suggested anyway: What is my logic connected to? Well.. I had hardcoded a load of constants that need to become variable. Once I did that, the logic didn't seem to work the way I expected it to so I thought I would "promote" the nodes to outputs so I can see what values they are taking on in SignalTap.. Maybe I have far too many interdependencies here and perhaps I need to take a step back and simplify what I have. The last 5 signals I refer to in my VGAController module - it decides where to paint a border or a screen background.. as the old Commodore Vic 20 used to. I know what I am doing it bad because I am including so much arithmetic now. It wouldn't have mattered with the constants.. but pretty bad to implement that complicated mess in logic.2.1KViews0likes0CommentsRe: Making Nodes visible to SignalTap
Yes I normally just do the "Start Analysis and Elaboration" when adding new nodes, to get SignalTap to have visibility of them. Right now I'm compiling the whole thing, shutting down SignalTap and restarting SignalTap but it still won't show those nodes with the Pre-Synthesis filter. I think the Virtual pin assignment would take longer to do as well - these days I edit my Verilog with Notepad++ so I have access to keyboard macros and the likes to speed up editing.2.1KViews0likes0Comments