Another outcome from this is you build what's called the top-down schedule. They have a funny word where I work. They call it tops down and bottoms up. We'll get to the bottoms-up in a moment. I'm not sure why the S is in there but I've always previously heard it as a top-down schedule. So, this is a rough estimation based on the requirements, your architecture specification to usually run my manager I showed you in the org chart. We put the schedule together and this is usually based on experience from the previous project. This is about how long. This is all the work that has to get done that we know has to get done and this is about how long we think it's going to take. But this is inaccurate at this point in time. We don't have enough data at this point in time to say yes we're going to start on this date and it's going to take exactly this many days to get it done. Again, very handy the more complex your system is really benefits you to build a performance model or some type of a behavioral or a time-based transactional model. You can use SystemVerilog, you can use System C. You use something that has a concept of time to build a model and you can learn all kinds of fascinating things about your design when you do this. We are in the throes of developing some performance models where I work and we get useful information out of them. I had them when I worked at Seagate and it was invaluable. I could turn all kinds of knobs, adjust buffer sizes, adjust speeds and adjust the workload that was given to a drive. I can stand back and watch how the drive performed and extract all kinds of interesting metrics from it, and this is well before the drive was built. Then sometimes I would have to circle back and change requirements in this database back here because we uncovered key insight that we didn't have before even by looking at a UML diagram it didn't give us enough insight to what was really going to happen. So, the performance models were very very very complex systems really useful. Later in the semester we'll talk about system C. It's free. You can go get it and install it and you guys I'll talk about that later. So, a bunch of work happens here but none of it's coding. I'm not coding anything yet. Figuring out, trying to get to the bottom of scope, schedule and resources that's what management needs to understand. How big is this project, how many people was it going to take. Once the architectural definition work gets done, it is not uncommon different companies column, different things. They were called- they call them at Seagate. I can't remember what they called it at Sea gate. They're called Stage Gates at my ground. That's what we call them. All these documents and all this work gets done and a series of people vote on get together senior management or director level type people, and get together and say, "We've reviewed all of this material, are the reviews completed? Does the cost targets look good? Is power look good? Get information out of the performance model. Do we look like we have a competitive product?" They vote, and they give a thumbs up or a thumbs down. "No, this product is uncompetitive. Go back and come back with a more competitive product." Okay, so you go back and you rework this stuff and you come back again and they look at it again and eventually, hopefully, if you've done a good job you get a thumbs up and then that enables you to move into the next phase. In the next phase, in this process, it's called the design planning phase. So, actions and deliverables that happen in this phase are initiating requests for quotes from vendors and making vendor selections. Oftentimes when companies manufacture products so much of it gets outsourced. So, you need to send requests for proposals and request for information and requests for quotes, and you get that back from multiple vendors. Some companies will like to manufacture everything and own everything inside but oftentimes manufacturing of products requires the engagement of outside design services, board manufacturing houses, assembly facilities, testing facilities. So, there's a lot of work that happens with outside vendors here, so that's what this initiate requests for quotes is all about, and it takes time to do that. It can take weeks and weeks and weeks and you go back and forth with the vendors or we don't like your price. Can you do better on your price and then they go off and a week later they come back with that new price and you try and hammer them down and so it's still too expensive. Can you shave another 10 cents off that or another dollar off it or whatever? So, it's an iteractive process but it takes time. So, while that activity is taking place, actual engineers that do the work, will write the code, write the software, write the RTL code if it's an FPGA or an async. They are not writing the code yet. You're going to write a document called a low-level specification. At Seagate we used to call them micro architecture documents, and this is where the design is done. You figure out your state machines. Every single module inside the design is described with all of its inputs, it's clocks, it's resets, all of its outputs, its behavior, its state machines, the relationship between control and the data, error checking, all the CPU accessible registers, software accessible registers, all that stuff is written in the specification. If you do this up front, it will dramatically shorten the time it takes to you when it comes time to actually write the code because you spent so much time. This is a lengthy process, okay. It takes lot of time. Weeks, weeks and weeks. You've been working on that document for so long but when you exit this phase, and you will see on the next slide the code just goes. It just comes out very quickly. It's very very- it's stunning when you go through it and do it this way for the first time because when you stand back and look at this is going to take forever. We got to start coding right now. That's a flaw in thinking. I have done it that way in the past and when I went through the first project that we decided we were going to do it this way and do all the design up front for any line of code, real code was written. It just looks good, it's light bulb but had this great epiphany and like wow. I think it took me like three days to write the RTL code for this complex design as because it's so fresh in your mind and you understand exactly how it works, what all of its requirements are, because all requirements were captured back here. You had a performance model to validate that the implementation was going to do or meet your performance expectations. So, you document all that stuff in a document. So, you document the hardware. So, the data and the flow control state machines all of that. In parallel with that, the software team is off doing a similar thing and the teams worked very closely together to define the low-level interaction between hardware and software for an UML diagrams can be great for that. I'm sending you a message, and you're sending me a response. Hardware's talking to the software back and forth. So, they do a very detailed software. A document capturing errors, what happens on errors? Many products need to report errors or understand that something has gone wrong and software needs to take corrective action. Firmware engineers when I was at Seagate told me that roughly 60 to 65% of the code with error handling code. So, over half was responding to errors. There was a parody errors some place, there was a CRC check failure some place. I was surprised to hear that number, but then when I started to think about how many errors that we had, it started to make more sense, but it was a little surprising to me at first. So, having all that written down in a document ahead of time everyone knows what's supposed to happen. You get this error. This is what's going to happen. This is what the hardware does. This is what the software's going to do in response to that error and it's been reviewed and everyone agrees this is how it's going to behave. Then test plans. Every module all the way up to the whole entire design, [inaudible] entire product, it needs to have some kind of a test plan and every sub-module within it art and engineer is responsible for some module there's a test plan for that module. All these test plans get rolled up into the overall test plan. So, understanding how you're going to test it, how you are going to verify that it's functionally correct is very very very important at this stage before you start getting into the coding phase. They'll write, and who better to write the test plan than the engineers that designed the hardware and the engineers that designed the software. They understand what has to be tested because they understand the requirements and they understand their design because they've just spent six weeks writing a micro architecture specification for a hardware and for the software and they will list out this has to be tested, this has to be tested, this has to be tested, this has to be tested and there can be several 100 lines long for a particular module. So, that's some of the documentation that gets generated. The verification side to be a verification lead and they'll write the testbench specification, how will this design be verified? We've got to design Device Under Test that we draw it out here, DUT, Device Under Test. This might be a submodule and an FPGA or an ASIC. This might be a one or more software routines written by a programmer. It's something that needs to be tested at some level, but just for the sake of discussion let's just say this is at the product level. So, you need something that will provide stimulus to it. If it's a chip, it's going to need a clock, it's going to need a reset, and it's going to need some input data, some kind. Outputs come out over here and there needs to be some checker or checking and often these communicate with each other, and the test bench, never heard that word before, term means this whole thing. It's some environment where the device under test can be stimulated and checked for functional correctness. I used to work closely with the verification lead because there were things I wanted to see in the testbenches, and I wanted to make sure that those features and those requirements, got into the testbench and were implemented. So, I can run the type of verification tests that I wanted to be able to run, but it focuses on how are we going to verify this. So, once the engineers, hardware engineers, software engineers, a test plan and testbench. This has all been figured out, it's often designed, we understand and with great detail, great and might hear the word fidelity. How well do we understand this design? We understand this that the team understands this design with a very high level of fidelity, means we understand it in very small increments or we have very fine-grained knowledge. Okay. Armed with that, experience and spending this time up front, it is possible working with the project manager to build the "real" schedule. It really mean real. It's much more real, it's much more accurate than this top-down schedule. This was, you heard the term swag before, we're just going to take a swag edit and get close. This is an estimate based on current and past experience. This one here is built by the team. It's going do the write all the code, they're going to build this thing. They understand, it's going to take me two weeks to write this code, it's going to take me two days to do this, it's going to take me four days to do that. All of these tasks are assigned some number of days and then their project manager is able to build the schedule. It says, "Well, we have this many resources, we have this much scope. Here's all our work that has to get done, every single thing that has to get done has some number of days assigned to it. Most managers use Microsoft Project, you see Microsoft project in that. It's used a lot for tracking who's working on what, when, and you can predict with, when you have very fine-grained understanding of what the problem statement is and what the scope is. You can get very close to accurately predicting when you will be done with the project. No matter how big it is, whether you're designing an aircraft carrier or you're designing a Nest thermostat. You have real numbers now. So, we have high confidence in the schedule. So again, once all this has happened, you get to the end of the design. Planning phase here, key stakeholders, the Vice Presidents and the directors they get together and they look at all this data and on here, there's a bunch of reviews that happened as well. All the stuff got reviewed, you just don't write a micro-architecture document and hope nobody looks at it, every document gets reviewed, prereviewed. You have all these reviewers who spent all this time up-front making sure you've got it right, give you the thumbs up in the air ready to go into the next phase. Does anyone think what I've talked about so far was counter-intuitive in terms of how to get to the release date of your product fastest? No, don't be afraid as a security. It took me years to come to this realization that this is what works. If you want to get a project done in the shortest amount of time with the people you have available to your resources, and scope, and schedule, something like this, okay, is the way to go. Now, I want to say there's a whole another level of detail below this that we could probably spend a whole semester on planning and executing project programs, but that's not what this class was about. But in, Professor Ephemere wanted you to get some exposure to the design development process and in developing the Industrial Internet of Things. I'm not sure any of the other ECE embedded system engineering courses they touch on this very much. So, he was very excited when I told him I wanted to introduce what I've learned about building products for 30 years, 30 plus years. One of the challenges that I talked about before is, while this is going on, new requests are coming into this constantly and it might be hard to imagine that. Eventually, you get to some point and you say, "Alright. There's no more changes, there's no requirements because we've got to get on to actually building this this project. So, depending on how disciplined the organization is at the particular company, these gates here, these checkpoints, these milestones, can be very rigid or they can get a little blurry move around. It just depends on the corporate culture and the people and what's been done in the past. Test question on the exam next week, the design is done when you exit this milestone, this checkpoint, this stage gate. The design is done. Some people call it locked, it's frozen, doesn't mean changes can't happen. I'll talk about that later, changes can occur and a process has to be able to, a process can't be so rigid that no change is rejected.
