Yes, the VRC is at offset zero. Note that in RCCE in RCCE_lib_pwr.h, line 25, RPC_PHYSICAL_ADDRESS is defined at 0xFB00 0000.
Yes, it is write-only. This is the casue of a lot of our issues. There is currently no easy way for a core to find out what the voltage is. You have to go out onto the MCPC and pass the value back, which is possible but takes forever in computer time.
Thanks to Rob for information about the following questions. The line numbers refer to RCCE_power_management.c
1.) Is the processor halted/sleeping/waiting during execution of line 583? If so how long?
If no other voltage change requests are pending, this call does not stall the core. But if there are, the wait depends on how many are queued up. The ballpark is a O(100K) core cycles per queued request at nominal frequency (533MHz). There is only a single queue.
2.) Does it also wait at line 584? If so how long?
Yes, this call causes a wait, see previous answer. There is strong suspicion that back-to-back issue by the same core of two voltage change requests does not cause a long enough wait for the target voltage to be reached, but research has not provided a definite answer. Research constraints on this end are preventing further investigation. Please report your results.
3.) How does the commanding core 'know' the voltage has reached the commanded voltage setting? Please give hardware details.
We can't actually read the voltage from the core (unless by invoking something on the MCPC) … this has been the issue all along. And some evidence indicates that RCCE_wait_power() returns sooner than it should and that’s why some people make three instead of two requests.
4.) The comment "do it twice, see findings by Nikolas Ioannou" preceeds the code... Where are these findings published?
Nikolas, are you listening? We have a preliminary research report from Nikolias, but do not have permission to make it public. Nikolas, if you have a public version or have published the paper somewhere, can you provide a link?