Flash read causes two reads

[Altera_Forum]

I have the Stratix III development kit with the 512-Mbit Intel part on it. 

 My command writes appear to be correct, looking at it with SignalTap. I write to the base address a command such as Read Device ID (0x90) and I see the strobes go.   However, when I then perform a direct 16 bit read (for example to read the config register after issuing the above write), I see TWO reads on the flash, i.e.   flash_data_in = IORD_16DIRECT(CFI_FLASH_0_BASE, 5);   This performs a read to flash address 0x00000004 and then immediately to 0x00000006, neither of which are what I want. I am not sure what is going on here except that it looks like some kind of bus width translation issue.   I have a Nios II system with the CFI peripheral set to address width 24 (24:0) and the data width 16. The flash lives at 0x04000000.   Thanks, -Brad

[Altera_Forum]

Have you had a look at how the driver does this? Does the driver code exhibit the same behavior?

[Altera_Forum]

I started looking at it this afternoon but I haven't yet sorted it out.

[Altera_Forum]

this a behaviral of the avalon switch fabric, an old bug/problem/feature 

your master (niosII) is 32 bit your slave (ext flash) 16bit unfortunately the avalon switch fabric fetches 2 16bit values to get 32 bit yes this is not needed as you read only 16 bit but it is implemented that way.  this gets anoying when the external component does something upon a read like all external profibus chips that i am aware of, a read of certain addresses are recognized and clear other bits, hard to find.  normaly these wasted read cycles do not disturb so you can ignore them a 16 bit write does only 1 16bit cycle if you realy want to get rid of the additional cycle you will need to insert some kind of logic that monitors the byteenable as they tell you the truth what byte is realy needed.

[Altera_Forum]

IIRC the nios data master always does 32 bit reads (and asserts all byte enables). Their will be a bus width adapter between that and a 16bit slave - which will convert every read request from the nios into 2 reads of the slave. 

 The only way I know of to avoid that is to make the slave have a 32 bit interface. You then need you own logic to perform the two 16 bit cycles under normal conditions - while allowing a single cycle for programming operations (etc). Or maybe it is possible to map the flash memory at multiple addresses with different properties ...

[Altera_Forum]

no that is not completly correct. 

there is a difference between normal memory access and IORD_16DIRECT as long as you use the IORD functions the byteenable indicated which bytes are needed.  monitor via signaltap these two cycles and have a look at the byteenable i have such a module placed between avalon switch fabric and the external tristate bridge to get rid of these additional read cycles.  in normal memory access it doesn't matter if you read 1byte, 2 byte or 4 byte, the data master will always read 4 bytes (32bit access)

[Altera_Forum]

Thank you all for your input. 

 As far as I understand, the Intel device on the Stratix III dev board is not byte accessible at all--there is no A0, so I don't understand how byte enables would play into this.   It does make sense to me however that the 32-bit Avalon slaves always do 32 bit reads and that's why two 16 bit reads would occur.    dsl, speaking of "Or maybe it is possible to map the flash memory at multiple addresses with different properties ..." I noticed that in the Stratix III example project, they mapped the one flash to two Avalon slaves connected to a single tristate bridge. My colleague and I could not figure out why they would do this, except if it's because there are byte accessible devices sharing the same address and data lines and some odd setup has to be done to make it work.

[Altera_Forum]

The byte enables take the place of the low order address bits. 

 One of the slaves might be a 16 bit slave (connected via a bus width adapter), the other a 32 bit slave (with the high 16 data bits disconnected). Something like that would let you do the specific cycles needed for writing the flash memory (being very careful about the addresses).

[Altera_Forum]

the byte enable is always a 4 bit byte enable , but for 16 bit slaves only the lowest 2 bits make sense and are used. but even if the slave is only 16 bit and so byteenable [1..0] is used the byteenable [3..2] are also indicating (both bits are 0) something. in our case the the upper 16 bit are not requested 

this trick can't be used with the shiped tristate bridge, you have to write your own tristate bridge that takes this trick into account and obeys the upper 2 byteenable bits

[Altera_Forum]

It appears that my writes and reads are now functioning, with the following huge caveat. 

 The datasheet for the flash part (Intel P30 family) says that after performing erase or program or other operations, you have to write 0xFF to the device base address to return to Read Array mode. When I do this, and then perform a read, I don't get my data, I get status.   FLASH_PTR[0] = 0xFF; //put device in read array mode   data_in = FLASH_PTR[DATA_LOCATION]; //read the data   In this case, the data_in equals the status data 0x80 instead of the data in that memory location. However, if I do the following, which is totally not what is specified in the datasheet, it works:   FLASH_PTR[DATA_LOCATION] = 0xFF; //write read array command to data location instead of base address   data_in = FLASH_PTR[DATA_LOCATION]; //read the data   Then data_in is the data I previously wrote!    Does this make sense in any way? I've heard that some flashes violate the prescribed operation.