SRAM interface issue

1. Don't connect the byte-enables coming out of the SOPC Builder generated module.

2. Tie the FPGA pins connected to the SRAM chip's byte enables high (or low)...not sure which.

Keep in mind that none of the half word or byte-wide accesses will function, but I assume you already know that.

Alternately, you could take a look at the Asynch. SRAM component and modify its class.ptf file so that it doesn't include the byte enables. [Extremely easy!]

Still another option is to wait for an upcoming document which will cover the creation of your own SRAM SOPC Builder component using the Component Editor (Component Builder).

Regardless of which path you choose, it's easy to solve.

Regarding data cache....only if your SRAM is used for data storage _only_. If code/.text is stored there, then you'd need icache, as well.

Cheers,

- slacker

So far the pins have been connected as described and everything seems to be working. However if there does happen to be a Byte write to the SRAM, this could be an issue as it will be treated as a word write which could inadvertenly write on top of valid data.

I also found out that if you were writing all the code in assembly, you could get away with this but seeing that this would be too monotonous, the C compiler is the way to go. However the NiosII has many 8bit and 16bit read/write instructions and the C compiler will use them. Doesn't look like there is a way to force it one way or the other.

Also sounds like the Nios debugger uses byte access only to read contents of memory. So this would prevent the use of the debugger.

What is your opinion on this?

Todd

Todd,

For a specialized application where you are certain byte-access won't be required (code storage, a dedicated data buffer that you ONLY address as 32-bit words, DMA transfers, etc.), then you should be okay. However, if you want compiled C code to run reliably or debug (as you mention), its best to have byte-access to the memory.

If you're REALLY on an I/O budget the thing that comes to mind is reducing the number of data pins. This will have a corresponding hit in performance, but will help... Avalon's dynamic bus sizing feature means that it doesn't matter wheter your external RAM is 8/16/32 bits -- a wide (for example, 32 bit access to 8 bit external memory) will be divided into four sequential accesses to the external device automatically by Avalon; see the Avalon Specification for additional detail on how this works. Again, the trade-off is your throughput is reduced.

Hi Jesse,

I am using a 16bit SRAM currently and do not have the ability to change my setup at this point. For now I simply need make things work. From slackers comments, it doesn't look like this is a difficult issue but I need someone to point me in the right direction.

Do you see any issues with modifying the ptf file for the SRAM component? Where is the SRAM component located? The only componetn that I can see with reference to SRAM is the /nios2/components/altera_nios_devkit_startix_edition_sram. Is this the same component that is used for the Cyclone boards? I would assume they are the same anyway. Also how do I go about modifying the ptf file?

Any help you can provide would be great.

Regards

Todd