SAMC clocks synchronisation - Page 1
Forum section: electronics / general

author: Simon
author_rank: Unknown
timestamp: August 16, 2019, 08:41:08 am
content: So i read a lot of registers can only be updated with a synchronised clock, so really i can't just write to a register. So how do I handle this ? the only thing i can think of is:Code:while(synchronisation bit not ready){}write registerIs it this simple/crude? or is there another approach? basically i see no way of doing it without having this potential delay, I guess if I don't keep trying to write to the same register over and over it will always be ready?

author: ataradov
author_rank: Super Contributor
timestamp: August 16, 2019, 04:35:08 pm
content: You can freely write into registers. Writes that are waiting on synchronization will simply block util synchronization is done. The reason for having this synchronization interface exposed is to give you an option to wait for the synchronization to complete and not block the bus.This for example allows interrupts to execute while the loop is waiting. If you remove the loop, then write that is blocked on synchronization will prevent interrupts from executing.The maximum synchronization time is predictable, so you may do your calculations and see if it is worth waiting, or you can just write the register.Different peripherals use either a common synchronizer for all registers, or a synchronizer per register. This will define whether you can write to other registers of the peripheral right after a register was written. Most newer peripherals have individual synchronizers.In general, I do not use synchronization in the initialization code, since blocking interrupts there is not an issue. And even for the regular code, if your peripheral is clocked by the same clock as the CPU, there is no reason to worry about the synchronization.

author: ataradov
author_rank: Super Contributor
timestamp: August 16, 2019, 04:37:39 pm
content: There is a minor difference for reads. Some peripherals (mostly low power stuff like RTC) require a separate read request to start synchronization. Those peripherals usually have a way to request a continuous reading using a READREQ register.

author: ataradov
author_rank: Super Contributor
timestamp: August 16, 2019, 04:39:07 pm
content: And if you still care about not blocking interrupts even for a few clock cycles, but can be reasonably sure that writes that will block are not called too often, you can still drop the synchronization wait.

author: Simon
author_rank: Unknown
timestamp: August 16, 2019, 05:06:03 pm
content: so i can read andwrite freely to registers if I don't care about interrupts? I think this mostly affects setting stuff up so no interrupts to worry about.

author: ataradov
author_rank: Super Contributor
timestamp: August 16, 2019, 05:13:53 pm
content: Generally, yes. There are a couple exceptions to this, especially on the read side.

author: westfw
author_rank: Super Contributor
timestamp: August 17, 2019, 01:26:05 am
content: As I read the documentation, the maximum synchronization delay is "several cycles" of theslower clock.That's not a big deal if the peripheral is running off of the CPU clock, but if you're doing something like running the RTC off a 1kHz clock, you might have a problem - lot of things can happen in several milliseconds.It's never been very clear to me just when you'll experience synch delays. Always? Only if you're accessing the register "frequently" compared to its clock rate? Randomly depending on whether the clock edges are?Grr. Just another roadblock to deterministic execution :-(

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2019, 01:34:48 am
content: Synchronization happens every time. The reason for this is obvious. Let's assume that destination clock domain is slower (as you said, 1 kHz RTC clock):1. CPU writes something into a write-synchronized register. This is a register that is located in a different clock domain.2. The actual write happens into the synchronization buffer register that is located in the CPU clock domain. Then that register is marked "busy".3. CPU moves on with execution, from its point of view write is done.4. Then many-many CPU clock cycles later, a clock ticks in the RTC domain. RTC understands that synchronization buffer is busy and has some data for the RTC.5. RTC reads this data and marks the buffer as free.6. Buffer is free and ready to accept new data without a delay.Items 4-5 take those "several cycles of the slower clock". This is obvious, since slower domain has no idea what is going on outside of its slow clock cycles.Now if your next write came in before item 6, that write will be stalled, since there is nowhere to put that data for the slow domain. And that "busy" bit is what SYNCBUSY register shows.BTW, all of this happens in any other MCU, SAM MCUs just expose the guts to the user. Sometimes the clocks are known to synchronous (even if peripheral clock is divided down CPU clock). In this case execution still stalls, but the stall time is predictable.And that also shows the difference between older peripherals, which had one SYNCBUSY bit and one one synchronization register for all target registers, and newer peripherals that have a separate synchronization register per each target register. That's why you get a SYNCBUSY register full of bits.In the second case you can write all separately synchronized registers in a row, nothing will stall.

author: Simon
author_rank: Unknown
timestamp: August 17, 2019, 08:18:21 am
content: Yes that all makes sense. It's not really a clock synchronisation issue, the clocks probably are syncrhronysed but the peripheral registers are on slower clocks as they are under the control of the peripheral not the CPU as this is ARM, the CPU is not Atmel/MCP but ARM and dropped into their periphery cluster that operates on it's own clocks.Se really the name of the game here is to read/write the registers all in one go.

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2019, 04:53:33 pm
content: It does not really have to be this way. You could always clock peripherals from the CPU clock or its small multiple. In this case stalls will be insignificant or non-existent. Almost all other MCU vendors do it this way. The only other MCU that I'm aware of that has similar system is EFM32 from SiLabs (former EnergyMirco).Even Microchip's SAM G5x and SAM V7x series do not have this synchronization issue.There still will be some special handling for RTC and sometimes timer registers. But it is not spread throughout the device.In theory having a variety of clocks allows for better power consumption optimization. But after having worked with those MCUs for quite some time time, I'm not so convinced that it is the case.

author: Simon
author_rank: Unknown
timestamp: August 17, 2019, 05:50:23 pm
content: SAMC is aimed at auto, power saving is a complete waste of time, it's not like they are meant for wearable heart rate monitors....

author: ataradov
author_rank: Super Contributor
timestamp: August 17, 2019, 05:51:21 pm
content: But it retains the peripheral set and design ideas from the other MCUs in the series. Nobody has money to design things from scratch every time.Also, automotive people have some of the hardest sleep requirements. So good sleep currents do not hurt.