Develop, this is always the fun part for me. This is where you get to write code and run simulations, and write software, and start testing out your stuff and actually doing the building. And we, as engineers, we want to build stuff, we want to go out into the world and create, we want to make the world a better place. So, this was always my favorite part. So, software development can start here, electronics development can start here, all the physical work that needs to get done, whatever that means for your particular project, this is where you actually start to do the design work, and this is where money starts to get spent also in potentially large amounts. Specifically, or especially, in cases where you're securing contracts with assembly houses, board manufacturing houses, you're signing contracts and commitments for so many units, and you have to pay them. So, cash is starting to flow out of your company. Jumping in at this point, and we just finished our last project. It's good that we know what we have to do for the next one, okay. We got to add features A, B, and C, and we all are just biting it a bit to get going, and we're just going to jump in and we're going to start writing the code and doing our development right here. This is the last century, this is the 19th century, development process mindset, call it what you will, old-school, you don't wan t to do that, this is a catastrophic mistake in development. To jump in at this point and just start writing code. You didn't raise your hand few minutes ago. It seems counter intuitive of you, I challenge you to go off and think about it for a while. I can share with you, it was 30 years of product development jumping in here, we'll move your end date out in time. Whatever that date you think you can hit by jumping in right here ,not going to hit. Schedule slips were very very typical with this approach, because if you jump in here, you do not understand the full scope of your project yet. By going through the steps in blue, the architecture and the design planning phase, taking all that time to do the design, write all those documents, write it all down, have all these reviews. You know exactly what the scope is, and therefore you can calculate a very very accurate schedule. You just jump in here, and you have no idea, and you start going along you're coding "I got basic functionality working" and then well, what about this? "I didn't realize I had to do that" and then you start thinking back, it's almost like going backwards, jump back to, "what are the requirements?" I don't know, aren't they exactly the same as the previous product? That's almost never the case. No, there's been requirements."I didn't know that". Well that changes my design, I got to go in and change my code. Then you just get into this big thrashing cycle where you keep rewriting your code and rewriting your code, and meanwhile, the exit is date here, keeps sliding to the right. Then management starts to have meetings, "So how comes you guys aren't on schedule?" Say, "well we didn't really understand the full scope of the project because we just started and we just jumped in" And you get scolded by the Vice Presidents with, "Well, next time you do the product development, you need to do planning up front so you now understand the full scope of your project." Okay, okay we'll do it, we'll do it next time. Then the VP leaves and you don't do it the next time, and then the same thing happens. It's bad for your company because you're missing commitment dates to your customers. Eventually, your customers might go away because you promised some products in August of some year and you don't ship them their product until April. They're not going to be happy with that. So, understanding the scope, that's why all this stuff that happens to the left of this is so incredibly important. All right, so you get through all this, and almost always, if you've expended all this money and time and people and energy and resources and all of this and you're ready to exit the stage, it's almost inevitably a thumbs up from Executive Management. Let's see, yes. Rate a release for manufacturer. So then you go into the manufacturing phase and this exit criteria coming out of manufacturing, almost always is a yes as well, because you want to get into validation at that point. We built a bunch of products, some number of our units and we want to start to validate them. In assuming an ASIC design Application-Specific Integrated Circuit, the RTL coding, if you didn't spend all that time upfront doing design planning, architecture specification and all that, it used to be a three-legged race, that's what we used to call it. Getting only RTL, everyone was starting on the same date and it was a race to get the RTL coding done and get all the verification done and get all the physical design work done. And it was like three horses on a race track and everyone is trying to get done first. Inevitably, verification and physical design end up taking the longest, especially, if it's a complex ASIC. But if you've spent all that time up front like I alluded to a few minutes ago, when it comes time to write the code or the software, this applies to software development as well, literally, the code just goes out of you, you sit down, it goes "I know exactly what I have to type, I know exactly what I have to code here" because it's so intimate to you and you've spent so much time thinking about it. at this very fine-grain level, the code just falls out of your brain. You could get your Emacs Editor and just kind of like tap on the side of your head and the code would come out of your ear and go into your Editor. And it's really surprising and whoosh, out it comes. Actions and deliverable is in this stage. So, with this design completed, the RTL code of coding phase becomes short to solve it, with software product as well. Software just kind of falls out of this thing. I talked about that already. Then, so you get all the coding done and then becomes a race between verification and basic physical design, or just the physical design for a product. So, task that happens here and basic physical design as pin placement, cell placement where all the cells are going to go, if it's an FPGA, you're going to take your RTL and synthesize it and you just run the Xilinx or the Altera script, and it synthesizes and places and checks timing, and does all that stuff for you. With an ASIC, you have to have encircling custom clock trees, routing, you do static timing analysis to make sure that all the flip flops that launches signal can get to the destination in time, you insert scan test logic and you run automatic test pattern generation, which is those patterns that are used on the tester. Your chip gets put down on a big 12 inch wafer over and over and over and over and over again, or maybe hundreds of Amana and a 12 inch wafer, and every one of the better nails tester comes down to test each one of those A6. Yes, it's one of those chips, it's one of those dye and those patterns that came out of the automatic test pattern generation process. There's a tool that you run to generate these patterns fed into the tester, and the testers and exercises every single dye it starts with one and just moves down the row. And if one of the dye fails the test because there's manufacturing defect or a dust particle, something's wrong with it, didn't pass a test and put a little link that on it so that dye doesn't make it into becoming a package part and gets shipped to the customer, can get shipped back to you.You put on the board because it's known bad. So that's what the ATPG is, it's an automatic test pattern generation. You need that when you go into the manufacturing part. So again, you get to hear the exit criteria, are all the reviews complete? Is the verification complete? I'm going to talk more about that in a minute. What does it mean? Vice Presidents get together, Directors give the thumbs up or thumbs down, we're ready to exit this stage move on to the next stage.
