Tick-Tock cadence. Ticks seems tougher.

[Hulk]

From what I gather since Conroe the average number of days between ticks (process shrinks) is 496 while the average number of days between tocks is 369.

The average tick-tock time has been 2.42 years per cycle starting with the introduction of Conroe. That is 3-1/2 cycles. The introduction of Skylake will be 4 full cycles of the tick-tock strategy.

Including Pentium 4 (Cedar Mill) at 65nm introduced 11/27/2006 (official Anandtech review date) then that would be 4 full cycles with 2.28 years per cycle. And an amazingly quick 231 days from Cedar Mill's introduction to Conroe. Intel was under the gun and showed us how fast they could get out a new architecture if their life depended on it!

It would seem ticks are more problematic for Intel. I guess it's easier to layout a new architecture than work out the kinks in a new process tech right?

It's hard to figure an exact release date for a part but for all but Broadwell I'm using the official date of the Anandtech review, which generally coincides with widespread availability. For Broadwell I'm using 1/1/2014 since that is about when system started shipping in decent volume.

According to my data the easiest tick was 427 days to Westmere, then 476 days to Ivy Bridge, followed by 503 days to Penryn and finally 579 days to Broadwell.

So here's what we have. Release date, days since last release

11/25/2005 - Pentium 4 (Cedar Mill)

7/14/06 - 231 days - Tock to Conroe
11/29/07 - 503 days - 45nm tick to Penryn
(734 days for the Conroe/Penryn cycle)
(46.1% IPC increase from P4, 93.2% overall performance increase)

11/3/08 - 340 days - Tock to Nehalem
1/4/10 - 427 days - 32nm tick to Westmere
(767 days for the Nehalem/Westmere cycle)
(24.9% IPC increase from Conroe tock, 75.3% overall performance increase)


1/3/11 - 364 days - Tock to Sandy Bridge
4/23/12 - 476 days - 22nm tick to Ivy Bridge
(840 days for the "Bridge" cycle)
(9.5% IPC increase from Nehalem tock, 57.1% overall performance increase)

6/1/13 - 404 days - Tock to Haswell
1/1/15 - 579 days - 14nm tick to Broadwell
(983 days for the "well" cycle)
(18% IPC increase from "Bridge" tock, 18.2% overall performance increase)

8/15/2015 (projected) - Tock to Skylake

Including the P4 tick and projected Skylake tock that would be 4.5 cycles in 3550 days. For an average of 789 days or 2.16 years per cycle.

But if you look at the trend above the "tock-tick" cycle has been increasing. 734, 767, 840, 983...

Update. So I went through and refined the IPC results I did on Anand's Haswell review from a few years ago and added IPC (MHz normalized) and overall increases in performance for each tock generation. Core2Duo and P4 (dual core) scores were increased by a factor of two to equalize to the quads. Of course this gives those cores the advantage of perfect scaling. P4 also gained some ground due to special Photoshop extensions. And I did NOT include AES TrueCrypt scores for Nehalem to Sandy Bridge in the IPC scoring because those scores were off the charts. I took great care in working the data. For example in the "going back" part of Anand's review I arrive at 18.1% increase in IPC from Sandy to Haswell and 18.0% with the "going further back" data. I then averaged both results.

I realize the Nehalem to Sandy IPC increase seems low. I double and triple checked it. That's what Anand's test results show. The overall performance increase is significant because there was a sizeable frequency increase from Nehalem to Sandy Bridge. Also the IPC and overall performance increase from Sandy to Haswell is about the same because frequency remained nearly constant.

The results are presented purely for your viewing pleasure. They are simply pulled from the testing Anand did with Haswell a few years ago and I thought they would be interesting to view along with the tick-tock cadence. I was sick earlier this week and had some extra laying around time

 

[TuxDave]

Heh, interesting data and conclusion. However if you label the primary design team for each project and apply the knowledge that design teams are constantly working, does that change your conclusion?

 

[coercitiv]

Funny thing also happens when you add ticks+tocks

Start at Conroe
843 days for Nehalem
791 days for Sandy
880 days for Haswell
~850-880 days Skylake (guesstimate)

It almost seems like 22nm and Haswell were just as hard as 14nm and Skylake

 

[witeken]

You should include the preliminary release date for the next Tock: Skylake at IDF SF on August 15.

 

[witeken]

Heh, interesting data and conclusion. However if you label the primary design team for each project and apply the knowledge that design teams are constantly working, does that change your conclusion?

Want do you mean with that? Does it change your conclusion?

 

[witeken]

It almost seems like 22nm and Haswell were just as hard as 14nm and Skylake

IB and HSW delays had nothing to do with 22nm or architecture problems (it were market reasons).

Just imagine that the delta between HSW and BDW if those 2 products weren't delayed .

Edit: On-topic: Of course Ticks are harder. Just designing a new node isn't enough. With Tocks you also have to do extensive testing I guess, but getting the yields from 0 to 90% is very hard.

 

[TuxDave]

Want do you mean with that? Does it change your conclusion?

No it doesn't, but only because I disagree with the OP.

 

[witeken]

No it doesn't, but only because I disagree with the OP.

Then what is your opinion?

 

[TuxDave]

Then what is your opinion?

My opinion is that if you do what I said, it would imply that tocks have more design schedule allocated to it.

 

[witeken]

My opinion is that if you do what I said, it would imply that tocks have more design schedule allocated to it.

I don't really think I understand what you're saying, but in any case I think Ticks are tougher and that you might be a little bit biased .

 

[Hulk]

Heh, interesting data and conclusion. However if you label the primary design team for each project and apply the knowledge that design teams are constantly working, does that change your conclusion?

That is a good point. The teams are overlapping. There are too many variables go down that rabbit hole. I think the point the data presents is the fact that the cycles are getting longer. And of course there could be lots of reasons...

 

[poofyhairguy]

But if you look at the trend above the "tock-tick" cycle has been increasing. 734, 767, 840, 983...

Well yeah, x86 is losing some of its economy of scale.

 

[krumme]

Thanx OP. Great work and interesting data.

 

[Fjodor2001]

My opinion is that if you do what I said, it would imply that tocks have more design schedule allocated to it.

"if you do what I said" - well what have you said? Also - "more design schedule allocated to it"?

Why talk in riddles...

 

[TuxDave]

"if you do what I said" - well what have you said? Also - "more design schedule allocated to it"?

Why talk in riddles...

Not sure why I'm getting such hostile response:

Heh, interesting data and conclusion. However if you label the primary design team for each project and apply the knowledge that design teams are constantly working, does that change your conclusion?

 

[Fjodor2001]

Not sure why I'm getting such hostile response:

I'm not trying to be hostile. I'm just not sure what you're trying to say. So I think it would help if you tried to clarify it and elaborated a bit further?

 

[TuxDave]

I'm not trying to be hostile. I'm just not sure what you're trying to say. So I think it would help if you tried to clarify it and elaborated a bit further?

In a simplified way of saying it:
If the same set of people were doing all the projects (one team) and they had to serialize their work (aka they cannot start on the next project until the current one is done), then Hulk's analysis seems pretty sound.

However, if you have multiple teams working on a different projects, you are miscounting during the time when both teams are working at the same time on different projects.

 

[ehume]

In a simplified way of saying it:
If the same set of people were doing all the projects (one team) and they had to serialize their work (aka they cannot start on the next project until the current one is done), then Hulk's analysis seems pretty sound.

However, if you have multiple teams working on a different projects, you are miscounting during the time when both teams are working at the same time on different projects.

Is that the way it is? I thought the team working on the ticks -- the nodes -- was always one team. The team working on the tocks -- the architecture -- was the other. One team based in Washington, one in Israel. They work serially, if what I understood was the way Intel runs.

You are suggesting that there are more than two teams, and they work in parallel. Am I understanding this correctly?

 

[witeken]

However, if you have multiple teams working on a different projects, you are miscounting during the time when both teams are working at the same time on different projects.

And why wouldn't that be equally true for process nodes? And how about the size of each team.

Also: R&D budget or team size or time spent on project != difficulty. Maybe making processors meaningfully faster is tougher than designing a new node, but that's another issue.

Intel will be able to release a new Tock every 2 years 3 decades from now just as easy as they're capable of doing that now.

 

[witeken]

Is that the way it is? I thought the team working on the ticks -- the nodes -- was always one team. The team working on the tocks -- the architecture -- was the other. One team based in Washington, one in Israel. They work serially, if what I understood was the way Intel runs.

You are suggesting that there are more than two teams, and they work in parallel. Am I understanding this correctly?

At any given time, you can be sure that 2 teams are working on future Tocks since creating an updated architecture costs 4 years or so. Also, I guess it's commonly understood that the 2 Intel teams are in friendly competition with each other.
I don't really know about how things work with Ticks, but they have a healthy pipeline:

(Since right now 10nm is in development, that means 3nm is in its initial stages of research.)

 

[TuxDave]

...
Also: R&D budget or team size or time spent on project != difficulty.
...

If we're going to go down this route of trying to quantify difficulty without using RD budget, team size or time spent, I'm out.

 

[Fjodor2001]

If we're going to go down this route of trying to quantify difficulty without using RD budget, team size or time spent, I'm out.

So you're saying that if projects working on Ticks had a bigger R&D budget, then those projects would not take longer than the Tock projects?

I.e. the difference in number of days it takes to finish a Tick vs Tock project is just a matter of how much funding each project gets?

If so, how come Intel doesn't try to adjust the R&D budgets so that the development time for Ticks and Tocks are evened out?

And if the Ticks currently always lag behind, it sounds like the Tock projects would sit idle part of the time waiting for Ticks projects to complete.

 

[witeken]

If we're going to go down this route of trying to quantify difficulty without using RD budget, team size or time spent, I'm out.

If we're not going to use rational arguments anymore, I'm out.

 

[TuxDave]

So you're saying that if projects working on Ticks had a bigger R&D budget, then those projects would not take longer than the Tock projects?

I.e. the difference in number of days it takes to finish a Tick vs Tock project is just a matter of how much funding each project gets?

If so, how come Intel doesn't try to adjust the R&D budgets so that the development time for Ticks and Tocks are evened out?

And if the Ticks currently always lag behind, it sounds like the Tock projects would sit idle part of the time waiting for Ticks projects to complete.

Ok, fair point. Here's my way of seeing things.
# of days to complete a project ~ scope (aka difficulty) / size of team
RD budget ~ size of team * # of days to complete a project

Therefore, scope (aka difficulty) is strongly related to the RD budget or the product of the team size & project schedule. How about that?

If you make team size a constant, then difficulty is proportional to RD budget or the project schedule.

As for your second part

And if the Ticks currently always lag behind, it sounds like the Tock projects would sit idle part of the time waiting for Ticks projects to complete.

Rule #1 of management (based on my opinion) is that engineers are not allowed to sit around and do nothing. So projects, schedules and assignments will be set so that they're always working. So if the work model you think another company has leads you to conclude that engineers are sitting there doing nothing for long periods of time, you can safely conclude that you have the wrong work model.

P.S. If there is a job out there where I can do nothing for long periods of time and get paid well, send me a PM.

 

[Enigmoid]

Ok, fair point. Here's my way of seeing things.
# of days to complete a project ~ scope (aka difficulty) / size of team
RD budget ~ size of team * # of days to complete a project

Therefore, scope (aka difficulty) is strongly related to the RD budget or the product of the team size & project schedule. How about that?

If you make team size a constant, then difficulty is proportional to RD budget or the project schedule.

As for your second part

Rule #1 of management (based on my opinion) is that engineers are not allowed to sit around and do nothing. So projects, schedules and assignments will be set so that they're always working. So if the work model you think another company has leads you to conclude that engineers are sitting there doing nothing for long periods of time, you can safely conclude that you have the wrong work model.

P.S. If there is a job out there where I can do nothing for long periods of time and get paid well, send me a PM.

I think you are oversimplifying. Once you hit a certain size group (total numbers of teams of engineers) it becomes one or two individual sections holding the project back. For instance, one step in the wafer process could conceivable set back mass production for more than a month (say something is going well and expected to be going well and then all of a sudden unforeseen delays happen). Its hard to move people onto the project because they don't know the specifics (they can do the more basic tasks but ultimately don't know the intricacies of that specific step).

You are right in that the engineers don't sit idle. They get reassigned to something else in the meantime but in essence that one team holds back everything.

This can greatly throw off your formula above. While you may have the loose correlation there is a huge amount of error in that kind of a relationship.