External SSRAM reading/writing problem

[Altera_Forum]

Hello everyone, 

 I want to connect nios core (cyclone ii) to external sram memory (cy7c1380d) but I'm experiencing a problem while reading/writing to/from the memory. For 2MB (data width 32 bits) memory I need 19 address bit, but the memory has 21 address bits. SOPC buider user guide says that Avalon-MM address[0] and address[1] should be left unconnected, but I don't know how to do that.   When I run an ssram test program, read and written data don't match.   unsigned int i; alt_u32 *buffer = (alt_u32 *)SSRAM_BASE; for(i=0; i<100; i++) { buffer = (i+1000000);  } for(i=0; i<100; i++) { if(buffer != (i+1000000)) errors++; }   So instead of this, I tried to do somthing like this: buffer[0] = 0; buffer[1] = 1; ... buffer[50] = 50; alt_printf("%x ", buffer[0]);  alt_printf("0x%x ", buffer[1]); ... alt_printf("0x%x ", buffer[50]);   And here is what is printed: 0x30 0x31 0x32 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x23 0x24 0x25 0x26 0x27 0x28 0x29 etc.   So, apparently, the address 0, 16, 32 are overwritten with what I want to write to the address 48, address 3 with 35, etc... At first I thought that it could be a timing issue and I added a delay of -2ns (also tried -3ns, -5ns, 180deg) to the pll (25MHz) that is driving my external ssram, but it didn't solve the problem. There may be a problem with the address pins, and I'm not sure if SOPC builder left-alignes the address bits or I need to do that.   Thanks, Nikola

[Altera_Forum]

Avalon always uses byte addressing, even for 32bit data slaves. 

So you must discard address[0] and address[1] if your ssram only supports 32bit addressing.  I also suggest to use uncached access (set the 32th bit of buffer) in order to prevent cpu fetching data from cache instead of actually reading back rom ssram. Anyway I think this is not your problem now.

[Altera_Forum]

Hello Cris72, 

 Thanks for the reply. How can I discard address[0] and address[1]?

[Altera_Forum]

Since you say your ssram has 21 address bits and it spans 2MB, then I guess it uses byte addressing, too. So you should connect address[0], address[1] to ssram a0 , a1. 

If only 32bit access is supported ssram a0,a1 needs to be hardwired to ground.

[Altera_Forum]

Hello, 

 There are still a couple of things that I don't understand. And I'm using some documents to find out the answers. First, Nios Development Board - Cyclone II Edition Reference Manual and Nios II development board schematic. What confuses me is that address lines of ssram are connected like A0 to ssram_a0, A1 to ssram_a1..., but lines ssram_a6 and ssram_a7 are connected to A19 and A20 and they are used for memory extension. Why aren't the lines ssram_a19 and ssram_a20 used for the extension? How do I then address the memory if two bits are excluded in the middle of the address?   This memory has byte addressing but I would like to use it just to write 32-bit data. So SOPC Builder User Guide suggest that two Avalon-MM Address Lines tri_state_bridge_address[0] and tri_state_bridge_address[1] should be unconnected. How will that affect the program code? Do I need to multiply each address by 4 to perform 2-bit left shifting?   I'm sorry if I'm not clear enough, but if necessary I'll try to explain better.   Nikola

[Altera_Forum]

If you memory is 8 bits wide, then you need to have an Avalon slave that is also 8 bits wide. The SOPC builder then includes a 'bus width adapter' than generates four 8bit slave cycles for each 32bit master cycle. 

 It is possible that, to avoid confusion, the tri-state bridge address lines are (usually) defined so that An is address 2^n - which would mean that A0 and A1 wouldn't be connected for a 32bit memory chip. For an 8bit memory chip A0 and A1 would be generated by the bus width adapter.  For SRAM the ordering of the address lines doesn't matter - neither does that of the data lines (nor the data polarity). So they might be switched around to aid the board tracking.

[Altera_Forum]

As I said above, you don't need a0 and a1 if you only perform 32bit accesses. 

So it doesn't matter if you connect them or leave them unconnected (in this case you hardwire to 0 the 2 ssram pins). I suggest you connect them, so you would be able to perform 8 or 16bit accesses, should you need in the future.  In program code you don't need to bother about address conversion. If you defined an alt_u32 pointer like in the code you posted, the compiler itself will take care of generating the correct addresses at 4 steps. You can verify this using the debugger with your code: buffer will automatically access addresses spaced by 4. While a alt_u8 pointer would increment by one.  I'm concerned about the A19 A20 lines connected to sram_a6 and ssram_a7. I don't know your dev kit, nor your ssram device, so I ignore the reason of such a connection. However this explains the behaviour you observed: accesses at addresses A, A+0x10, A+0x20 and A+0x30 drive ssram pins exactly the same, so you definitely always access (and overwrite) the same memory location.

[Altera_Forum]

To avoid misunderstanding , please clarify your exact address lines connection, nikola.  

What dsl says about address ordering is correct. But I understood sram_a6 and ssram_a7 are driven by A19 A20, while A6,A7 from tristate bus don't drive anything, and this would lead to the situation I described. But probably your connection is like dsl thought:   sram_a2 - A2  sram_a3 - A3  sram_a4 - A4  sram_a5 - A5  sram_a8 - A6  sram_a9 - A7  sram_a10 - A8  .... Is this correct?

[Altera_Forum]

Thank you for your help! A problem is a bit clearer now to me. I was trying to find pin description for CY7C1380D, but I couldn't. You are right, my address pins maybe are in the wrong order, ssram_a6 and ssram_a7 are connected to the memory pins A19 and A20. However, in the datasheet of the memory, address pin order in not very clear. For instance, they are described as A0, A1 and A (the rest). But it's not described whether setting A0 to 1 and the rest to 0 writes a byte or 4-byte. If 4-byte is written, then indeed in my quartus I need to assign tri_state_bridge_address[2] to A0 of the memory chip.

[Altera_Forum]

One thing that happened to me when I tried to go through one of the tutorials with a dev board, is that when the sopc component was dropped onto the qsys 'circuit' (or maybe when the whole thing was droppen onto the pcb) the external connections were lined up by position, not name. 

So when I tried to remove/change something everything got connected to the wrong places. I remember trying to get the LED outputs lined up again, but in the end I gave up excluding the item I didn't want.

[Altera_Forum]

Hi, the problem appears to be fixed! As I said ssram_a6 and ssram_a7 were connected to A19 and A20, I changed it to point to the right pins. Also, I left ssram_a0 and ssram_a1 unconnected as SOPC Builder User Guide suggests when using 32-bit external device. Final pin connection order is then ssram_a2 to A0, ssram_a3 to A1,..., ssram_a20 to A18. 

 Thanks once again for leading me to the solution!   Nikola

[Altera_Forum]

One more question regarding external ssram :) 

 My nios is running at 50MHz and I drive ssram with the same speed. Does it make sense to run external memory at clk higher than nios clk?

[Altera_Forum]

I don't think it would give any performance increase. Even if the Nios' data and instruction masters were trying to access the SSRAM simultaneously, I'm not sure the SOPC builder fabric would be able to blend those two together and take advantage on the increased speed. Also any clock crossing domain will add some latency, so you may end up with a slower system. 

It could make sense if you had a fast DMA in your system though. For example a SSRAM and DMA running at 100Mhz, and the Nios kept at 50MHz (if you really don't want to run it at 100 MHz).

[Altera_Forum]

If Nios is your only Avalon master, I don't know if using higher ssram frequency makes any sense. 

Probably it'd rather worsen the timing, because of higher frequency signals and more logic resources are required (a clock adapter needs to be inserted between nios and ssram). You could have some advantage if your ssram requires multicycles or waitstates to perform some operations; it this case a higher ssram frequency could avoid Nios stalls and improve performance. This is useful with SDRAMs, where you have latencies due to precharge, refresh and row selection delays, but with ssram you don't have this intrinsic delays. However, I know this kind of ssram  use some level of pipelining, so I believe it can lead to multicycle bus stalls if you frequently  use random access rather than burst or sequential accesses. You must browse the datasheet for this information and define the optimal design  on the basis of the way your application uses the ssram device.  My advice is testing both configurations with some benchmark and find out which one gives you better results.

[Altera_Forum]

Thanks for the advice! Since my application is not time-critical, for now I'll keep it running at the same speed.