Embedded System Lecture 1 (a).pdf

Embedded System Lecture # 01(part # 01) Hello and welcome to the first lecture of the embedded systems course. I would start the lecture promptly with this first slide, which is telling you, of course, why you should be part of an embedded system and why you should study embedded systems. The global...

Embedded System Lecture # 01(part # 01) Hello and welcome to the first lecture of the embedded systems course. I would start the lecture promptly with this first slide, which is telling you, of course, why you should be part of an embedded system and why you should study embedded systems. The global embedded systems market size reached US dollars 162.3 billion in 2022, and the expectation is that it would rise up to US dollars 258.6 billion by 2032, with a combined annual growth rate of 4.77 percent during the next 10 years. So, I am certain that this slide and this text only is a great motivation for you to be getting involved in better systems and working with embedded systems. The obvious question that comes to the mind is why this huge market, why this huge sales figure, and why this huge growth rate? Well, there's a lot to embedded systems than does this slide.  Welcome to this beautiful red-colored slide. I hope you can enjoy the text that is written; pardon my handwriting and writing with the mouse. The main reason for these huge figures is that embedded systems come in different forms and sizes. They can be in the flavor of an ASIC, for example, a microcontroller, which is basically an embedded system designed for a particular domain. For example, microcontrollers are designed for industrial control and optimized for industrial control. Not only that, embedded systems can also be implemented using different approaches. For example, embedded systems can be processor-based, such as Raspberry Pi and other things like ESP32 or Arduino, for that matter. Not strangely enough, embedded systems can also be FPGA-based, which are field-programmable gate arrays. Field-programmable gate arrays are smart devices that consist of logic cells that can be used to implement any digital circuit. So, when embedded systems come with the flavor of FPGA, they can be of two types: embedded systems can only be FPGA-based, or they can be an SoC or a System on Chip based. For example, on a certain single chip, the CPU core and the FPGA portion or programmable logic code can coexist. So, we can say that embedded systems can come basically as a processing system code and a programmable logic-based system. You can do all programming on the processing system, and when you need to have custom hardware for accelerating your algorithms, you can program them using the programmable logic fabric of the FPGA. When you do these kinds of things using the programmable logic, you come to the concept of accelerators. So, FPGA-based systems can have normal code running on the processor, but if you need specialized hardware or an accelerator to accelerate different tasks, for example, graphics processing, you can use the programmable logic-based subsystem of the device to program your hardware into that. Basically, we have this great thing, and the greater thing that we can say is that anything can be coded, can be converted to hardware. So, in essence, there is no difference between what hardware can do for you and what software can do for you. Both of them are equivalent, but of course, from a performance point of view, the hardware-based accelerated approach would be better because we can have different kinds of optimizations for that. This approach that I discussed about the processing system and the programmable logic fabric is implemented, for example, by the Xilinx Zynq family. How can we create these accelerators? Well, to create the accelerator, you can use different approaches. One of the approaches used is to have a hardware description language which describes your hardware of the accelerator. HDLs can be very long, HDL, which is C language-based, or HDL can be VHDL, which is Ada-based. So, if you want to work with hardware description languages, you can use these two flavors. But of course, there is another approach which is very simple and straightforward, which is called high-level synthesis. Using high-level synthesis, you can create your accelerator code first using C language or C++, and then you can let the software convert that C language code into the HDL automatically. What's the benefit? The obvious benefit is you don't need to learn Verilog, you don't need to learn VHDL. You can work on your C/C++ code, and the system can convert that using HLS into the hardware description language code that describes your accelerator. Now let's take a look at the difference between an embedded system and a microcontroller. This is actually a very common discussion that is done in many discussions or interviews. Well, embedded systems and microcontroller-based systems. So, point one about embedded systems is that when we talk about embedded systems, they have larger resources, large RAM, large ROM, etc. An ideal example of an embedded system would be consisting of devices like Raspberry Pi, ESP32. These are all examples. As far as microcontroller-based systems are concerned, they have very fewer resources. Many microcontrollers, surprisingly, have very little amount of RAM, for example, 256 bytes, 512 bytes. Are you surprised? Now, that's the way this is the problem. They have a really less amount of resources because they are mostly single-function. They have got one single function. For example, microcontrollers are optimized for industrial control, like I said before. So, for carrying out a single function, lots of resources are not required. That's why microcontrollers would have fewer resources. But, for example, embedded systems might be having a general-purpose behavior. For example, a Raspberry Pi system is a complete system that can carry out multiple tasks. Your mobile phones, for that matter, they can come under the category of an embedded general-purpose system because they can carry out different tasks and run different apps. So, let's look at the outline of what we'll study: embedded systems overview, what are they, the design challenge, how you have to optimize the design matrix. This is an important term. In which technologies you can implement embedded systems, you can implement using processor technologies, IC technologies, design technologies. Now, let's take a look at embedded systems. We know that computing systems are everywhere, right from your microwave ovens to your washing machines, to your television sets. They are everywhere. But most of us think about desktop computers, right? But there's more to embedded systems than just desktop computers. But there's another type of computer system which is far more common, of course, our embedded system. So, embedded computing systems overview: what are embedded systems? Computing systems embedded within electronic devices. So, one of the definitions of an embedded system can be computing systems embedded within electronic devices. For example, computer system in your camera, computing system in your dishwasher, computing system in your fully automatic washing machine. These are all examples of embedded systems. And one of the big stages of embedded systems is a car of today. So, our cars are very electronic and very digital in nature these days. So, the electronic fuel injection systems, ABS systems, emission control systems, these are all examples of embedded systems. As embedded systems are small, they are very pervasive, so billions of units would be produced early. Right, so that directly translates to our discussion of the first slide, of course, right? This huge market. So, this is one of the more reasons for having a huge market for embedded systems. And of course, as it says, perhaps 50 per household, and per mobile or for automobile, some battery systems would be present in the automobiles. They are present in the automobiles. So, a very funny slide, a short list of embedded systems. Not only that, the list goes on and on. So now, some common characteristics of embedded systems. This is again an important slide because it is telling us about what are the key components or key characteristics of embedded systems. So, most of the embedded systems would be single-function, and single function means they execute a single program repeatedly. I talked about accelerators in the previous slide. Accelerators would also be a form of a single-function embedded system, right? They would be accelerating a certain task. A classical example can be taken in your digital cameras, right? So, in your digital cameras, the system that converts your image to a particular format, for example, JPEG, would be an example of a single-function system because that function only has a single function, to convert the image into a JPEG format. They are also tightly constrained, and by tightly constrained, we mean they must be low cost. You can't have an embedded system or a very popular embedded system that costs $5,000 or 5 lakh rupees, for that matter. And they are tightly constrained, which means they must be low power, especially in today's scenario, battery-operated functionality. The power factor is very important. So, low power is a very important requirement for today's embedded systems, and they must be small, they must be fast, and for some applications, they must be very reactive and real-time. And what do we mean by reactive in real-time? They continually react to changes in the system's environment. A classical example would be in defense applications of embedded systems, right? An anti-radar system or anti-missile system, for that matter, that shoots down missiles, locks missiles on the target, and shoots the missiles down should be very reactive and real-time, right? The F-16 fighter bomber has got a sequence of embedded systems. It employs redundancy in embedded systems, right? There are three embedded systems. If the first one fails, the second one takes over. If the second one also fails, the third one takes over. And what the embedded system does in F-16 is actually a very classical example because in order to fly the aircraft, you need the embedded system because the aircraft is so unstable that without the embedded system, the pilot would just faint because the aircraft would toss and turn, and the pilot won't be able to control that, right? So, these are the different very important applications and characteristics of embedded systems. The same is true for the B2 bomber. B2 bomber also has a lot of embedded systems to make it fly properly because, again, B2 bomber is a very unstable aircraft. It's a good example, which is a digital camera, right? The digital camera has got different systems, right? It has got a microcontroller. The role of the microcontroller is to handle the slow operations, right? Slow operations like responding to buttons, starting the video capture, ending the video capture, responding to different buttons and inputs from the user, right? Since the user would be slow in presenting inputs, the microcontroller is enough to take care of the things. There are also special-purpose devices or specialfunction, near single-function system, which would be called single-purpose processors, like JPEG encoder, like I discussed before. That would convert the image from the raw form into the JPEG form. There would also be a DMA (Direct Memory Access) controller, which is again, would be an SPP. Chargecoupled device or CCD processor would again be an SPP because it would take care of the image that is cast on the charge-coupled device. Then we have the pixel core processor that would be handling the pixel-oriented tasks, again an SPP. The idea of this whole slide is to tell you that an embedded system might consist of different kinds of subsystems. Some of them might be ASAP or application-specific instruction set processor, like the microcontroller, while other blocks would be single-purpose processors or SPPs. So, what is the functionality requirement of an embedded system? It should be single-function. A digital camera is always a digital camera; you cannot use it as a washing machine. Similarly, tightly constrained, it must be low-cost, low-power, small, and fast because the camera has to be held in the hand. So, it should not be the size of a brick. Similarly, it is battery-operated, so it must be a low-power device and low-cost so that everyone can purchase a digital camera. Reactive and real-time? Not really necessary in this particular thing because it's not a mission-control-critical application. It won't be very bad if there's a 200-millisecond or 300-millisecond delay in taking a picture. So, it need not be reactive in real-time. Reactive and real-time are fast systems, like I discussed before, like the flight control system of the F-16 and the B2 bomber or the flight control system of the Space Shuttle. Now let's move on to the design challenges when we are making embedded systems. Making the battery systems is challenging because we have to work with design metrics, and we have to optimize the design metrics. What is the design metric? It is a measurable feature of a system's implementation. Optimizing design metrics is key. For example, if I am designing a printer, my design metric would be pages per minute. It should have the most number of pages per minute to be faster. So, this is one of the design metrics. Every obvious goal is to construct an implementation with desired functionality. If I am making a printer, my obvious goal is to make it a printer first. Functionality should be correct. It should be able to print. So, what is the challenge here? Simultaneously optimize numerous design metrics. We'll discuss afterward the design metrics compete with one another. If you make one design metric good, that might make the other design matrix bad. So, you have to have a balance or a trade-off between design metrics. So, talking about design challenge and design matrix, what are the common design metrics? Unit cost: the first design matrix is the unit cost, the monetary cost of manufacturing one copy of each copy of the system, excluding the non-recurring engineering or the NRE cost. This is simply the cost of making one device that is sold or one embedded system that is sold. And what is NRE (non-recurring engineering) cost? It is the one-time monetary cost of designing the system. You might say that it includes the coursework, research and development, initial prototype design, etc. So, all the costs that are involved with that would be called NRE cost. Size: again, the physical space required by the system. For handheld devices like your smartphones, smaller is better, right? Smaller, lightweight, low-power is better. Performance: the execution time or throughput of the system. One important point to note that I would be emphasizing it later on is that performance is measured from the point of view of the performance of that particular embedded system. For example, if I'm considering a printer, sorry, I am interested in pages per minute. If I am buying a printer, a printer with the pages per minute of 5 is bad as compared to a printer with pages per minute of 10. I don't care about the processor that is in the system. I don't care about the amount of RAM that is installed in the system. I am only concerned with the performance with respect to the functionality. If the functionality is better, my embedded system is better. So, I'll go for a printer with 10 pages per minute as compared to 5 pages per minute. Power, of course, the amount of power consumed by the system. Flexibility, the ability to change the functionality of the system without incurring heavy energy costs. So, if you want to change or add a feature for flexibility or functionality to the system, it should be flexible. You should not have to redesign the entire system to implement a small change. An ideal example is changing firmware. As firmware is changed, the entire embedded system can have different and optimized behavior because firmware change is only a software change; there is no major change in the hardware of the system. Okay, design challenge optimization for the review. Again, common design metrics also include time to prototype - the time needed to build a working version of the system. The time to prototype means we want to develop an embedded system where we ensure the functionality of the system. The system might not be optimized, but the functionality would be ensured at this stage. After time to prototype, there is time to market - the time required to develop a system to the point that it can be released and sold to the customer. Time to market is basically the time required to make a sellable version of the system, and this would be the final version that would be sold to the customers. Maintainability, the ability to modify the system after its initial release. Remember I said before that maintainability is good. It comes under the category of flexibility. Firmware updates, firmware upgrades. As far as FPGAs are concerned, they can be reconfigured for different functionalities in real time. Today's data centers have got a lot of add-in cards that consist of FPGAs. So, FPGAs are very flexible. I'll give you an example. Let's say in the morning, we have the system which is being used to accelerate databases. So, the FPGAs would be considered configured as or programmed as a database accelerator in the morning. But in the evening, there are users that are using it for scientific applications. So, during the evening, the FPGA would be reconfigured for scientific applications. So, the CPU would be there, and we will have different customizable cores or accelerator. C1 is the database accelerator core in the morning, and C2 is the scientific application accelerator core in the evening. Okay, a design metric competition. I discussed before that design metrics compete with one another. So, improving one may worsen the other. So, what is the punch line over here? Expertise with both software and hardware is needed to optimize the design metrics because you should be aware that which aspect of the functionality can be done better in software and which can be done better in hardware. Theoretically, we know that whatever software can do, the hardware can do. There's no difference. But based on different considerations like cost, size, etc., you may need to make decisions when you are developing an embedded system that which components of the system would be carried out in software and which would be carried out in hardware. So, a designer must be comfortable with various technologies in order to use the best for the given application and constraints. So again, as in the digital camera example, this, for example, CCT preprocessor is hardware-based, and microcontroller is the software-based component. And this diagram says that design metrics are competing with one another. If the power consumption is reduced, right, you make the power consumption better, and the NRE cost might be more. So, it would worsen, right? So, this is the idea. So, if the performance is increased, right, the size would be decreased and so on. But again, size and power are related. If size is reduced, the power consumption might be increased because of the excessive power dissipation. So, this is basically a double headshot. It might work well for you; it might not work best for you. Time to market is a demanding design metric which is the time required to develop a product to the point it can be sold to the customers. Time to market is very important when you're selling a device, for example. If Apple is making an iPhone, it needs to make it on time so that the time to market is as low as possible because if Apple takes too long to develop the iPhone, the market window would be lost. Market window is the window during which you have maximum sales. So, the average time to market constant is about eight months. So, any product that has to be designed has to be released in about eight months, and delays can be costly for that matter. So, as we can say, roughly, this is the graph between revenue and time in months. So, the cycle is that revenues are initially low and peak in a certain window, which is this window. This is the market window for this particular device. Right as we can see and after this period, revenue again starts to go down. So, to get the maximum revenue, the product must be released ideally in this particular window. If it is not released, of course, if it releases at some point in time over here, less revenue. So, this is basically the main thing, and delays can be costly like when we see shortly. Now let's try to formalize this calculation because delays are very important, and we must find out how much do delays cost us. What is the effect of delays on revenue? To do that, we can develop a mathematical model. So, the mathematical model is being developed using this approximation for this particular figure. So, we have a bigger triangle right, which represents the total market window and the peak revenue that can be generated. So, we start from this point in time, we move to this point, maximum revenue, and then we go back. There's another thing that is the delayed triangle, and later triangle starts with the delay d. So, this basically is d. So, we start, release the product after this delay d. Again, the revenue peaks at this point now, which is the delayed revenue, and then it goes back. Okay, this length is W in terms of time, and this total is again 2W because this is W, and this is W. Okay, so now, of course, the product life is 2W, right? This is the market window, complete like we discussed this, right? And this peak set W both for the case of one time and both for the delay as well. And as we can see that when we have the delay D, the revenue is less than the peak revenue. So, what is the loss? That's the difference between the on-time and delayed rectangle areas, right? So, the whole revenue is this, the big area of the big triangle, and the delayed revenue is the area of the small triangle. So, if we delete or subtract the smaller area from the bigger area, this basically would give us the loss in revenue that will have this respective particular effective thing that we are looking at right? So basically, areas happen to base into heights. So, what is the on-time base? It is 2W, and what is the on-time height? It is W. So, on-time area is half into two W into W. So now, we'll have the whole revenue, which is this area of the bigger triangle, and we'll subtract the area of the smaller triangle to get this particular thing, which is the loss in revenue. So, what is the on-time area? On-time area is half into base, which is 2W, into height, which is W, since this length is W. This height is W because Theta is taken to be 45 degrees. Similarly, for the delayed, half into base, the base is 2W minus d, into what would be the height? This is W minus d, W minus D. So, height would also be W minus D because Theta is 45 degrees. So, this is the delayed area. Then we can find the percentage revenue loss. So, the percentage revenue loss is given by the formula: Percentage Revenue Loss=( (On-Time Area− Delayed Area)/ On-Time Area ) ×100 Please go ahead and solve this using this formula to get this particular expression. Now, let's have an example that the lifetime is 52 weeks and delays 4. Please find the percentage revenue loss, and do the same for the second example. The results would be very interesting. I would invite you to find the results of what you get and show me... Absolutely, let's highlight the key points in bullet form: Market Overview:  Global embedded systems market: USD 162.3 billion in 2022, expected to reach USD 258.6 billion by 2032.  Annual growth rate: 4.77% over the next 10 years. Embedded Systems Forms:  Various forms and sizes: ASIC, microcontrollers, processor-based systems (e.g., Raspberry Pi, ESP32, Arduino), FPGA-based systems (SoC and standalone).  Xilinx Zynq family example: Combining processing system code and programmable logic fabric for flexibility. Accelerators and High-Level Synthesis:  Accelerators: Custom hardware for specific tasks.  High-level synthesis (HLS): Convert C/C++ code into hardware description language (HDL) for FPGA programming. Embedded Systems vs. Microcontrollers:  Embedded Systems: Larger resources (RAM, ROM), versatile (e.g., Raspberry Pi), generalpurpose.  Microcontrollers: Fewer resources, optimized for specific functions (e.g., industrial control). Design Challenges:  Optimizing design metrics: Balancing unit cost, size, and performance.  Unit cost: Monetary cost of manufacturing one copy, excluding non-recurring engineering (NRE) cost.  NRE cost: One-time cost of designing the system. Common Design Metrics:  Size: Physical space required by the system (smaller is often better).  Performance: Execution time or throughput, measured based on the specific embedded system's goals. Performance Over Hardware Specifications:  Emphasis on functionality over specific processor or RAM details in embedded systems.  Preference for better functionality as a key factor in determining system superiority. Flexibility in System Design:  Prioritization of the system's ability to adapt and change without significant energy costs.  Highlighting the advantage of firmware changes for optimizing embedded systems without major hardware alterations. Design Challenges and Optimization:  Introduction of common design metrics, including time to prototype, time to market, and maintainability.  Acknowledgment of the competition between design metrics, requiring expertise in both software and hardware for optimal solutions. FPGA Flexibility:  Illustration of FPGAs' flexibility, allowing real-time reconfiguration for different functionalities.  Example of a system using FPGAs for database acceleration in the morning and scientific applications in the evening. Time to Market Significance:  Emphasis on the critical nature of time to market in product development.  Explanation of market windows and the impact of delays on potential revenue. Mathematical Model for Revenue Loss:  Formulation of a mathematical model to calculate the percentage revenue loss due to delays.  Introduction of the on-time and delayed areas as triangles to represent revenue scenarios. Example Scenario:  Application of the mathematical model to an example with a system lifetime of 52 weeks and a delay of 4 weeks. Invitation to calculate and explore the results for better understanding