Tick-Tock cadence. Ticks seems tougher.

[TuxDave]

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.

Also a fair point. I think you can argue the accuracy of anything to death (we haven't even started to include the organization of work and the efficiency of team members) and inevitably come to a point where everyone goes "well, I guess we don't have enough data to make a conclusion". I personally thought my error bound was lower than the "scope is correlated to the # of days between releases". But I guess you're free to disagree.

 

[krumme]

Without knowing crap about cpu production i would expect the new process nodes to take far longer as there must be a lot of serial work where you can not just speed up time even with more manpower or if you do to a certain degree its unproportionally expensive.

 

[Exophase]

Without knowing crap about cpu production i would expect the new process nodes to take far longer as there must be a lot of serial work where you can not just speed up time even with more manpower or if you do to a certain degree its unproportionally expensive.

I was going to say exactly the same thing.. throwing more money at a project is a lot like throwing more cores at a software problem. If it's managed well it can sometimes help a lot, but other times not so much and sometimes not at all.

 

[Idontcare]

This is standard project management triangle type stuff.

You can minimize only two of the three.

Want it quickly and on a shoestring budget? Be prepared to have the scope be cut way way back (including quality).

Want it quickly and with awesome features? Be prepared to spend a mint making it happen.

Want it with awesome features and without spending a lot on R&D? Be prepared for the product development time to be long and the market intersection date be pushed way out into the future.

Which goes to Tuxdave's point - we know the scope (the feature sets of the ticks and tocks products), and we think we know the timeline for their development (but do we really know when they were started just because we know when they were released?), but for sure we haven't a clue as to the development costs and resourcing levels (headcount, monetary, etc.).

And if you don't know all three, you can't really speak to the overall project difficulty or lack thereof without making a boatload of assumptions.

And given Tuxdave's unique position of insight on this very subject matter, any resistance he is providing to guide us away from the assertions stated in the OP ought to be well received and highly regarded.

 

[witeken]

And given Tuxdave's unique position of insight on this very subject matter, any resistance he is providing to guide us away from the assertions stated in the OP ought to be well received and highly regarded.

Sure, but shouldn't we also need to have the POV from an Intel process guy?

 

[TuxDave]

Without knowing crap about cpu production i would expect the new process nodes to take far longer as there must be a lot of serial work where you can not just speed up time even with more manpower or if you do to a certain degree its unproportionally expensive.

The tick-tock cadence was presented as a method to split up architectural schedule risk and process schedule risk. As a result, architectural design gets to spends significantly more time on tock projects and process design spend more time on enabling the tick projects (tick to tick timeline). What I was getting at is that there are parallel teams and so you can't do the math as if the projects were being worked on sequentially. I didn't mean to start going into a "who has a harder job, a process engineer or a architect?".

Lastly, yes I know what "too many chefs in the kitchen" mean and at some point, not speed up progress no matter how many engineers you throw at a problem. I guess you can say this is the "Ahmdahl's Law" in project management. And there's also the other side that I think many engineers are familiar with where you just don't have enough engineers because you're R&D budget limited. You simply need to reduce scope or increase schedule (or work overtime... which is the common solution).

 

[krumme]

The risk management if ofcource the reason and imo looking at history its damn successful.

Go eg back to the p4 days when core duo was introduced on 65nm. A stellar mobile product that even showed the weakness of the desktop x2 3800. Talk about getting the right product when its most needed.

 

[krumme]

One can add the benefit of operating with two teams is more obvious in a monopoly like situation. You enable some friendly competition inside that makes people stay alert.

Eg i always assumed the teams worked parallel and would never assume something about what team is better or what is the most hard job from the data presented here

 

[Hulk]

I want to clarify that I wasn't make some grand statement or theory with my OP. After a perfunctory analysis of the tick-tock cadence I only stated that it seems ticks might be tougher than tocks.

If one team was working on both ticks and tocks this would be a relatively easy conclusion. Thus far we have an average of 334.75 days/tock and 496.25 days/tick.

We also know that two separate teams are working in parallel on ticks and tocks. Furthermore we know that as stated by Intel prior to this year a tock was supposed to be released every two years and a tick "sometime" in between the tocks. And just this year Intel extended the tock cycle to "approximately every 2 to 3 years."

http://www.fool.com/investing/general/2015/02/21/did-intel-corporation-just-redefine-tick-tock.aspx

"In a form 10-K filing from early 2014, Intel (NASDAQ: INTC ) described its "tick-tock" product development methodology as follows:

As part of our R&D efforts, we plan to introduce a new Intel Core microarchitecture for desktops, notebooks (including Ultrabook devices and 2 in 1 systems), and Intel Xeon processors approximately every two years and ramp the next generation of silicon process technology in the intervening years.
Intel just filed its form 10-K for the most recently ended fiscal year. Notice what the company had to say about its tick-tock methodology now:

As part of our R&D efforts, we plan to introduce a new Intel Core microarchitecture for desktops, notebooks (including Ultrabook devices and 2 in 1 systems), and Intel Xeon processors approximately every two to three years and ramp... the next generation of silicon process technology in the intervening periods. [Emphasis added.]"


This information would seem to imply that while "tougher" or "harder" might not be the perfect words to describe the difference between ticks and tocks, Intel's statements do seem to imply that tocks are more predictable, which I take to mean they have more control over them.

Could it be that ticks have more of a "hard-unmovable" goalpost while tock goalposts are somewhat "softer" and "moveable?" What I mean by that is AFAIK there is a certain yield that must be hit for ticks for economic viability and there doesn't seem to be much flexibility there. On the other hand while there are obviously design goals for tocks they can back off performance goals a bit if it appears time is running short.

 

[pantsaregood]

Don't forget Prescott, it was pretty much the tock before Cedar Mill's tick.

Prescott was kind of a combined tick/tock - new process and radically changed core from Willamette/Northwood. Really, Prescott started Intel's release cadence.

 

[Hulk]

Don't forget Prescott, it was pretty much the tock before Cedar Mill's tick.

Prescott was kind of a combined tick/tock - new process and radically changed core from Willamette/Northwood. Really, Prescott started Intel's release cadence.

Around that time at Intel I imagine everybody kind of running around like chickens without heads absolutely freaking out about how the Athlon was wiping up the floor with Intel processors. Somebody at the top must have reorganized them and that person deserves quite a bit of credit.

 

[jpiniero]

Around that time at Intel I imagine everybody kind of running around like chickens without heads absolutely freaking out about how the Athlon was wiping up the floor with Intel processors. Somebody at the top must have reorganized them and that person deserves quite a bit of credit.

You mean the person who came up with the idea to bribe Dell not to use AMD.

 

[Hulk]

You mean the person who came up with the idea to bribe Dell not to use AMD.

No bribes necessary once Conroe appeared

I'm talking about the person that got the ship headed toward Conroe.

 

[tenks]

It's not like Conroe was made over night. You make it seem like athlon64 came out, kicked intel's butts, and then they reacted and made conroe 260 days later. Conroe was already long in development, like all uARCHs, and it definitely took more than 260 days.

 

[Hulk]

It's not like Conroe was made over night. You make it seem like athlon64 came out, kicked intel's butts, and then they reacted and made conroe 260 days later. Conroe was already long in development, like all uARCHs, and it definitely took more than 260 days.

No, I'm making it seem like the fact that the Athlon was beating the P4 in performance created a fire under Intel to get Conroe out the door quickly. The days I quoted are the best available information we have for the sake of comparison. If you have better data please present it.

 

[tenks]

No, I'm making it seem like the fact that the Athlon was beating the P4 in performance created a fire under Intel to get Conroe out the door quickly. The days I quoted are the best available information we have for the sake of comparison. If you have better data please present it.

No need to get defensive man, just pointing out Conroe didn't take 230 days to make.

 

[krumme]

No, I'm making it seem like the fact that the Athlon was beating the P4 in performance created a fire under Intel to get Conroe out the door quickly. The days I quoted are the best available information we have for the sake of comparison. If you have better data please present it.

Intel was under fire in 1999 when k7 rumours arived. Heck even the motherboard manufacturers didnt want their name on the mb!
K7 was like a pentium pro vs a pentium. It had a freaking strong fpu and was a perfect server arch. Otellini wrestling and paying started back then. Even with such an enormous perf and perf w advantage amd didnt get the entire server market. They just didnt have the muscle.

 

[Hulk]

No need to get defensive man, just pointing out Conroe didn't take 230 days to make.

Sorry. I can get "prickly" too quickly

And yes, who knows how long the total Conroe development from soup to nuts took. But you have to admit, for years they're rolling along with the various P4 incarnations and then less than 8 months after the last P4 is released a totally new architecture hits the streets. It was a shocker. I remember being like "holy $hit!, where'd they pull this from?" It was a crazy about face from the company that had been shoving clockspeed down our throats for 20+ years.