Forum Discussion

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

Weird system config, weird system behavior

I've got a weird system configuration and in testing it, I'm seeing some weird behavior that I hope someone can explain.

The configuration:

- custom hardware based on the Cyclone III (EP3C55) that utilizes a Asynchronous SRAM that is 1024kx16bits. The byteenable lines are hard-wired low so I believe we are hosed for using byte accesses on this part.

- NIOS II/f w/instruction & data caches defined. No MMU or MPU or any DMA components configured.

- Connection from the NIOS II to the SRAM is via a Avalon MM Tristate Bridge. The bridge connects to the SRAM component using a component .TCL file... similar to the one posted here: http://www.alteraforum.com/forum/showthread.php?t=26487

- I've created an application & bsp for the above configuration using the MemTest template provided by Eclipse. I set things up so that everything executes out of on-chip memory.

The behavior:

- The RAM test fails address bus testing (MemTestAddressBus). I know that it also fails byte and half-word access testing (MemTest8_16BitAccess).

- When I single step through byte and half-word access testing via Eclipse, and monitor memory, I see the single byte writes updated a 16-bit word in memory. For example, writing "0x05" appears to write 0x0505 to the target location. I attribute this to the fact that our hardware doesn't have the byteenables properly wired up. This also happens when I try to write directly to memory from the memory monitor in Eclipse.

- When I execute this same code via nios2-console, I get similar results. HOWEVER -- and this is the weird part, when I do a "byte" write in the nios2-console followed by a "dump", it looks like byte writes are *working*. What's up with that? For example, when I execute:

> byte 0x200000 0x12 0x34 0x56 0x78

> dump 0x200000..+0x10

I see that 0x200000 looks correct. I thought this may be some sort of caching thing, so I've also tried "memcache unmap all" to disable any caching, but I get the same result.

Since our byteenables are not wired correctly, I don't see how nios2-console can possibly work correctly. I'm baffled. Is it writing to a local, console specific cache and simply fooling me that it's making those writes to external SRAM? Or, is it performing a 16-bit write on the output whereas the Eclipse monitor performs 8-bit writes?

Any insight will be greatly appreciated.

Thanks,

--tim

1 Reply

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

    I learned about Signal Tap II and did some minimal internal logic tracing. The 8-bit byte writes place, for example, "0x0505" on the data bus when writing 0x05 to the external RAM part. Since we don't have byte lane enables happening, that explains the funkiness when updating our RAM location. When updating memory via the nios2-console, it writes a 16-bit value even when doing byte writes.

    What is not clear is how nios2-console "knows" what the other half of the byte is. I assume it must read the location, modify the corresponding upper or lower byte, and then write the 16-bit result or maintain a local cache or something. I didn't too any in-depth tracing using Signal Tap, but am guessing something along these lines is happening.