The PSoC 6 part you are using has only one SRAM controller, which means the CM4 an CM0+ need to share the SRAM controller. If one processor is accessing anything in the SRAM, the other one needs to wait till it completes the transaction. By slowing down the CM0+, it would affect the time it takes to access something in the SRAM.
Except, op-code fetches are from flash, not SRAM. Toggling a GPIO output bit is also not SRAM. Even if so, throttling the 150MHz M4 core to the speed of the M0+ core because of alternating op-code fetches (or whatever) would be a huge waste. If op-code fetches of the fast core are limited by the speed of the slow core (even when sleeping), then this should NOT be advertised as 150MHz when the MAX speed of the slow core is 50MHz (and it would be common to operate the slow core much more slowly). The very point of having a fast core is so that it can operate....... FAST.
Also, I would assume that since the M0+ core is a von Neumann architecture, and the M4 core is a Harvard architecture, then the op-code fetches are from separate memory spaces (a requirement of the Harvard architecture). The GPIO immediate output instruction being executed by the M4 core does not access Ram at all, and only fetches from program memory that is most likely totally unavailable to the M0+ core. Throttling one, based on the other, seems both pointless and completely counterproductive. Thanks for the effort, but despite somebody marking your answer as "Correct Answer", and it may be a good answer to some other question, it does not seem to answer *this* question at all.
Shows 3 separate SRAM regions and 3 separate SRAM controllers. SRAM contention between a von Neumann architecture core and an Harvard architecture core should not be an issue. Limiting the M4 core to the current operating speed of the M0+ core would be a very bad design decision and is probably NOT what is happening. The question remains,... what *is* happening that causes this to happen, and how do I fix this crippling problem?
Seems like the core is actually still running at 150MHz, but the I/O is limited by the speed of the "Clk_Slow" of the M0+ core. Various combinations of clock rates for "Clk_Fast", "Clk_Peri", and "Clk_Slow" shows that there is some important part of the peripheral system that is clocked *NOT* by "Clk_Peri" but by "Clk_Slow". If "Clk_Fast" and the M4 core is set at 150MHz, and the "Clk_Peri" is set at 75MHz, and "Clk_Slow" is set at, for example, 1MHz, and the M4 core is only executing the 3 machine instructions necessary to increment a register and output it to a port, it will only toggle the port once per 1MHz (500kHz for a full cycle square wave). Multiple increments of the register shows that the M4 core is still actually running at 150MHz, but every time it comes to the output instruction, it stalls for the remaining part of the clock on the "Clk_Slow" M0+.
So, despite what the data-sheets seem to say, the fact is that at least a primary part of the I/O system, that required for the core to actually output a value to a port, does *NOT* run on the "Clk_Peri" but instead runs on the "Clk_Slow". So, to run on low power (M0+ core), and wake up occasionally to do something REALLY fast with the M4 core, I can not just run "Clk_Fast" and "Clk_Peri" relatively fast, and run the M0+ core VERY slow to save power while the M4 core sleeps. Running the M0+ core at 75 MHz just to see, for example, if the Sun rises, seems like an awful waste.
This seems to be a major mis-design of the PSOC 6, and certainly an error in the already somewhat under-documentation of this part of the system. Somebody show me if I am wrong on this, or better yet, what can I do to make it right.
End of my input. Cypress doesn't pay me enough for the time I've spent on this already. It would be so much easier to just put it in the docs.
Sorry for the delay. We were checking internally for the reasons why M4 is not toggling the I/O as fast as before dropping the "Clk_slow".
It turns out the MMIO AHB-Line bus Interface, which is used to access the I/O registers is clocked by the "Clk_slow". That explains why the M4, even running at 150MHz, is not able to toggle at 10MHz when the Clk_slow drops drastically.
Note that you want to keep the M0+ running at higher frequency for other reasons. Some system calls are only executed on M0+, so if you drastically slow down, it will affect their performance. For instance, any system calls related to security and flash writes. The DMA engine is also clocked by the "Clk_slow".
We will update some key documents to point this out. Thanks for sharing your findings.