Process. So, the goals of any product development process would be to minimize the area under the heap curve, heap chart curve, keep the head count down and the duration is as short as possible, and produce the highest quality product possible within the scope and the schedule and the resources, that meet the customer requirements. So, it maybe an obvious statement but I just wanted to put it down to drive home the point. This is a classic mistake, be aware of this, because I've done it in my past. Then, when I get farther into the project, I realized that I made a mistake. Jumping in and starting to code before the product is defined, all the requirements have been gathered and the architecture has been figured out and the implementation documents have been written because engineers like to start coding. Like, "Oh, I know what we need to do. I'm going to start writing a C code for that. I know what I'm going to do. I know just what to do, okay, because I'm going to go off, I'm anxious to start writing out geocoder, typing RTL code and running simulations. All right. my safe machine is working. Excellent. Oh, my data's moving through my module. Fabulous. This is great." You have to resist that temptation to do that, it will take way longer for you to build your project if you just jump in and start. You have this rough idea of what needs to happen but you don't have all the details yet, and you're just biting at the bit to get going. It will end up, inevitably, taking you longer, if you had slowed down and gather the requirements, royalty architectures classification, did the implementation detail, did the design ahead of time, we'll see that here coming up. A modern design process uses- I think we call it 3D when I was in the past life. It is design first, develop second, and deploy is third. I have a picture of this here. So, time is going from left to right. So, you do all the design work here, you do all the development work here, and all the stuff that happens in deployment, happens out there. So, each of these three phases is broken into two sub phases. So, here's, under design, we've got architecture definition and design planning. So, this is where requirements are gathered, the architecture specification is made. This is where all the actual design is done. You don't start development until the design is completely done, and like I said, so many engineers want to jump in right there. "Guess I'm building this. I'm going a breadboard it, I'm going to- I can't help myself." I understand that. Believe me, there's a strong desire to jump in and just start writing code because you know the code has to get written at some point. Right? But you're going to end up throwing that code away. If you take the time to do the architecture definition, do the design planning, you want to make this period as short as possible, and if you jump in right there, it's going to be longer than you think it is. Even if you've done it before in a previous project, it's going to take longer. So, there's the development phase, it's split into software development to development of the hardware, they're all electronic components, the physical development, and print circuit boards, the case, and display and all that, whatever external features that your product has. Then you go into this manufacturing phase. Then, you get manufactured products back, or maybe you might have have outsourced to assembly companies or if you're really big like Apple and Google, they use Foxconn and others, to do their manufacturing for them, but if you're a small company, you may manufacture your products yourself. Then, you get your products back and then you enter this validation phase. Then, once you're through the validation process, you're ready to go into production and start shipping products to your customers. So, this is where we left off in the last class, and we were looking at a development process. Just to review, there's this a notion of designing first, developing second, and deploying third. So, three primary phases, each of those phases is subdivided into two additional phases. The design phase is subdivided and starts out with the architectural definition and then design planning. The development phase is where all the code is written, all the electronics is developed whether that be a custom application-specific integrated circuit or FPGA, printed circuit boards. There's physical development that needs to be done designing if the product has a case putting all of that together. You have to have a plastic case for your product. Somebody, somewhere at a mold shop, will have to design your mold, half plastic would be injected into and produce the plastic pieces for your product, that will encase your product. Then, you go into the manufacturing phase, where you have some number of products built. Then, you go into a validation phase and we'll talk some more about that and then you enter production, finally. The next series of slides assumes an ASIC development but these ideas, these notions can be applied to the development of any product, any system, small or large. So, what happens in the architecture definition phase? So, this is not a complete list but it's a good start. Actions and deliverables that happen in the architecture definition phase. You capture your requirements, you write your requirements document or put them into a database, it could be a spreadsheet, something, either shall statements, the product shall do this, list all of the features, you may have cost targets from your product marketing people. If they say, in order to sell this product in volume, you have to hit this price point. Power requirements of product won't exceed eight-and-a-quarter watts, for instance, or power won't exceed two watts or whatever it is. Size and weight, performance, specifications, all of these requirements that the product needs to meet needs to be captured. So, everyone working on the product development can go look at that database or that document and understand what the requirements are. My work we're switching over from using this enormous spreadsheet and putting all of the requirements into a database, where we can run reports and filter and sort and compare and do all the things that would be much more difficult to do if we stayed with this spreadsheet approach. Once you understand what all the requirements are, the architects will write an architecture documentation. What it does, how it works, data and control flow, UML diagrams. Raise your hand if you know what a UML diagram is. Okay. For those of you who don't know what a UML diagram is, I think years ago, the creators of UML, they thought that this would be some kind of executable specification, at least that's my understanding. I'm not 100 percent confident on that, but, here's the idea of a UML diagram. So, imagine your product has two CPUs and in it is a bunch of hardware modules. Okay. So, let's see here. I'm just making this up on the fly here this. Let's say, we have a primary communication with the outside world for this product as an Ethernet piece of hardware, Ethernet connection. So, you got some Ethernet hardware that is capable of sending and receiving TC IP packets. Okay. Then, I'm just going to call them CPU one and I'll put CPU two over here. Now, we have- let me put some boxes around these things. Hardware one and hardware two. Time in a UML document flows down. So, I used to draw these when I was at Seagate. I draw these vertical lines like this, each of these. So, time starts here, and a packet is received by the hardware. The packet, sometime later, after maybe the CRC has been checked, the address has been checked and header, some finite amount of time goes by, the packet is sent to CPU one, where some processing takes place. It might be a command, it might be part of a video stream, who knows, something, some amount of time goes by. Some number of computations takes place here. You can bound this and say, it has to happen in X microseconds or X nanoseconds or whatever, and that can be a requirement that is captured in the requirements document. Then, the CPU send some kind of a control message to this piece of hardware to get it to do something and it operates on the data and that takes some amount of time. Then maybe, this piece of hardware sends a message, some other kind of message over here to the CPU and some more processing takes place. Maybe hardware two is a display. I'm just making it up. Some kind of data is now given to this display. Then maybe an acknowledge is sent back here, which says "Yes, I got that." Some time goes by here and this CPU, it has to process that acknowledge, and it sends some kind of message or status back to this hardware or maybe, it bypasses this one, [inaudible] to say. Just bypasses it altogether and comes back. The CPU just communicates directly with the CPU, we're done. Then, some processing gets done and another done message is sent to the Ethernet packet. Very shortly after that, say an ack is sent back to the sender of this packet. This is a great way to stand back in a design review and even in your own, to build your own mental scaffolding about how your product works. What happens when information is processed by hardware incentives software running on a CPU and what the flow is through your product. I drew these all the time for SSDs. It's very handy. Most embedded systems, complex systems like Industrial Internet of things, systems, it's important to understand where the division of labor between hardware and software is in a UML diagram. Again, it's another great way to see what that division of labor is. You can stand back and look at it and say "Okay. I think this works." You can create a model of your system and test it and see if it does work, and you may discover that, well, we're doing all this computation here, and this is, we can't get all that, what we thought we could get done in this amount of time, it can't be done, so, we're going to do less of it and we're going to move some of that functionality that was in software or firmware and we're going to move it over into hardware and it gives you the ability to move, responsibility between pieces of hardware and pieces of software.
