XMC1100 NVM wait states documentation?

[User7804]

Hello All,

where is the speed of the XMC1100 flash documented?

Thanks in advance,

Oliver

[#2]

Hi,

In the data sheet, there is a section on Flash parameters (section 3.2.5) which says a read time per word of 50ns. I figure that means 1 wait state at a CPU clock of 32MHz (31.25ns period).

[User7804]

T.O.M. wrote:
...read time per word of 50ns. I figure that means 1 wait state at a CPU clock of 32MHz (31.25ns period).

I'm afraid this assumption is not valid. My experiments show that not every access is affected by wait state (burst read?), and as far as I see, it doesn't depend on the CPU clock speed (configured automatically or by the user?).

Oliver

[#4]

It is described in the reference manual that read granularity is 1 word and wait states are automatically inserted. There is no mention of such a burst read feature, which would be useful for linear code execution. Therefore I doubt that it is there, but I may be wrong. 😃

[User7804]

Doubt is good, proof is better.

I made a simple test: A sequence of str instructions takes 2c per instruction when executed from RAM and 2-3-2-3... cycles when executed from Flash. That was the reason for my original posting.

That's not unusual and often documented in controllers from other companies. The read granularity is not affected, but one read may pull 64 bits from the flash memory, so the second word is available without latency.

What I disliked: Setting the CPU clock to 8MHz resulted in the same wait states, although the Flash should be fast enough. Other CPUs wait states can be configured. Maybe also the XMC can be configured, but I didn't find it in the docs.

Oliver

[chismo]

Hello all,

Please refer to the latest versions of the following documents for Flash wait state information:
1) Section 8.3.2 on memory read of the reference manual.
2) Section 3.2.5 on Flash memory parameters of the data sheet.

In general, the Flash memory inserts automatically wait states during memory read if needed.
Read accesses to Flash require 0 wait state for MCLK < 8 MHz and typically up to one wait state for MCLK >= 8 MHz.

[User7804]

Hi chismo,

thanks for your information.

Please refer to the latest versions of the following documents for Flash wait state information:

I did so before asking.

1) Section 8.3.2 on memory read of the reference manual.

8.3.2 states: "The NVM will insert waitstates during memory read automatically if needed", that's rather vague.

2) Section 3.2.5 on Flash memory parameters of the data sheet.

3.2.5 states: "Read time per word typ. 50ns" but this doesn't help without a knowledge about read-ahead and buffering.

Read accesses to Flash require 0 wait state for MCLK < 8 MHz and typically up to one wait state for MCLK >= 8 MHz.

I didn't find this information in the docs, where did you get it from?

And why are there wait states at 8MHz even though the DS states 50ns access time? 50ns seems to be fast enough for zero WS at much more than 8MHz.

After all "up to one wait state" is still vague. As I demonstrated, I found a 1-2-1-2... delay by experimenting. I would prefer to get this information from the docs.

[User7804]

correction: "1-2-1-2... delay" was nonsense. The experiment was a sequence of str instructions yielding 2-3-2-3 cycles.

[chismo]

Hi Oliver,

Could your observation about the instruction execution cycles be due to the pipeline effect of the Cortex-M0 processor? I am not a Cortex-M0 expert but I am thinking:
- Cycle 1: Fetch of two 16-bit instructions from the Flash
- Cycle 2: Due to the insertion of 1 wait state, fetch is completed only in this cycle
- Cycle 3: Decode of the 1st instruction
- Cycle 4: Execution of the 1st instruction; decode of the 2nd instruction
- Cycle 5: Execution of the 2nd instruction
The above gives 5 cycles and if execution is from RAM, I remove the 1 cycle due to wait state.

From the Flash point of view, there is no additional prefetch of the Flash memory. Every read access gives 1 word.

Unfortunately, the information about the number of wait states with regards to MCLK is not available in the documents today. We will address this in future versions.

Read access time of 50ns is under nominal conditions. We have seen under worst case conditions that 0 wait state is true only when MCLK is less than 8MHz. When MCLK is 8MHz and above, it can be 0 or 1 wait state, depends.

[User7804]

Hi Chismo,

thanks for taking care to improve the documentation.

You may be correct with CM0 pipelining, but as seen by the user, I simply need to know how fast it gets.

I still can't follow regarding 50ns vs. 8MHz or what "worst case conditions" might mean.

Oliver

[chismo]

Hi Oliver,

I have found out that there are early samples of the devices that runs always with 1 wait state. The device that you have should be one of these. The errata sheets needs to be updated to identify the samples having this behaviour.

Regarding your previous question on worst case conditions, I am referring to temperature effects and process deviations which worsen the Flash access time (time Flash takes to output the data) and access delay time (time for Flash to receive the read request).

And further to my comments on the number of wait states should be 0 or 1 when MCLK is >8MHz, this is actually not correct. I have just found out that it can be up to 2 wait states as well. Unfortunately, I also do not have the full details so my recommendation for now is that you would need to consider the worst case of always 2 wait states per Flash access even though this seems excessive.

I will be following up on this topic with the relevant colleagues and I will update on the forum again when I have more details.

[User7804]

Hi Chismo,

your posting implicated that the Flash wait states are not fixed (programmed, configured) but variable over temperature and process variations. I don't want to believe this.

Do you have any idea when you get detailed information?

Oliver

[chismo]

Hi Oliver,

Sorry, I still have no visibility on this.

Alternatively, could you share your application's requirements specific to the Flash performance? You need a deterministic timing for code execution? Any chance that you can execute the timing-sensitive code from SRAM?

[User7804]

Hi Chismo,

for a loop with tight timing requirements (reading and processing data from the ADC at full speed), I need to know how far the timing can change.

You wrote "temperature effects and process deviations" and "up to 2 wait states", so I need more information what can happen.

IMO it should be stated clearly in the documentation, as many other things still missing.

The XMC1100 is a great piece of silicon, but it's documentation progress is disappointing. The new errata sheets cause more questions than insight.

Oliver

[chismo]

Hi Oliver,

I have gotten some updates regarding the Flash wait state information. Basically for each Flash access, it takes:
- for MCLK < 8 MHz: 0 to 1 wait states
- for MCLK >= 8 MHz but < 16 MHz: 0 to 2 wait states
- for MCLK >= 16 MHz: 1 to 3 wait states

These numbers are expected to vary within the mentioned range:
- across different Flash accesses for the same device
- from device to device
- with temperature and process deviations

To minimize the effect of the adaptive nature of the wait states generation, besides executing the timing sensitive code in SRAM, another option would be to make use of the timers to regulate the execution time of these codes.

With regards to the documentation, the wait states information will be added to the next release of the data sheet. It would also be greatly appreciated if you can feedback on the other missing/confusing information in our documents today.

Regards,
Chismo