Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
18 years ago

Problem with fitting design in EP3C25 - Why do I use so many M9K blocks

Hi

I am trying to make a design with the new Cyclone III device (EP3C25F324C8), but I keep getting an error when I run the fitter. The fitter complains about that I use too many M9K blocks. I only use 211,304 memory bits which is 1/3 of the capacity so it seems like I only use a small portion of the bits in each block.

I only use blocks from SOPC builder in my design so I expect that the RAM is probably made in the design files. I use the following blocks which consumes much RAM

- NIOS CPU

- DDR SDRAM High performance controller

- 2 x Triple Ethernet Controller

- 4 x Scatter - Gather DMA controller

- 2 x on-chip memory (Descriptor memory)

- jtag UART

I have used the Triple speed ethernet design (TSE_SGDMA) for the EP2C35 development kit which is available in version 7.1 as a reference design.

From the text in the error it seems like each bit in some of the registers occupies a whole M9K block. I have tried to change the settings in Quartus II, but I cannot make the fitter work.

I have pasted a small portion of the text in the error below (I get around 1000 of the lines when i expand the error)

I have been told that it might be because Quartus II 7.1 is a preliminary version, but I do not know.

Does anybody know what I have to change?

Thanks

Tom

Error: Selected device has 66 RAM location(s) of type M9K. However, the current design needs more than 66 to successfully fit

Info: List of RAM cells constrained to M9K locations

Info: Node "MCE4025_cpu:inst|sgdma_tx1:the_sgdma_tx1|sgdma_tx1_m_readfifo:the_sgdma_tx1_m_readfifo|sgdma_tx1_m_readfifo_m_readfifo:the_sgdma_tx1_m_readfifo_m_readfifo|scfifo:sgdma_tx1_m_readfifo_m_readfifo_m_readfifo|scfifo_of01:auto_generated|a_dpfifo_vl01:dpfifo|altsyncram_otd1:FIFOram|q_b[24]"

Info: Node "MCE4025_cpu:inst|sgdma_tx1:the_sgdma_tx1|sgdma_tx1_m_readfifo:the_sgdma_tx1_m_readfifo|sgdma_tx1_m_readfifo_m_readfifo:the_sgdma_tx1_m_readfifo_m_readfifo|scfifo:sgdma_tx1_m_readfifo_m_readfifo_m_readfifo|scfifo_of01:auto_generated|a_dpfifo_vl01:dpfifo|altsyncram_otd1:FIFOram|q_b[25]"

Info: Node "MCE4025_cpu:inst|sgdma_tx1:the_sgdma_tx1|sgdma_tx1_m_readfifo:the_sgdma_tx1_m_readfifo|sgdma_tx1_m_readfifo_m_readfifo:the_sgdma_tx1_m_readfifo_m_readfifo|scfifo:sgdma_tx1_m_readfifo_m_readfifo_m_readfifo|scfifo_of01:auto_generated|a_dpfifo_vl01:dpfifo|altsyncram_otd1:FIFOram|q_b[26]"

Info: Node "MCE4025_cpu:inst|sgdma_tx1:the_sgdma_tx1|sgdma_tx1_m_readfifo:the_sgdma_tx1_m_readfifo|sgdma_tx1_m_readfifo_m_readfifo:the_sgdma_tx1_m_readfifo_m_readfifo|scfifo:sgdma_tx1_m_readfifo_m_readfifo_m_readfifo|scfifo_of01:auto_generated|a_dpfifo_vl01:dpfifo|altsyncram_otd1:FIFOram|q_b[27]"

Info: Node "MCE4025_cpu:inst|sgdma_tx1:the_sgdma_tx1|sgdma_tx1_m_readfifo:the_sgdma_tx1_m_readfifo|sgdma_tx1_m_readfifo_m_readfifo:the_sgdma_tx1_m_readfifo_m_readfifo|scfifo:sgdma_tx1_m_readfifo_m_readfifo_m_readfifo|scfifo_of01:auto_generated|a_dpfifo_vl01:dpfifo|altsyncram_otd1:FIFOram|q_b[28]"

Info: Node

12 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    The information in the Fitter compilation report can be limited for a no-fit. You might have to change to a larger device temporarily so that you can get a fit and use the report sections mentioned below.

    In the Fitter report, "Resource Section --> Resource Usage Summary" tells the number of M9K blocks used. As you are probably figuring out, that number is much more important than the number of memory bits used.

    "Resource Section --> Fitter RAM Summary" tells how the Fitter divided up the memories in the design into M9K blocks. This might give you a lot more insight into things like your suspicion that "each bit in some of the registers occupies a whole M9K block" (I doubt that this is what's happening). Some columns in this table tell you the size of the used number of bits in a particular memory. When a memory is placed into M9K blocks, there might be some "wasted" bits in the M9K blocks because the memory in the design has a depth and/or width that can't be divided exactly into the allowed M9K depth/width configurations. Other columns in the table tell you the number of bits in all the used M9K blocks including these "wasted" bits. For example, you might have a memory that is 3K deep by 3 bits wide. That's 9K bits, but an M9K block cannot be 3 bits wide. This 3Kx3 memory could be implemented with two M9K blocks each configured as 4096x2 or each configured as 2048x4. Either way, there will be wasted bits.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    I'm fighting with this exact issue. I have seen it in QII 6.x as well as 7.x. Specifically, and for reasons completely unknown, QII decides that all memory needs to be implemented as 1 bit wide memories regardess of requested depth. So a 1k x 8 buffer that should take 1 M9K, takes 8 M9K instead. Not too big a deal until every bit of every memory gets expanded. My current 3C10 app is demanding over 500 M9K, even though the actual block usage should be about 42.

    I have seen the behavior come and go with nothing more than a tweek to an on-chip memory instantiated in SOPC builder. Like changing the width of a buffer from 8 to 16 bits...no change in size...and suddenly every bit of every memory wants its own block...and the block utilization goes from 20 to 200. If anyone has a clue, I'd love to hear it...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    A quick screen grab of the usage. Note the CPU's use of M9Ks...a tiny bit over what would normally be expected.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Open the Compilation Report and go to Fitter -> Resource Utilization -> RAM Summary. This is an excellent resource estimate by instance. One thing to note is the message at the bottom, is that the fitter may spread a memory over multiple blocks, i.e a 1Kx8 might get spread into 2 or more blocks. It only does this when it has room, and thinks it will get better performance. (There is a message at the bottom that declares this). So the usage tends to be a little higher than expected in a non-full device. If you go to the Fitter Report -> Resource Usage Summary, then the number of block rams tends to be the idealized number(i.e. if everything were packed as tight as possible), but this is not broken out by hierarchy. BobO, your case doesn't sound like the spreading issue at all, and I would file an SR if at all possible to get it resolved(somethin' strange is happenin')

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Yeah, the graphic I posted 2nd was a snapshot of a portion of the resource utilization report. You'll note that the CPU section alone is claiming to need 197 blocks...with the 2 1024 bit register blocks wanting 32 blocks each. Clearly QII is allocating a block per memory bit regardless of required depth, which is almost never the right answer. Spreading? Indeed.

    I point out the CPU section only because it is something that I have no direct control of (other than cache size...which happens to be 8 and 4) and clearly cannot be a function of poor coding on my part. Not to say that I haven't broken a design or two :D but I don't think this one it my bad.

    My AE has submitted an SR, so hopefully I can get this resolved soon. I was kinda hoping someone on the forum had encountered this though, and could give me a "yeah...all you gotta do is...." type answer.

    Thanks!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Is that fit after a full place and route? You might say it can't get through the fitter because it requires so many RAM blocks. If so, is the actual message that it can't fit because it requires 192/x M9Ks(or a larger number if some are required elsewhere?). I'm just wondering if you're getting a no-fit because of something else, and the analysis and synthesis reporting is just splitting them into memory slices, but the fitter would have actually correctly grouped them back together, and the no-fit isn't correlated to this. (I'm pulling this theory out of you know where, just because I've never seen it do this before, but naturally I don't have enough information)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    It dies immediately upon starting the fitter, and the error given is the same as the original poster's error....

    "error: selected device has 46 ram location(s) of type m9k. however, the current design needs more than 46 to successfully fit"

    ...so it seems to be a memory block issue. You make a good point though, that the real problem and reported problem may not be exactly the same. I may try to back some buffers down a bit more and see if it gets happy and we miraculously shrink from needing 500 blocks to only 40-ish.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Can you open the error message(click the plus) for more information? I don't know if it has one. Can you make a dummy project and target a larger device? My guess is that it's not sometimes using 1 bit of every RAM and sometimes it isn't. Instead, it might be packing everything like you'd expect, but still requires more RAM than available(maybe just a few more), it fails, and the synthsis and analysis report is showing 1 RAM per slice. But it's not that it failed thinking it needed one RAM per bit width of memory, it failed because it truly needed more than 46. (Again, just taking a stab here...)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    --- Quote Start ---

    I may try to back some buffers down a bit more and see if it gets happy and we miraculously shrink from needing 500 blocks to only 40-ish.

    --- Quote End ---

    As I suggested for the original post, you could change to a larger device temporarily so that you can get a compilation report for a fit. That might be less trouble than reducing the amount of memory in the design. I always question what is in the Fitter compilation report for a no-fit because some of the numbers don't tell you what you would have had if it had fit.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    As was suggested, the no fit result lies horribly. I trimmed buffers back to the bare minimum, without changing the design, and 500 blocks suddenly became 42. Then added back 4 more blocks and it still fit.

    I am using core with unknown block usage...and it turned out to be 3 more than I guessed. Had the fitter said "49 is greater than 46", this is a non-problem. But when the fitter says..."49 is greater than 46, but what I really wanted was 500, so I'll tell them 500" ...this becomes a real head scratcher.

    Thanks for the feedback guys!