So, where do requirements come from? Customers? Yeah. First and foremost, they're the ones that buy your products and pay your salary, so you got to keep the customers happy for sure. Internal sources, it could be sales, marketing, many companies run competitive analysis, both when I worked at Seagate and Micron, we have competitive analysis, groups, they go out and buy competitors' products, and expose them to all kinds of testing, and extract information and characteristics about the product. You can learn a lot about what sells in the market by looking at your competitors products. Management, they are going to have ideas. Engineering, lessons learned from the previous projects. I guarantee you, when you go out in the working World and you start building a product, and you ship it, you're going to learn a ton, then when you move on to your next product, there's key learnings things. Others all these key learnings that take place, and you have all these moments like, "All right. Well, in the next project, we're not going to do that and we're not going to do this, but we are going to do this and we failed here in this place, and that was a big issue for our customers, we're going to fix that." So, we bring all these lessons learned forward into the next project. Sometimes engineers just go, they wake up, happens to me, usually at night when I'm sleeping, and I dream about work. I know it's weird, but I can't help it, my brain just like crank on stuff, and I get up in the middle of the night, and have to write it down on a piece of paper. I will come in first thing in the morning and I'll call up another engineer and say, "Hey. I had this idea last night and let me talk about it, and see if it makes sense to integrate into the project." We're going to look at this next section is broken down and staffing, organization roles, and responsibilities and the process or a process. Also we'll look at staffing first. It is in a company's best interests to staff a project appropriately, and the question that immediately becomes well, what is appropriately? It turns out the answer is, it depends. It's not all projects represent an equivalent amount of complexity, equivalent duration the time it takes to complete it from start to finish, and resources, people, gauging project complexity. Most management that I've been involved with look at any particular given product project as the sum of three vectors and metrics, and those metrics are Scope, Schedule and Resources. So scope. It's a measure of the design space, a measure of the complexity. How many microprocessors are there in this? How much code do we have to write? How many interfaces do we have? How many features do in functions do, does this product implement? Yeah, it's a feature feet think and think about it as the number of features for instance. Sometimes I think about it that way. This is a big design scope versus a small designs scope versus a medium designs scope. So, what does a feature list? How many features, how much of the previous design can be leveraged because when you're, after you've got your first product out there's a strong tendency to pull as much of that design work that was done before both the hardware and the software of it forward, and leverage it because it shortens your design time. The more stuff that you can leverage the more things you can leverage from your previous product, into your future product, saves you time on the next product. This question gets asked all the time, how much can we be leveraged from the previous product? How much new design work must be completed? Because inevitably, when you move from one product generation to the next, there's these new requirements so new design work needs to get done. We have to understand how much new design work is involved in that second project. When does a project need to be completed? According to management, sales and marketing, guarding your customers, when do customers want test units? Some companies call them qualification units. When do customers want the product and volume? Usually during a product development, you'll get to a point where you have a product that you feel is stable enough and you give it to your customers and then they'll go off and start to experiment with it, and put it into their systems and test it, and immediately you'll start to get feedback and you find out well what doesn't work. But that's good, because if you're not at your final product release yet but and then there's this iterative process that happens with the customer, and your company maybe there's firmware updates and bugs that need to be pushed to the customer, and so they call this the qualification cycle before you get to the volume production. There is the,the customers definitely have an idea of a when they want, when they want the product and when they wanted it in volume. These ones don't always line up with each other. Management and customers have a different perspective on when the product needs to be available. Resources, staffing. How many engineers are available? Can we use the people we already have? Is hiring required. May be able to use everyone, once everyone finishes on the current product it's possible to take all of those engineers, and move them to the next project. Projects have a tendency to over lap in time kind of like this you can think of a hump and you'll see this, I got a chart coming up in a minute. But they overlap like this so there is a rise of people, and at the beginning of a project, and then the ramps down to just a handful of engineers support folks taking care of the products that are shipping out in distribution, and then that overlaps with the ramp-up of the next project. So, what does a heap chart look like? So lets us shape thing. So, here's an example of a heap chart. Who's heard of a heap chart before? Anyone? Okay. New term. So, this is the person count here on the left, start of the project, end of the project. You can see the number of design engineers starts out, low, kind of ramps up in the middle of the project, and it reaches a plateau, and so careful of this. Working on complex projects as like I use this analogy, if you got a big boulder and you're pushing it up the hill you get one person to try to push that rock up the hill, and he can't do it and you bring some more resources in, and I get four or five that can get their hands on that rock. Let's say the rocks are big enough where you could get eight people's hands on it to push it up the hill. The rock is moving up the hill fast enough. So, hiring more people. Doesn't help you because there's no room for them to push on the rock. So, you reach this law of limiting returns on headcount. Hiring more people can't accelerate the process any faster because of that pushing-the-rock-up-the-hill effect. There's only so much surface that these engineers can push on. So, it's not uncommon for this to flatten out. I showed all three of these flattening, having a period of flatness because you're just adding more headcount doesn't get you to that. This end ain't any faster. So, be wary of that. This shows design engineers, shows verification engineers. You'll notice that there's a lot more verification engineers in the middle here than there are design engineers. If this ratio is backward, something's wrong and I've worked at places that it's like that. Lots and lots of design engineers and not nearly enough verification engineers and then bugs aren't found and you have to spend a chip or you have to reprogram your FPGA. I can't emphasize enough. Verification is where it's at. Many hardware engineers get their bachelor's or master's degree and they have a background in hardware design, but they go into verification. I can tell you verification, it pays very well and you get hired right away because companies are scrambling for good verification engineers. So, even though they have experience in hardware design, they have experience writing software, they end up going into verification because they are in high demand. When I was at Seagate, we had to go outside the state to find verification engineers because there just wasn't anybody in the state of Colorado. Then, there's always the mechanical and the physical engineers here that you probably have one at the beginning here, and then you'll get up to two or three working on the packaging and the plastic case for your product or whatever it is. There's screws and a chassis and all this stuff. There's thermal analysis that needs to be done. Lots and lots of mechanical things. So, you'll have some number of mechanical and physical engineers and then eventually, that will ramp down at the end of the project. The area under the curve represents one of the costs of doing business. That's OpEx or Operational Expenditure. Management is highly motivated. Most places I've worked, this is a generally true statement, are highly motivated to minimize this expense. They want to minimize the area under the curve. The way I think about it as an integral. Organization. So now, we got a whole bunch of people. How do we put them together to be effective? How does this work? I cannibalized some if my training and slide material from my working world, changed it a little bit, took the confidential stuff out. This would be for a safer designing and a second application-specific integrated circuit versus an FPGA. FPGA might be similar to this but the numbers would move around a little bit. So I think, you're going to build a custom chip here. At the top, up here, there needs to be a manager and a hardware architect and a software architect. Then these numbers in parentheses are the headcount. Under the software side, you need a senior person to be the software lead, and then underneath the software lead, you'll have a number of senior design engineers and a number of junior design engineers and some number of test engineers. So, in my hypothetical example here, I've got 20 software engineers on this project. It's important to have these software people involved early on in the beginning of the hardware, so that there aren't disconnects between what firmware or software is expecting and how the hardware behaves and I've seen a chip get designed and sit on the shelf for a year before software even came around and had their very first look at the chip. So, that was completely disconnected and then that got fixed and it was kind of stunning to see that happen. Then you get a lead hardware person and a number of senior and junior hardware design engineers. You get one test engineer here. That might be two, [inaudible] hard fixed fast numbers. On the verification side, you get a verification lead and you've got maybe 10 senior verification engineers and 20 junior verification engineers for a total of 31 in the verification category. Then you've got your mechanical and physical lead. You want someone that's been around them and doing mechanical design for a long time. Go find that person that they know a lot and know how to design printed circuit boards and do signal integrity analysis and they know all of these. They've been through the wringer a lot. So, you want to go find that person, you want them on your team, and then a senior and a junior mechanical and physical engineer. In my example, we've got four here. So, just note the ratio of hardware engineers, I got 11. I got 20 software engineers and I've got 30 verification engineers and a handful of mechanical. This is a good distribution. This works. The systems are so complicated today that this spending time in verification for an ASIC is crucial. If a bug gets through, then you need to figure out how to fix it and you have to spend the chip. So the mask sets for a chip can be 5, 10, 15, $20 million, and that's for the full set of masks. If the bug that got through is so bad that you have to change a base wafer all the way up and then you need a whole brand new mask sets, so you're pulling the lever on another $10 million and that gets the attention of management very, very quickly. Hey, what's going on there? You just spent another $10 million. Well, we had a verification escape. Well, how come? Well, we only had three verification engineers. What? Yeah, don't do that. These aren't, again, hard and fast numbers but it just gives you an idea of the relative importance of verification, software to hardware. Often what happens is sometimes as a verification effort is ramping down, some of these verification engineers will come over and write software or firmware, for instance. That's something that can happen. Figure out how to organize yourself somewhere along these lines. Use this as a template with modifications appropriate for your situation. Now, when you first get a job, you'll come in and they'll be this organization. But over time, you can bring up ideas and make suggestions and be a force for a positive change in your organization, and work towards achieving some structure similar to this.
