CPU Core Voltage (SVI2 TFN) or Core x VID or what?


New Member
System . . .

AMD Ryzen 3700X
MSi Unify x570 Mobo
Cosair 3600 32GB Ram (2x16GB)
650 SeaSonic Titanium rated PS
other odds and ends :)

I've read through at least the last 8 recent pages in the forum and couldn't find anything on this so hoping someone can assist.

I am in the process of OC'n my 3700X and want to be sure that I am paying attention to the correct voltage readings in HWiNFo for the ACTUAL voltage the CPU is getting. In my BIOS I can set it to an all core clock OC, and set the VCore to the (AMD) recommend max voltage of 1.325. Once in windows I launch HWiNFo and start benching to see what Vdroop I get when pushing the system to the max. I want to know what reading should I be looking at to determine the actual voltage that the CPU is getting?

If I look at 'SVI2 TFN', it pretty much stays at 1.325, but if I focus on the 'Core x VID' I see the voltage drop to 1.2xx during all core workloads. If I want to get the most out of my all core OC, then I need to use LLC to help with Vdroop but I don't know which reading to base my choice off of. If I base it off of 'Core x VID', then I know I should start increasing my LLC modes up until I get it to stay stable at 1.325 under all core load in my 'Core x VID'. If I base it off the SVI2 TFN then I don't want to use LLC as it doesn't really drop below 1.325.

My thought process is...
(Turn off PBO, cool'N'quiet,C-States, etc as I am just doing all core OC and don't need any of this as I want it to act the exact same way at all times during use)
1. Set multiplier for CPU
2. Set Vcore to value (for me 1.325)
3. Launch Windows and HWiNFo
4. Start bench and look at numbers
5. If numbers drop below 1.325, then increase multiplier until unstable and once unstable increase LLC mode in BIOS and retest
Step 5 is where I need to know what voltage value/reading I should be looking at in order to ID the voltage flucuation change from the LLC mode change.

I apologize if this has been coverd, but I wasn't able to find it anywhere.


HWiNFO Author
Staff member
You should always rely on the "CPU Core Voltage (SVI2 TFN)", this is the most accurate voltage. VID values are only what the CPU requests from VRM.


New Member
Hi Martin,
At first thank You for this great program. :)

I'm writing because I need little help understanding readings too.
For 3 days I'm fighting with my Gigabyte B450 Aorus Elite - newest BIOS and Ryzen 1600 AF (12nm).
Long story short - My PC wasn't dropping voltage at CPU in idle after OC using Pstates. Right now with clean, updated Windows 10 it is doing so, I think.
The problem i have is that Core #0-6 VID is fluctuating in range of ~0.4-1.35v(Pstate manually set), Vcore reading from Motherboard is acting same way, but SVI2 TFN it is not.

At this point I have no idea at what reading I'm supposed to look. I would be really grateful if You could clarify this for me.




@19arek93 Some BIOS auto settings will set the correct power saving options for low current idle (namely C-States, AMD cool'n'quiet and Power Supply Idle Current) but it depends on the board, how you set the manual Vcore, and which Windows power plan you use.

I wanted to open a new thread exactly regarding the SVI2 TFN sensor not dropping voltage at idle currents (regardless of the polling rate), because I've been wondering that myself. But I think this is just the right thread :)
If your motherboard Vcore reading shows this low voltage idle state, it is really happening. Measuring Vcore from the back of the socket with a multimeter reflects that.
The sampling interval from the SVI2 TFN sensor probably does not register the short idling voltage dips (or there's some capacitive magic), and the same way, the motherboard sensor probably does not show short bursts up to the requested voltage.

HWinfo motherboard Vcore and SVI2 TFN Vcore idling (for reference, polling rate is 2000 ms to have the low current idle state, and voltage is set at 1.200V in BIOS)
Annotation 2020-06-21 161400.png

DMM back of socket idling. Note the short bursts close to 1.20V

Either way, idle power states voltage changes are happening too fast for both DMM and software readings. So an oscilloscope would help!
Last edited:


Well-Known Member

Colleague! Because the sensors of the motherboard control circuits use averaging due to integrating circuits with an unknown time constant, then they can miss short amplitude bursts, and the device you use is not a RMS voltmeter, but the time constant of the integrating circuit in its circuit is hardly shorter than 0,25 - 0,5 sec. usually digital voltmeters are built according to the double integration scheme because it provides a sufficiently small measurement error, but it also has a long cycle of a single measurement, so I would use a peak sensor from a Schottky input diode and a capacitor with a capacity of 5 - 10 nF - anyway, with most digital voltmeters at the input there is a source follower with a MOS transistor providing the input impedance of the circuit several tens of megohms, and to observe the presence of pulses I would use an oscilloscope with a passband of at least 100 MHz.


Oh natürlich! Thanks for the thorough explanation. That's why I'm saying, either way DMM or software don't show the reality. But the point is, if the software superIO Vcore reading fluctuates low, it's safe to say that the idle power state is working, even if the SVI2 TFN sensor's voltage doesn't appear so. The lower PPT reading is also a good indicator of working idle state (and low SMU core power)
Last edited:


Well-Known Member
As a developer, I can name the upper limits in which the deviation of the supply voltage is allowed - up to 2.5V <= ±1%, 2.5V - 5V ±5%, 5V - 12V - ±7%, 12V and above ±10% in the entire range of declared operating temperatures, currents and operating frequencies. When going beyond them, the operability and serviceability of the circuit is not guaranteed. This is primarily due to the technological variation in the parameters of semiconductor devices capable of reaching ±30% - ±40% within a single production batch, and this directly affects the percentage of production defects and the cost of finished products.