Nios II problem

At work I'm using a Nios CPU with Quartus 7.1. I've configured it with 512 bytes data and instruction cache, and it uses internal RAM. I have a struct like this:

struct Something { alt_u16 foo; alt_u16 bar; };

When modifying "foo" in a loop in main and "bar" of the same object in an interrupt, it looks like sometimes it behaves like the interrupt overides both variables, e.g. main increments "foo", but after the interrupt has written "bar", the old value of "foo" is there, too. Maybe there is a bug with memory cache updates? When I'm using "int" (or alt_u32), the problem disappears.

Is there anything like this already known? If not, I'll try to extract a simple test case.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss
Loading thread data ...

This really isn't FPGA related. This is actually a classic problem (see comp.arch for lengthy and recurring discussions on this, notably on Alpha). To know exactly what is going on you need to examine the generated code, but I'm willing to bet that this is the classic RMW problem. For a single-thread program, it is correct of read foo and bar as a single 32-bit word, modify just the bar portion, and the write back the full 32-bit word. However in the presence of multiple threads (interrupts can be seen as a thread), this is not valid. If NIOS lack 16-bit writes (doubt it), then you _have_ to use a int to get atomic updates. Otherwise, you may be able to get the desired behaviour by sprinkling volatile in the appropriate places, but IMO, using int is safer and cleaner.

Regardless, study the disassembly of your interrupt service routine to understand this problem (it's a race).

Tommy

Reply to
Tommy Thorn

This was my first idea, too and I have disassembled it and it uses "sth" and "ldh", which loads and saves 16 bit, so I think there might be a bug in the generated CPU core.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

One more hint why it might be a CPU core problem: I have configured Nios to use 32 bit block RAM, so it has to do some clever internal thing, if it writes to the same memory location from the main function and from interrupt.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

"Frank Buss" wrote

Have you tried to bypass the cache? (you need to set the bit 31 of the address for that)

Marc

Reply to
Marc Battyani

How many write enables does the block ram have?

Aren't they oftern seperate for each 8/9 bit lane?

In traditional external memory I'd expect this problem with sub-width writes, but in an FPGA I would think that narrower write enables would be available.

Reply to
cs_posting

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.