Stratix III Memory usage efficiency

Has anyone else encountered the problem of shape and size of M9K blocks (I suppose this applies to other devices also). e.g. if I want a 2720X18 memory (48960 bits), the wizard will construct one out of 9

4096X2 memories (82944 bits) which is 60% efficient.

Does anyone have a stategy for getting more efficiency of usage out of these blocks?

I can think of one way (in this example by stacking 6 512X18 blocks and using multiplexers and decoders etc.) but perhaps someone has a better or more straightforward approach.

I'm asking this about SIII because I am quite used to SII M4K and M512 blocks which seemed to be a better fit for my designs.

Thanks, DaveW.

Reply to
davew
Loading thread data ...

Skip the wizards, write code, use synthesis.

Quartus synthesis can do 4096x18 in 73728 bits.

formatting link
formatting link

-- Mike Treseler

Reply to
Mike Treseler

bits.http://home.comcast.net/~mike_treseler/block_ram.pdfhttp://home.comcast.net/~mike_treseler/block_ram.vhd

Thanks Mike, perhaps I'm asking a daft question but your example uses 9 M9K blocks of a Stratix III which = 82944 bits or 73728 as you say if you configure the M9K as 4096X2 = 8192 bits. Your example uses all the bits in the block so the utilisation is 100%. My memory only utilises

60% of the bits but it could have been organised differently with a little extra logic - I'm not suggesting that Quartus should be able to work this out though - I don't think it can because it would involve extra gates and the pipeline delays would be different.

In my solution, I used 6 M9K blocks configured as 512X18 and multiplexed the outputs (BTW my memory is dual ported). It also required a decoder to provide individual we lines to each of the blocks. In other words it stacked the memory blocks in series rather than in parallel at the expense of the extra logic.

I wondered if this was a common way of getting better utilisation or if there was a better way.

Have I missed your point though?

DaveW.

Reply to
davew

bits.http://home.comcast.net/~mike_treseler/block_ram.pdfhttp://home.comcast.net/~mike_treseler/block_ram.vhd

I guess the main point was that don't use the wizards to generate the memories unless there is no other way (very exotic amount of ports etc.).

It's wiser just to let the synthesizer to infer the memories. Then the memories are usually portable to other architectures, and it's easy in the tools to change how the memories are implemented with attributes or synthesis settings.

The integrated synhesizers can infer most of the normal memory structures. Synplify seems to be much better figuring out what to infer even from quite convoluted code that does not follow the example templates.

--Kim

Reply to
Kim Enkovaara

Note that I didn't configure anything other than the address and data widths. If I compiled the same code using ise, some other block sizes would be used.

Your requirement is slightly over the 11 bit boundary so I used 12 address lines. You may end up needing that extra memory anyway.

That would be a custom, device-specific design. If that's what I wanted to do, I would infer multiple smaller rams and glue them together in a wrapper entity.

That strikes me as a lot of work to save three blocks.

I leave so much block ram unused, that the thought never occurred to me.

I guess my main point is that I have a bad attitude about using vendor-specific wizards when I don't have to.

-- Mike Treseler

Reply to
Mike Treseler

Hi Dave,

The memory wizard configures the memories to their maximum depth because this uses the least logic and runs at the greatest speed(i.e. minimal decode logic required.) There is a maximum depth parameter in the Megawizard where the user can enter the maximum configuration depth for your block. In this case, if you enter 512 it should configure them as 512x18 and do what you need.

Hope this helps, Subroto Datta Altera Corp.

Reply to
Subroto Datta

Ah! So that's what that parameter which I have been ignoring is for! Thanks Subroto, that's interesting. I'll try that out tomorrow. Dave.

Reply to
davew

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.