DFI NF4 Ultra-D vdimm mod: come inside.

[flexy]

i hope people *here* dont confuse the VTT droop with the VDIMM droop when VDIMM is close to 3.3 rail ? I know they confuse those two issues elsewhere.
VTT droop also occurs with LOWER VDIMM (eg. 2,8 or 2,9) where VDIMM is NOT fluctuating at all.

The "VDIMM fluctuates" is a different story than "VTT droops".

VTT drop: Occurs ALWAYS (?) no matter what VDIMM is at and what rail you grab your vdimm off.

VDIMM drop: Occurs if your VDIMM is too close to your 3,3 rail...eg. starts here once i set VDIMM to 3.0, gets really bad at 3.1 (like EMC showed yesterday)

[Tony]

I have modded an A00 with vdimm and VTT i will see what effect this has if any on overclocking etc.

[uwackme]

You could use a diode to connect the 5V rail to the Vcontrol input, as this will lead to a .7v DROP in the voltage at the pin...4.3V.

Keep the leads as short as possible. Dont use long leads on things, they act as antenna's to add noise into the circuit.

[EMC2]

1 . Use 5V is not recommend by richtek in recent batch of regulator ... Using 4V is one thing that can be consider ...

2 . The nominal center of actual board is different from dummy load testing like the richtek datasheet ... The patter in memtest8# already cover the full current sinking/sourcing mode of this regulator , I will only check the peak-to-peak range of the result of actual board ...

3 . 94mv in my original measurement is not very good , but acceptable when you consider that the VTT is 1.45V but not 1.25V in the richtek datasheet ... And this is the TCCD/300MHz/1T case , if the DRAM is BH5/CH5 type or the DRAM frequency is much lower , the value will be smaller ...

4 . I don't know what happened to your board , but I have tried 4 different board(different batch/model) ... All of them act very close to the pic I post ...

1. I noticed the note for the ACL5 part, but you aren't using that version are you? And yes... 4V should be fine since Vmem can reach 4V and is thus already used...

RT9173 Discussion picture:


2. Yes, the nominal center of the actual board may be different, but it still exists... and the Vtt still goes in one direction due to sourcing current and the other direction due to sinking current... nothing to due with the MB will change that. Looking only at the peak-to-peak variation is misleading... and doesn't take into account assymetrical loading issues. The nominal center by design of the part is Vref+Vos. You can either use Vref as nominal or Vtt @ minimal/zero load. It's pretty obvious when looking at what Vtt does under testing that it does have a real and measurable center position. One example would be it's value during Memtest T5, where it stays rock solid and equal to Vref... another would be with Memtest paused, where you see an apparent small Vos in the positive direction.

3. No it isn't very good... especially when assymetry is taken into account. Regarding the 1.45V versus 1.25V - as shown in the discussion pic I put together from RichTek's spec, the variation of Vtt is almost purely a function of load current, not Vtt level, as can be seen and is annotated in the pic. That's also why the % delta for DDR1 is less than for DDR2. Note that the 3A delta is right at 2X the 1.5A delta as well. From my testing to date, this is confirmed, as I see no appreciable difference due to the level of Vtt/Vmem.

Regarding whether it is related to TCCD or 300Mhz or frequency in general, here's some captures using CH5 based DIMMs at two different frequencies (and lower than the TCCD captures). Note that these were both taken with everything EXCEPT the memory speed kept constant.

240Mhz UUT Memtest T8:


120Mhz UTT Memtest T8:


You'll notice that the Vtt magnitude change remains the same between 240Mhz and 120Mhz MemClock... and right at the same as what was seen with the TCCD at 300Mhz.

4. I don't think it's just my MB... but since I've used 2 different PSs, 3 different CPUs, and 3 different sets of memory of 2 different kinds, it is restricted to the MB in general.

I do think you aren't seeing the very large changes that I've recorded because of test condition and equipment differences most likely. Two questions come to mind after further testing tonight...

a) have you used the test conditions in Windows that I sent you the info on?
b) have you run those test conditions with a Winnie rather than an FX?
c) what Vcore levels have you done testing with, just default or higher?


I did go back this evening and also re-checked the "large step" conditions I had previously seen in windows, this timing using 2x512MB of CH5 based DIMMs. The first run I did not see the magnitude of change I had previously. So... I sat down and analyzed all the differences between the two sets of runs.

a) CH5 versus TCCD
b) 200Mhz FSB vs 295Mhz FSB
c) 200Mhz MemClock vs 295Mhz MemClock
d) Vmem 3.3V versus 2.9V

Everything else was exactly the same (ok... temp might be +/-2C different)... including external test equipment, probe points, etc.

So I decided I would eliminate the differences I could easily, one at a time. First thing I did was go into the BIOS, set the FSB back to 295Mhz, dialed in a memory ratio of 4/5 to keep the UTT speed down, and re-ran the test.

Here is 295x9:


Bingo - we have the problem showing up again. Now, was it the higher frequency on the memory or on the CPU. So I made a series of 3 more runs, each one with everything EXCEPT the CPU multiplier the same:

295x8 Win MemTest:


295x7 Win MemTest:


295x6 Win MemTest:


The last run (295x6) is very close to the first unrecorded run (scope trigger set too low, looking for a bigger droop) where setup was 200x9, 1:1 on memory. Note how the magnitude of the change goes down each time.

This actually makes some degree of sense... one big thing in common with the majority of conditions under which the large scale (>100mV) droops occur are when the CPU and memory utilization rate changes by a large amount and the speeds are relatively high.

The only other condition to date that I've seen cause the large magnitude droop on Vtt is the video switchover that occurs during Win2K bootup... but it is another potential large scale current demand change on the MB and full-bore utilization to low utilization...

It appears now one of two things are going on with the large scale droops - either the regulator is loosing it (stability) do to power demand changes or there is some condition where we get a higher than expected load demand on Vtt due to some unforeseen combination and the regulator's overcurrent circuit is tripping.

I don't know if you test this with 7/04 bios ... With 7/04 bios , the period should be within 10ms in the 1st stage and 2nd stage ... I can not explain the detail of all the bios programming voltage transition limitation , it's a protection behavior I set ...

I did that testing with 510fixed BIOS. I haven't looked at it yet with 7/04, but I will. Hopefully the shorter duration/method prevents the overshoot I saw (if not may need to raise it halfway, pause, then the rest of the way).

I can not explain the detail of all the bios programming voltage transition limitation , it's a protection behavior I set ...

hmmmmmm... this "protection behavior" occurs at the same relative time as when the Video is re-initialized (right after VGA detect/POST) and when video modes are changing (my test bed monitor makes a distinct, audible 'click' when video modes are changed)... one of the conditions that I've seen the large scale Vtt fluctuations is during the Windows initialization of the video and video mode change... related perhaps?

Peace

[EMC2]

I have modded an A00 with vdimm and VTT i will see what effect this has if any on overclocking etc.

Curious which Vtt mod you decided to try out... and look forward to your efforts

--- uwackme ---
Just FYI... Vctrl is a to change... it's on the TAB of the part, so the part has to be totally removed and isolated (plus HS), then put back down to connect up the other 4 pins to make a Vctrl mod Someone want to give me a mod-mule MB to use tho...

[suio]

EMC2 and OSKAR,

I noticed the same voltage behavior with OCZ PC3200 Gold BH-5 (OCZ4001024ELDCGE-K) memory a while back. I no longer see such issue exists with the OCZ Plat. Rev2 TCCD memory. I even posted the question at DFI-Street forum about a week ago. No one responded of course.

P.S. My video card is acting strangely (BSOD every 2-3 hours) in recent days. Any possibility the NF4 Ultra-D board could do something to the video card?

[alpha0ne]

EMC2 and OSKAR,

I noticed the same voltage behavior with OCZ PC3200 Gold BH-5 (OCZ4001024ELDCGE-K) memory a while back. I no longer see such issue exists with the OCZ Plat. Rev2 TCCD memory. I even posted the question at DFI-Street forum about a week ago. No one responded of course.

P.S. My video card is acting strangely (BSOD every 2-3 hours) in recent days. Any possibility the NF4 Ultra-D board could do something to the video card?

On two occasions after changing bios upto the 704 then restarting after reconfigure (I have done this on hundreds of boards/chipsets/CPU's so no stranger ) I have noticed SEVERE screen corruption that looks like the graphics card (X800) is being either overvolted or the pci-e bus is wayyy over speed

I have only ever come across such behaviour in the past when I have overvolted due to modding a vid card done back in my 8500 days

[flexy]

nice job by you guys measuring and all that

Btw. do we have that vtt issue no matter what DIMM slots we use and if it's related to load created by the DIMMs, and do we get smaller drops by using eg. only one dimm ?
Just wondering.

[groovetek]

Well I certainly haven't studied enough electronics yet to analyse and comment on the graphs and technical explanatios above, but a question to Oskar Wu and/or EMC2:

My CPU died the second I pressed save settings and exit in the 704-2 BIOS. I had changed VID to 1.200, VID special to *133%. This is a setting I had used in previous BIOS's and found gave me the optimal VCORE for my Venice 3000+ 0517 EPMW. The BIOS would read 1.56V, which was perfect for allowing 3ghz prime/bench/stressCPU stable on air cooling.

Now, of course you would understand that I am very frustrated with losing such an amazing chip, and naturally that I would point my finger at the BIOS, so it would be great if knowledgeable people like you could look into the issue and see if the BIOS did introduce some voltage control problem.

I have tested the RAM and graphic card, both are working fine in my friend's system, and my CPU is confirmed to be dead. No power even runs through the chip, since no heat is being generated at all.

I haven't yet tested the DFI NF4 Ultra-D board with another CPU yet, despite having thoroughly resetted the CMOS. I am very apprehensive about sticking another CPU into this board, especially with the 704-2 BIOS still in it. My response from DFI technical support was to RMA the board, and that there may indeed be something wrong with the BIOS... but that's all I've heard, and I've sent an in-depth email regarding the symptoms, to see if they can take the information and use it constructively to debug or verify the 704-2 BIOS, and let me know if the BIOS was at fault or if it was the board, or if (unlikely) it was just something else or some freak incident. I haven't had a response for days, but that's OK, I'm a patient person. I have ordered an Abit AN8 though... don't want to potentially risk other hardware.

This was the original response from DFI after I had briefy explained my problem:
_____________________________
Dear Customer

Thanks for your letter of July 06. According to your problem description, there might be something wrong with BIOS. Please contact with your retailer and apply for RMA service. I apologize for the inconvenience may cause you.

Sincerely Yours truly,

Tech Support

DFI Inc.

Issue NBR: (~~~~snip~~~~)
___________________________

So this is the reply I made, and seeing as there are many knowledgeable people here - maybe you can take it in and see something that makes sense... I'm no electrical engineer yet, so my theories and stuff can be radically impossible, so please take that into consideration. I do however, have alot of experience with hardware, and have been overclocking for a very long time.

___________________
Hello DFI,
Thankyou for the reply. Unfortunately after extensive testing and debugging of various components in my system today I have found that my Venice CPU has died, most likely as a result of a bug in this 704-2 BIOS (Oskar Wu, Hellfire, Merlin version).

I believe the VID control may have a bug, allowing the board to spike the voltage when using certain VID & VID special settings. I believe this is the reason, because usually the commonly experienced symptom of constant over-voltage (typically around >1.75v for 0.09u A64 CPUs) is that the CPU is gradually damaged due to electron migration, however in my case the CPU instantly lost power after saving settings and exitting. The VID selected was 1.200 with VID special control of 133%, which I have used previously with other BIOS's to achieve a 1.56vcore BIOS reading, far below the maximum tolerance of such A64 chips, especially when temperature was well under control. I have also observed that there is literally no electricity running through the CPU (CPU is generating no heat at all, motherboard showing 4 diagnostic LEDs, usually indicating CPU is not even being detected), and to me this sounds like a blown trace or maybe a blown surface-mounted component - which usually would not occur unless a suddenly excessive high voltage is applied. Therefore, I believe the BIOS caused the motherboard to suddenly apply the max vcore that can be supplied immediately after I saved settings and exitted BIOS. I am concerned that other people may be affected, and so I think it's important that Oskar Wu, or whoever is the head of the DFI BIOS development team to be notified of the possibility of the presence of a bug in this BIOS. Again I have to emphasize that I cannot be 100% positive that the BIOS is at fault, but logically it seems to be the case.

Therefore, I speculate that the motherboard itself may still be functional - however I will not know until my new CPUs arrive. But as you would understand, I'm feeling VERY apprehensive and worried about testing my new CPUs on a board that is potentially dangerous. I do not want any more CPUs to be possibly destroyed by the board, even though I have resetted the CMOS - I still cannot feel secure about this. And yet on the other hand, if I apply for RMA with the board and they say there is no problem with it, then it would have been a big waste of time, and also money.

What is your suggestion to be the best solution to my situation? And, typically, under such circumstances, would AMD's RMA system cover the death of my Venice 3000+ CPU if it was caused by the motherboard? I understand that overclocking is not covered by CPU manufacturers, but in such a case, the death is most likely (as I stated before, I cannot be 100% positive) not directly to do with overclocking, but motherboard/BIOS related. Indeed, as you said, this has caused a large inconvenience for me, not only because I have go to through this RMA process, but mainly because I have lost a truly special CPU.

Any constructive help would be greatly appreciated, thankyou very much for your consideration thus far.

Kindest Regards,
John.
__________________

Any help would be GREATLY appreciated guys!

[timpanogos]

groove, fwiw ... I found that messing around with the various vcore settings can be very touchy ... I also work for low vcore with high multiplier, but that 1.20/133% was a no poster for me. try to stay in the 1.30 to 1.35 ranges with various multipliers..

however, a vcore conversation here is the wrong place ... this is a very import thread to many and we should try to keep this focused on vtt/vdimm issues at this point.

you should post support issues to dfi-street or start a different thread at this site.

just my 2cents

[Malves]

Didn't read the long post about the vcore. Anyways, for better vcore control, just do this vcore mod.

[Ubermann]

On two occasions after changing bios upto the 704 then restarting after reconfigure (I have done this on hundreds of boards/chipsets/CPU's so no stranger ) I have noticed SEVERE screen corruption that looks like the graphics card (X800) is being either overvolted or the pci-e bus is wayyy over speed

I have only ever come across such behaviour in the past when I have overvolted due to modding a vid card done back in my 8500 days

I have seen the same thing, it looks like a voltmod that has gone bad but when you reboot its back to normal.
But this was with an older bios and an untouched X850 card.
But you get eyes big as an octopus and heart stops beating when you see it.

[wtz54321]

Well I certainly haven't studied enough electronics yet to analyse and comment on the graphs and technical explanatios above, but a question to Oskar Wu and/or EMC2:

My CPU died the second I pressed save settings and exit in the 704-2 BIOS. I had changed VID to 1.200, VID special to *133%. This is a setting I had used in previous BIOS's and found gave me the optimal VCORE for my Venice 3000+ 0517 EPMW. The BIOS would read 1.56V, which was perfect for allowing 3ghz prime/bench/stressCPU stable on air cooling.

As far as I know , this is beta bios ... And anything that screw up things could be happened ... You should not use it if you are ok with previous bios ...

[groovetek]

yes, well, previous bios's had issues with async overclocking with my G.Skill UTT BH5 GH kit.

it looks like at dfi-street, someone has killed their FX55 sandiego the exact same way with this BIOS... maybe it's coincidence that it's with a 704 BIOS as well, but me thinks otherwise.

[alpha0ne]

Well the official 310 bios is even worse. I lost my first pair of RAM with it.

IMHO the err 'official' 310 bios is a 'kin disgrace

[groovetek]

i think the weird graphics corruption thing could be indirectly related to more voltage controlling bugs that could potentially be present with this BIOS.

[wtz54321]

yes, well, previous bios's had issues with async overclocking with my G.Skill UTT BH5 GH kit.

it looks like at dfi-street, someone has killed their FX55 sandiego the exact same way with this BIOS... maybe it's coincidence that it's with a 704 BIOS as well, but me thinks otherwise.

I don't see any information that 7/04 bios solve the async issue ... So before you update to a bios that is still beta , you should know that could be happened , especially when there is unknow amount of ppl does not have any problem with the beta bios ...

[tictac]

Well I certainly haven't studied enough electronics yet to analyse and comment on the graphs and technical explanatios above, but a question to Oskar Wu and/or EMC2:

My CPU died the second I pressed save settings and exit in the 704-2 BIOS. I had changed VID to 1.200, VID special to *133%. This is a setting I had used in previous BIOS's and found gave me the optimal VCORE for my Venice 3000+ 0517 EPMW. The BIOS would read 1.56V, which was perfect for allowing 3ghz prime/bench/stressCPU stable on air cooling.

Now, of course you would understand that I am very frustrated with losing such an amazing chip, and naturally that I would point my finger at the BIOS, so it would be great if knowledgeable people like you could look into the issue and see if the BIOS did introduce some voltage control problem.

I have tested the RAM and graphic card, both are working fine in my friend's system, and my CPU is confirmed to be dead. No power even runs through the chip, since no heat is being generated at all.

I haven't yet tested the DFI NF4 Ultra-D board with another CPU yet, despite having thoroughly resetted the CMOS. I am very apprehensive about sticking another CPU into this board, especially with the 704-2 BIOS still in it. My response from DFI technical support was to RMA the board, and that there may indeed be something wrong with the BIOS... but that's all I've heard, and I've sent an in-depth email regarding the symptoms, to see if they can take the information and use it constructively to debug or verify the 704-2 BIOS, and let me know if the BIOS was at fault or if it was the board, or if (unlikely) it was just something else or some freak incident. I haven't had a response for days, but that's OK, I'm a patient person. I have ordered an Abit AN8 though... don't want to potentially risk other hardware.

This was the original response from DFI after I had briefy explained my problem:
_____________________________
Dear Customer

Thanks for your letter of July 06. According to your problem description, there might be something wrong with BIOS. Please contact with your retailer and apply for RMA service. I apologize for the inconvenience may cause you.

Sincerely Yours truly,

Tech Support

DFI Inc.

Issue NBR: (~~~~snip~~~~)
___________________________

So this is the reply I made, and seeing as there are many knowledgeable people here - maybe you can take it in and see something that makes sense... I'm no electrical engineer yet, so my theories and stuff can be radically impossible, so please take that into consideration. I do however, have alot of experience with hardware, and have been overclocking for a very long time.

___________________
Hello DFI,
Thankyou for the reply. Unfortunately after extensive testing and debugging of various components in my system today I have found that my Venice CPU has died, most likely as a result of a bug in this 704-2 BIOS (Oskar Wu, Hellfire, Merlin version).

I believe the VID control may have a bug, allowing the board to spike the voltage when using certain VID & VID special settings. I believe this is the reason, because usually the commonly experienced symptom of constant over-voltage (typically around >1.75v for 0.09u A64 CPUs) is that the CPU is gradually damaged due to electron migration, however in my case the CPU instantly lost power after saving settings and exitting. The VID selected was 1.200 with VID special control of 133%, which I have used previously with other BIOS's to achieve a 1.56vcore BIOS reading, far below the maximum tolerance of such A64 chips, especially when temperature was well under control. I have also observed that there is literally no electricity running through the CPU (CPU is generating no heat at all, motherboard showing 4 diagnostic LEDs, usually indicating CPU is not even being detected), and to me this sounds like a blown trace or maybe a blown surface-mounted component - which usually would not occur unless a suddenly excessive high voltage is applied. Therefore, I believe the BIOS caused the motherboard to suddenly apply the max vcore that can be supplied immediately after I saved settings and exitted BIOS. I am concerned that other people may be affected, and so I think it's important that Oskar Wu, or whoever is the head of the DFI BIOS development team to be notified of the possibility of the presence of a bug in this BIOS. Again I have to emphasize that I cannot be 100% positive that the BIOS is at fault, but logically it seems to be the case.

Therefore, I speculate that the motherboard itself may still be functional - however I will not know until my new CPUs arrive. But as you would understand, I'm feeling VERY apprehensive and worried about testing my new CPUs on a board that is potentially dangerous. I do not want any more CPUs to be possibly destroyed by the board, even though I have resetted the CMOS - I still cannot feel secure about this. And yet on the other hand, if I apply for RMA with the board and they say there is no problem with it, then it would have been a big waste of time, and also money.

What is your suggestion to be the best solution to my situation? And, typically, under such circumstances, would AMD's RMA system cover the death of my Venice 3000+ CPU if it was caused by the motherboard? I understand that overclocking is not covered by CPU manufacturers, but in such a case, the death is most likely (as I stated before, I cannot be 100% positive) not directly to do with overclocking, but motherboard/BIOS related. Indeed, as you said, this has caused a large inconvenience for me, not only because I have go to through this RMA process, but mainly because I have lost a truly special CPU.

Any constructive help would be greatly appreciated, thankyou very much for your consideration thus far.

Kindest Regards,
John.
__________________

Any help would be GREATLY appreciated guys!

Maybe here is the reason why...
http://www.dfi-street.com/forum/show...20&postcount=1

[alpha0ne]

Maybe here is the reason why...
http://www.dfi-street.com/forum/show...20&postcount=1

FARRRK me Oscar should have posted that HERE 2 days ago, not everyone relies on DFI street as the font of knowledge, MANY more do HERE

[EMC2]

Give Oskar a break... I seriously doubt he knew it two days ago... I'm sure he posted on "the street" as soon as he found it... and word got from "the street" to hear in a matter of hours (look in AMD section).

Oskar is by far the most responsive MB company engineer around and has busted his chops for the enthusiast community for quite a number of years. Sheesh....

/rant off

Peace

[THunDA]

Not to mention you always take a chance when flashing a beta bios.. Im sure Oscar will have it sorted out soon..

[bachus_anonym]

Yep... Beta, just like Alpha BIOS should be flashed ***ONLY*** if one has issues with previous, Official BIOS.
Unfortunately, this might mean that even though BIOS glitch might have killed your chip, you're probably out of luck. Unless, DFI will be certain that that was the reason for it's death, then it would not really kill them to get you a new chip... It would be pretty good PR to me... Showing how much they care for users "beta-testing" their BIOSes.

Anyway, just take it easy. Don't attack Oscar Wu for that... get in touch with them one more time and see if they can help you with possible replacement or sth...

[groovetek]

I haven't and have no intention of attacking him or even DFI at all - In fact I admire Oskar Wu for his honesty and willingness/commitment to solve the problem. I have, however, tried my best to warn other DFI nf4 users of the bug in the BIOS. I've been very rational with my emails and posts as you can see here on XS, and also on dfi-street, i4memory.
That said, I am confused how a BIOS could introduce such a fatal bug though, even if it is an alpha... I don't know how to code/program BIOS's, but assuming the code for VID doesn't change from 1 bios to another (since that's not where improvements are required/or being changed), it's surprising that this can occur...

I only used the 704 BIOS because every BIOS before that was giving me troubles with G.Skill GH BH UTT kit when using async memory divider settings. I had followed every guide, tried dozens of different settings, all with no proper stability. The 704 finally did it for me and I was very happy, but then unfortunately, this happened, when deciding to up my CPU speed (i need 1.56v (1.20 * 133%, tested in prevoius BIOS's) for 3.0ghz, it was set to 1.525v and no "Above VID %" setting prior to this)...

As for getting me a new chip - it would be good PR for DFI, but unfortunately it wouldn't happen with a large-scale manufacturer like DFI because they are already popular enough as it is... and where would they find me another week 17 chip that goes as hard as mine did, haha... I'd love to find another one that could though... sigh... not to mention as a uni student with no proper job atm, the cost of computer hardware really adds up. I had waited 3 months to build this system after selling my old parts because of exams and because I knew winchesters and AGP platform-related parts would lose value very soon after that, so sacrificed all this time so I could gather enough money for these parts, and then on the 3rd day of setting it up it dies on me, very very bad luck .

edit: if anything though - it seems at least here in Australia, AMD's RMA system is extremely stringent, and I may not be able to get a replacement under these circumstances... if that is the case, then it'd be good if i did get just any 3000+ replaced for me... although do undrestand that DFI is not obliged to do this, since it was an alpha BIOS...

[stealth17]

[on topic]

i did the vdimm mod the other day but located the pot down neat the chipset. this means i have the wires about 6inches long that goto pin 4 and 6. now that i think about it though, is that a bad idea? wouldnt i be introducing a lot of EMI and loss?

thanks

[/on topic]

[CaTalyst.X]

You can reduce some EMI by wrapping the GND wire around the Hot wire for as far as you can until you get to the solder points. You could glue the pot to the FET Heatsink thats right next to LM358 if you want to feel safer.

-CaT