Vcore Value on ASRock Z87 Mother Boards

[parsec]

Hi Martin, I'm back to create more work for you

You may recall my thread about the Vcore and VID readings on my ASRock Z87 Extreme 6 board, with an i5-4670K. I also understand that you are at the mercy of the sensor chip used on a board, the (lack of) information provided by the manufacture, and what information from Intel is available to you. I hope you also know I am never criticizing your work with HWiNFO, just trying to provide you with information for everyone's benefit.

The subject here is the Vcore reading. For a while now, I've seen screenshots of CPU-Z, and now HWiNFO running on Gigabyte Z87 boards, that shows Vcore readings of ~0.200 volts. That of course is in a CPU idle situation, with SpeedStep, C1E, and C-States enabled, I assume with C-States enabled down to at least C3.

Using identical CPU settings in my ASRock board's UEFI (SpeedStep, C1E, C-States enabled down to C7, using Auto CPU voltage settings, and stock CPU clocks/multipliers), the Vcore readings I get are virtually locked at ~0.900V. Core clocks are at 800MHz, VIDs of ~0.755V at idle. I know the Windows Power plan setting for Minimum processor state affect this, and I have a plan I use with that set to 0% Minimum processor state.

At the same time, I see extremely low CPU power usage, with CPU Package power (Current) commonly below 1.0 Watt, and Minimum values well below 0.1 Watt. The IA Cores Power minimum reading is incredibly low, if correct.

When I saw the ~0.200V Vcore reading in CPU-Z on Gigabyte boards, I assumed that was wrong, since that was shortly after Haswell was released. Now that time has passed, and I'm seeing those values in screenshots of HWiNFO in forums, I've changed my mind. :-/

I realize that you may not be able to get this data from the sensor chip (Nuvoton NCT6776F) and ASRock's implementation of it, etc. Attaching a debug output file that contains data at 800MHz clocks, and at 3.4GHz, switched by changing the Windows Power plan.

I'd be thrilled if you can do something about the Vcore reading for my board. Thanks very much!

---

Sigh, someday I'll learn how to do multiple attachments, with one in the post...

[attachment=712]

 

[Martin]

Thanks for understanding my situation.
I would surely tell you what the Vcore means on this mainboard, but unfortunately I don't know. I believe only ASRock knows for sure, so it might be worth asking their support. I only report the same values as ASRock A-Tuning tool reports. It seems to be closer to VID, but not the same though. Maybe it's VID + offset?

 

[parsec]

Thank you anyway Martin, I understand, I was just hoping to get a nice reading like the Gigabyte Z87 boards do, or I should say what you've been able to provide for them. :-/

The ASR Z87 Vcore reading in HWiNFO seems like it is one half of the CPU Input voltage. That is, when I have CPU Input voltage set to 1.800V in the UEFI, HWiNFO shows ~0.900V. If I tweak the CPU Input voltage in A-Tuning (new beta version, somewhat better in some aspects), I see the Vcore value in HWiNFO change too.

Looking at HWiNFO right now (v4.22-1970), my VIDs are ~0.755V, core speeds of 800MHz, and the Vcore is 0.8960V. Using a Windows Power plan, I can set the cores to 3.4GHz, with VIDs of ~1.055V, and Vcore is still 0.896V. Just FYI, FWIW.

Question, new topic. CPU Package Power, IA, and GT power readings. I get very low power usage reading in HWiNFO at idle, as Haswell is supposed to provide. That is using all C-States, stock clocks, etc. Your opinion on those readings, any good? Realistic? My screenshot above has examples of minimum values. Thanks.

 

[Martin]

Your Vcore observation is interesting, maybe that value should be Vccin and multiplied by 2. What does the ASRock A-Tuning tool display ?

As for the power values, I believe HWiNFO displays correctly what it reads and the low numbers are caused by C-States. How does the power measurement behave when under load (CPU and iGPU) ? Does it then seem to provide correct numbers?

 

[parsec]

The new versions of A-Tuning will display the CPU Input voltage, labeled as Vcore, as ~1.800V.

New UEFI versions for my board now display CPU Input voltage and core voltage (VID?) correctly... I assume...

I have CPU Input voltage set to Fixed, at 1.800V, but see a small fluctuation in the A-Tuning reading, and in the HWiNFO Vcore value, which tracks it perfectly, but showing 1/2 the A-Tuning value. By tracking I mean take the HWiNFO Vcore value, multiplied by two, and the result matches the A-Tuning CPU Input voltage reading.

I noticed in AIDA64 (build 2529), that a reading it labels "VRM" matches the HWiNFO "Vcore" reading perfectly. The Vcore reading is virtually static, and does not at all vary like the VIDs do. It droops a bit during high CPU usage, like classic "CPU Vcore droop", which it is, just Haswell-style.

The HWiNFO Power readings change constantly, as they should. They increase along with CPU load, and decrease at idle. IMO, they seem accurate, make sense, and are reliable (no weird readings.)

I know the C-States and other Z87 power saving features I have enabled cause the low CPU power usage readings. I've been experimenting with them for a while, and am surprised by the very low values I see in HWiNFO. Although they are only momentary, it is still stunning to see sub-one tenth Watt CPU Package Power readings, and the IA and GT core power values are unbelievable. That is why I'm asking about them, and the quality of the data, can they really be that low? I know, what HWiNFO receives as data, is what we see...

Here's a SS of A-Tuning and HWiNFO so you can compare the CPU Input voltage reading of A-Tuning with the Vcore value of HWiNFO. I've watched that Vcore value for weeks, and I could swear it is exactly 1/2 the CPU Input voltage value/reading. Also note the CPU, etc, Power readings. I ran the AIDA64 stress test with HWiNFO running, to show variations in the power usage readings.

[attachment=715]

 

[Martin]

Thanks for the report and analysis. I believe you're absolutely right and the Vcore value reported by HWiNFO needs to be multiplied by 2 and in fact it's the Vccin voltage. I based my adjustments on an older version of A-Tuning/BIOS which probably had this wrong as Vcore, so it seems they fixed it later. I'll do the same in the next build released

 

[parsec]

Thanks for the report and analysis. I believe you're absolutely right and the Vcore value reported by HWiNFO needs to be multiplied by 2 and in fact it's the Vccin voltage. I based my adjustments on an older version of A-Tuning/BIOS which probably had this wrong as Vcore, so it seems they fixed it later. I'll do the same in the next build released

Thanks Martin, I appreciate it! I'm honored to contribute to the accuracy of HWiNFO in a very small way.

I forgot to mention the new versions of A-Tuning are posted in the Beta driver and utility section on a board's download page.

For my own understanding of this, the "multiplied by two" statement is likely not what the fix actually is. Are you dealing with the Vccin VID here? Which would be a binary or hex data value? Or an actual voltage value in a floating point number format?

Multiplying a VID does not work, nor does bit shifting a binary VID.

Just running this through my mind trying to discover how it works! :huh:

 

[Martin]

The value in question comes from the Nuvoton NCT6776F hardware monitoring circuit and is read in units of 8 mV. Most voltage values from this source need mainboard-specific adjustment - to know their meaning and appropriate multipliers to get final voltage values. So in this case it seems VIN0 (which was thought to be * 1 = Vcore) is in fact * 2 = Vccin.

 

[parsec]

The value in question comes from the Nuvoton NCT6776F hardware monitoring circuit and is read in units of 8 mV. Most voltage values from this source need mainboard-specific adjustment - to know their meaning and appropriate multipliers to get final voltage values. So in this case it seems VIN0 (which was thought to be * 1 = Vcore) is in fact * 2 = Vccin.

So it is common to multiply a data value by some factor to get the true value? Interesting. It looks like the VIDs for this voltage have 10mv steps according to the Haswell Desktop processor datasheet.

I'll watch for the next release and report back about the Vcore/CPU Input voltage reading on my ASR Z87 board... unless it is in 4.23-1973 now.

 

[Martin]

Yes, it's common for hardware monitoring chips that some voltages require this. It's because the standard input range for Voltage INputs (VINs) of such chips have a max range of ~2.0 - ~3.0 V (depending on resolution), so to get +5V or +12V for example, mainboard vendors use different resistors (R1/R2) to implement voltage dividers. This is the reason why it's mainboard specific and since there's no way how to automatically know what R1/R2 values are used, a tool reading values needs to know R1/R2 values per each mainboard model. The other problem is that the hardware monitoring circuit doesn't say which VIN belongs to which voltage rail... Thus HWiNFO has a huuge database with such values for most mainboards and some of them are tricky to find out...

VID is a different thing and internal to CPU.

4.23-1973 should fix the Vccin for ASRock Z87. Is it OK now?

 

[parsec]

Oops, what am I doing not trying 4.23-1973... yes it is perfect!

I'd add a screenshot, (if you'd like one) but trust me, it is fine.

I'll fool around with the CPU input voltage a bit, but I'm sure it will be fine. I'll let you know if I find anything, but I highly doubt it.

Thank again for giving us the best these ASR boards can provide, still jealous of the Gigabyte Z87 board's capabilities. Gigabyte actually has two sensor chips on their Z87 boards to enable their readings, given what I've read in this forum. Must be nice...

Thanks for the insight into the voltage readings and how you must deal with them. Hmm, what readings are hiding in all those mystery voltage values I hide? Let's see if I can find another useful one in there.

 

[Martin]

Thanks for the feedback