Forum Discussion
Honored ContributorExternal SSRAM reading/writing problem
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
14 Replies
Altera_ForumAvalon 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
