double write pulse using only one single IOWR_16DIRECT

--- Quote Start ---

Half a year later.

Today we encountered exactly the same SOPC bug.

Unlike your case, for us Data Cache Burst is important since we plan for heavy use of DDR SDRAM. So your workaround wouldn't work for us.

Of course, we can manually edit SOPC builder generated file multiplying chip select by byteenable, but it's ugly and doesn't fit our development process.

Is there a hope for actual bug fix?

Or, may be, less ugly workaround that will allow us to use both dcache bursts and cfi flash at the same NiosII CPU?

--- Quote End ---

Hi,

Maybe you can escalate the issue to Altera Support. If you're still fresh about the issue, you may send them the archive of your project for them to "reproduce".

Hopefully this will solve the bug.

--- Quote Start ---

Hi,

Maybe you can escalate the issue to Altera Support. If you're still fresh about the issue, you may send them the archive of your project for them to "reproduce".

Hopefully this will solve the bug.

--- Quote End ---

That what I probably have to do, but I am too lazy to start answering questions like "Did you try 10.0 SP22?, Did you reproduce in latest hottest 10.0.0 preliminary beta?" etc, etc....

Now to the good news. We found a workaround.

Just insert Avalon-MM pipeline bridge without burst support between in between NiosII CPU and cfi flash. The bridge converts single-word burst writes coming from the CPU which are triggering the bug into regular 32-bit writes with properly set byteenables that altera_avalon_cfi_flash module capable to deal with.

That's actually was easy. Doesn't compare with obscure, hard to reproduce, DDR2 on Arria2GX problems that I am fighting for majority of the recent week :cry:

--- Quote Start ---

That what I probably have to do, but I am too lazy to start answering questions like "Did you try 10.0 SP22?, Did you reproduce in latest hottest 10.0.0 preliminary beta?" etc, etc....

--- Quote End ---

lol, can't agree any stronger (or more strongly?!? :D).

--- Quote Start ---

Okay,

Here's what I found out!

When having a 16-bit device mapped to 32bit nios via tristate-bridge, every IOWR_16DIRECT will initiate 2 accesses to the device. Ex: IOWR_16DIRECT to 0x04 will write to location: 0x04 and 0x06.

My question is: is my observation true? Why is it designed that way? If it is that case, the CFI-flash will go crazy because all the command sequence will go wrong. I'm sure that someone already succeeded in getting the CFI flash working. How to work with CFI-flash ????

... Any reference design available?

Thanks a lot.

Jeff

--- Quote End ---

Hallo,

I have an similar problem. I would like to connect a memory mapped slave, with a 16-Bit wide data interface to the nios ii. Then I do the IOWR_16DIRECT() operation from nios and try to set some registers inside the slave depending on the addresses.

Unfortunately addressing fails. Maybe the multiple write operations causes this.

Now I extend the data interface to 32-Bit and use IOWR() (ignoring the upper 24 bits) -> everything works fine.

surprisingly (http://www.dict.cc/englisch-deutsch/surprisingly.html) the IOWR_8DIRECT() method works fine. I use it several times to access registers of slaves with a 8-Bit wide data interface.

Could somebody explain this behavior? :confused:

Greets

Sim

The nios cpu always does 32bit master accesses, so if your slave is narrower than 32bits a 'bus width adapter' is added - that converts the single 32bit cycle into 2 or 4 cycles with the approprate byte enables asserted.

Moreover the nios always asserts all 4 byte enables on reads.

You really are better off writing a 32bit wide slave.