Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)

Page 664 - Seeking answers? Join the AnandTech community: where nearly half-a-million members share solutions and discuss the latest tech.

Josh128

Golden Member
Oct 14, 2022
1,318
1,983
106
Arrow Lake Leak got somebody excited enough to tune up a 9950X on Geekbench. Multiple different runs of 5950 MHz all core OC today, probably DI or LN2 :astonished::astonished::hearteyes:



5950X OC.jpg
 
Last edited:

Hitman928

Diamond Member
Apr 15, 2012
6,695
12,370
136
It doesnt mater if it s too early as long as the clocks rising and falling edges are fast enough, once triggered the flip flop will keep its state for at least the duration of a clock cycle.



Same as above, if the signal is propagated swiftly this will allow for better level validation, what is a problem actually is when clocks signal hedges are not fast enough, at wich point levels coherency can no more be maintained since the flip flops cant be switched on/off correctly if the clocks signals are not well formed, no matter what are the data signals levels and shapes.


I never use such sentences, i mean such arguments or rather lack of, you know, things like "it s well known that", "it s shown in real world tests" and so on.

You may not like that real world tests prove your theory wrong, but that is the ultimate evidence. You can theorize all you want, but if the real life tests show something very different or even the opposite, then your theory is clearly wrong. The proof is in the pudding.

Hold time violations are also called minimum delay violations because the signal is propagating too fast, so saying it doesn't matter if it is too early is, again, wrong. These type of timing violations are frequency independent. A quick google search will show this is true. I've never met someone who is so confidently wrong over and over again. If you want to prove me, and every digital designer out there, wrong, show some proof of what you say is true in working designs. Outside of that, best of luck to you, I won't be wasting any more time on this.
 

Fjodor2001

Diamond Member
Feb 6, 2010
4,207
580
126
So who wants to be guinea pig and buy a CPU from the first batch now, unless AMD discloses what the actual problem was and how well it could be fixed?
 
  • Haha
Reactions: igor_kavinski

Abwx

Lifer
Apr 2, 2011
11,884
4,873
136
You may not like that real world tests prove your theory wrong, but that is the ultimate evidence. You can theorize all you want, but if the real life tests show something very different or even the opposite, then your theory is clearly wrong. The proof is in the pudding.

Hold time violations are also called minimum delay violations because the signal is propagating too fast,

The pudding interior say that time violation occur mainly when the data signal is too late.

It can occur if the signal comes too early but in this case it s only if the clock is too high and as a consequence that there s not enough time for the stage to be triggered during the relevant clock cycle as to hold the desired value.

So assuming that frequency is low enough at the start there will be no time violation by other mean than the transistors not switching fast enough, that is, too low transconductance to charge parasistic capacitances in due time, i.e, signal being too late as a result.
 

branch_suggestion

Senior member
Aug 4, 2023
823
1,784
106
Gives AMD enough time to launch a new AGESA for reviews.
N3B being a complete mess has really led to lots of chaos, thankfully Zen 6 development is going nicely.
But for this gen rollout, things are rough, same with GPUs for all players.
 

Hitman928

Diamond Member
Apr 15, 2012
6,695
12,370
136
The pudding interior say that time violation occur mainly when the data signal is too late.

It can occur if the signal comes too early but in this case it s only if the clock is too high and as a consequence that there s not enough time for the stage to be triggered during the relevant clock cycle as to hold the desired value.

So assuming that frequency is low enough at the start there will be no time violation by other mean than the transistors not switching fast enough, that is, too low transconductance to charge parasistic capacitances in due time, i.e, signal being too late as a result.

Prove it, otherwise. . .

Hold violation happen when data is too fast compared to the clock speed. For fixing the hold violation, delay should be increased in the data path.

*Note:* Hold violations is critical and on priority basis in comparison are not fixed before the chip is made, more there is nothing that can be done post fabrication to fix hold problems unlike setup violation where the clock speed can be reduced. The designer needs to simply add more delay to the data path.

 

Abwx

Lifer
Apr 2, 2011
11,884
4,873
136
Prove it, otherwise. . .




You re just repeating what i said, so how should i prove it otherwise, didnt i say that if clocks are low enough there will be no time violation..??

It can occur if the signal comes too early but in this case it s only if the clock is too high and as a consequence that there s not enough time for the stage to be triggered during the relevant clock cycle as to hold the desired value.

So assuming that frequency is low enough at the start there will be no time violation by other mean than the transistors not switching fast enough, that is, too low transconductance to charge parasistic capacitances in due time, i.e, signal being too late as a result.


So read first what is said, since you re now trying to make a point out of something you once negated a few post above, your quote is saying exactly what i stated in my post that i just quoted above.

Anyway, at least i got a good pile of lols for free.
 

Hitman928

Diamond Member
Apr 15, 2012
6,695
12,370
136
You re just repeating what i said, so how should i prove it otherwise, didnt i say that if clocks are low enough there will be no time violation..??




So read first what is said, since you re now trying to make a point out of something you once negated a few post above, your quote is saying exactly what i stated in my post that i just quoted above.

Anyway, at least i got a good pile of lols for free.

Read it again, it agrees with me.
 

Abwx

Lifer
Apr 2, 2011
11,884
4,873
136
Read it again, it agrees with me.
Here the quote you posted :

Hold violation happen when data is too fast compared to the clock speed. For fixing the hold violation, delay should be increased in the data path.

And here what i said before you posted this quote :
The pudding interior say that time violation occur mainly when the data signal is too late.

It can occur if the signal comes too early but in this case it s only if the clock is too high and as a consequence that there s not enough time for the stage to be triggered during the relevant clock cycle as to hold the desired value

So what you quoted is just the same thing as what i said, and the contrary to what you said in your first posts on the subject.

Edit : The data signal state will last as long as the clock signal doesnt change state, if the clock signal is of low enough frequency the data signal will have all necessary time to trigger the driven stage.
 
Last edited:

Hitman928

Diamond Member
Apr 15, 2012
6,695
12,370
136
Here the quote you posted :



And here what i said before you posted this quote :


So what you quoted is just the same thing as what i said, and the contrary to what you said in your first posts on the subject.

Edit : The data signal state will last as long as the clock signal doesnt change state, if the clock signal is of low enough frequency the data signal will have all necessary time to trigger the driven stage.

Nope, try again. As the quote says, you cannot fix a hold violation post fabrication. Clocks, making them faster or slower, have nothing to do with it.
 

mostwanted002

Member
Jun 16, 2023
63
127
86
mostwanted002.page
Arrow Lake Leak got somebody excited enough to tune up a 9950X on Geekbench. Multiple different runs of 5950 MHz all core OC today, probably DI or LN2 :astonished::astonished::hearteyes:



View attachment 103765
Is it a geekbench issue that it says "Memory Channels : 4"?

1721876604354.png
 

Markfw

Moderator Emeritus, Elite Member
May 16, 2002
27,235
16,106
136
So who wants to be guinea pig and buy a CPU from the first batch now, unless AMD discloses what the actual problem was and how well it could be fixed?
Me. Its not a problem. READ. Its a QA issue. In other words, allowing a 9950x to be sold at under the advertised MHZ or the like.

Worse case, allowing a 9950x to be sold that does not meet QA and at top frequency, is not stable. Sound familiar ?
 

Fjodor2001

Diamond Member
Feb 6, 2010
4,207
580
126
Me. Its not a problem. READ. Its a QA issue. In other words, allowing a 9950x to be sold at under the advertised MHZ or the like.

Worse case, allowing a 9950x to be sold that does not meet QA and at top frequency, is not stable. Sound familiar ?
Reading the other posts in this thread, it does not seem to be clear what exactly the reason for the delay is. QA could mean lots of things. How come you think it’s likely a frequency only issue?
 
Last edited:

Doug S

Diamond Member
Feb 8, 2020
3,570
6,305
136
Edit: If it was an actual issue with the chips, there's no chance they would be able to get them fixed and new ones out the door within a week or two. It would have to be either the QA testing miss as explained, or something wrong with the microcode/firmware that they could fix and push out quickly.

They could easily fix a hardware issue within a week or two. Just look at Intel, they didn't need a respin they're able to solve it with a firmware update (at least to the extent of preventing future degradation, they can't undo potential past degradation)

AMD could have looked at Intel's troubles, done some internal reviews "are we vulnerable to the same sorts of problems", found they were, and are making changes to insure voltage levels are kept within bounds to prevent similar issues. By recalling before release they avoid the risk of having chips out there that are operating "unfixed" for months/years by the sort of people who never update their firmware.

Now I have no idea what AMD's problem really is, but the timing of this given Intel's announcement seems a little suspicious to me. A couple week delay to cut the possibility of such issues off at the pass would be well worth it, if it means being able to sit back with a smug grin on your face while Intel deals with the fallout for their problems for the next year or two.
 
Jul 27, 2020
27,958
19,106
146
These companies are packed with talented and highly professional people, yet things go wrong from time to time. This (Zen 4/RPC) gen should be very indicative of that.
These talented and highly professional people don't get it in their heads to do crazy or stupid things on the CPUs. That's how they got their job in the first place. Usually someone wanting to monkey about with things isn't tolerated at most workplaces around the world.
 
Jul 27, 2020
27,958
19,106
146
It’s good that AMD found this issue before launch. But as I finding this issue this close to launch is a bit concerning. AMD should have done tested all scenarios and not skipped on some.
Maybe some smartass in the art department drew a really tiny doodle on the Zen 5 IHS and one or some of the reviewers discovered it while examining the IHS with magnification. And it's probably NSFW.