 So, embedded systems, they are everywhere, okay. In fact, it is hard to see something which is not an embedded systems anymore, right. Previously, we used to say, okay, sort of what are embedded systems, but you face them everywhere. You face them in the ATMs that you use for your bank transactions. One of the most impressive examples of an embedded system actually is this, right. It is quite amazing, the kind of technology that goes into this kind of thing, into a mobile phone. It is much more impressive than space technology. What you are able to achieve in a very limited footprint with battery power which you make last for about 8 hours and the amount of processing which is going on here, what used to be occupying an entire room full of computers about a couple of decades ago is there in your pocket, you know, right. And that is the amazing thing about this, especially with the new chipsets like the ARM9 chipsets which are there in the higher-end phones like the Sony RX910i and listen that, okay. They are everywhere, they are in your cars, they are in your defense services, right. I had a slide on that which gives the detail of where all these things are, right. Can you give me examples of where you would find embedded systems? Consumer electronics, whereas industrial automation, military applications, medical applications, aircraft, aerospace. Incidentally, a car actually contains technology which is from the aerospace industry, right. The same kind of systems that you had in aircraft come down at a fraction of the cost into automobiles. Like for instance, ABS, anti-skid braking, anti-lock braking which is there in higher end automobiles now was actually designed for aircraft, right. But now you find it in cars also. Air by wire is there in aircraft, now it is there in cars also, right. So in order to predict what is there in the automobile of tomorrow, you just have to look at the aerospace industry, right. And not only that, it is not a coincidence then that aerospace people, many of them are actually building cars, companies like Volvo, Saab and all that in Europe. And companies which are building cars in India are starting to get into the aerospace industry like Mahindra and Mahindra and various other people like this, okay. The skills are very complementary skills, right, engineering and design skills. So essentially embedded systems are everywhere and we presume that you will be wanting to play a role in actually building these embedded systems, okay. Typically in the past we used to say that embedded systems are usually single functional in the sense that they can do only one thing, right. That used to be the case in the old days with pagers and mobile phones and things like that. But increasingly now, right, a phone can be many, many things as you know, right. It can be a gateway to computing resources, it can be a modem for your laptop, it can be having lots of applications on it, MP3 players, video players and what have you, right. So what a phone is becoming is morphing at a terrific speed nowadays, okay. What it seems to be turning into is a gateway into larger computer resources, increasingly, right. Nokia has that as part of its future vision that a phone is going to be a gateway into computing resources. So you should look at it as a different kind of entity than the way we do at the moment. Typically embedded systems are tightly constrained, right unlike a traditional software system where if the software system is not running fast enough, the designer will say or put a memory Daldo, right or he will say put a bigger processor, we will solve the problem like that. In an embedded system you do not have the luxury because typically cost is the constraint that means you cannot have a higher end processor than what you have, right. Size is a constraint, the footprint of the processor has to be a given footprint like for instance I was talking to guys who had designed the onboard control systems of the gun stabilization controls in the Arjun tank, right. They had been told by the DRDO guys that it na jaga melega, this corner this board has to fit, right. So given that constraint they have to design the board with all its cooling requirements and footprint and everything to fit there, right. If they cannot do it they do not get the job, right. So it can be done and performance, right. Performance is very important. In a digital camera for instance, are you willing to wait 10 seconds after you click the button for your camera to store the image, no you are not willing to, right. You expect certain kind of speed at which this thing should work, okay. Even phones, right you become very impatient now with your address books on the phone because it is not fast enough, right. A few years ago you would have been grateful that there is an address book and you can store more than about 100 numbers on the phone. Things have changed, perceptions changed, power. You are tightly constrained in the amount of power that you have available to you. Like in a phone example, typically the amount of power which is there in the battery you got to make the most of that, right. You would not buy a mobile phone in which the battery lasts half an hour, right. So there are all sorts of very exciting tricks, interesting tricks that these guys use in order to prolong battery life. Like turning off parts of the circuit board and stuff like that, okay. Or more optimizing, more optimized algorithms, right. You never ever thought that the way you write a program, right, actually affects the physics of some processor somewhere. If you write a very inefficient program, it consumes a lot of energy. If you write a very tight, clever program, it consumes much less energy, okay. Because the amount of energy a program consumes, right, is totally dependent on the size of the program, right. And the number of instructions that you execute, right, per second or what have you. Because each instruction that you execute, actually what is happening is that it is causing some physical disturbance on a chip, right, gates are being operated and stuff like that. And to operate gates you need energy. So the more gates you operate and more often you operate them, the more energy you dissipate, right. So you never thought that the way you write your program can actually sort of have an implication on the power that you dissipate, okay. The other issues which come up in building of embedded systems are real time issues, right. So how this is to build reactive systems like the cruise controller of a car which has to respond to the environment around it to other vehicles and things like that. Traditionally cruise control used to be just you set a speed and it maintains that speed on the road, right. If a car comes in front of you and slows down, you will collide, okay. The new adaptive cruise control systems nowadays that you get in automobiles have a system of radars or detectors around the automobile. So if someone cuts in front of you, your car slows down and when it disappears, it speeds up again, okay. So real time means, right, reactive means that delay in computation can lead to the failure of a system, right. Your environment is actually setting the deadlines or the frequency with which you should react to events, right. If a missile is going at a certain speed, you have to match that speed or be faster in order to bring it down, right. So the environment sets the constraints and you have to design to those constraints basically, okay. So the plan here will be, we will swap these two parts, first our intro and then we will get into real time systems support for embedded software, that is what I mean by ESW. And then we will go into new paradigms, we will just touch a little bit about a language called Lava and then we will talk about handle C, right. Which is an interesting language in which you can have cycle level accuracy of building hardware systems and building parallel hardware systems. So to continue the exploration of embedded systems, you have three aspects to it, right. Hardware software and the architecture that you choose to use, right. You can build an embedded system in a variety of ways. You can just write raw programs, right, which can go and you can compile it into the gates which denote the chip essentially if you like or what you can do is that you can write a program that denotes, so you layer it into two parts. One is a program and an operating system, which you can put onto the chip. And the OS would typically be a real time operating system, right, because it is an embedded, it is an reactive system, where you can layer the problem in two parts. One is you can think of an application that you might want to build and the other is the RTOS that you want to deploy, right. And the way we work is that we take a traditional off the shelf real time operating system like RT AI or RT Linux or something like this. And depending on the application that we have, we can throw out various parts of the operating system. So you come up with a very small footprint operating system, which then you bundle with a program that you want to use or you want to run on the system and then you put that onto FPGA or you can deploy that onto a processor or what have you, okay. So software I think is not a very important part, it is increasingly becoming the most important part of the system design nowadays, right. And hardware is becoming more and more a commodity item. So to bring out this difference into how embedded software is different from traditional software and why you just cannot say that it is software on small computers, right. Is that typically it is dedicated, right. Typically you are interacting with the physical processes of various kinds, right. So you have sensors and actuators and various processes being controlled, right. Whether it is a mobile phone where you got to sort of talk to the antenna, the RF electronics. So you have to talk to the battery controller or what have you or whether it is the automobile systems, right. There are lots and lots of embedded systems in the automobile, right. So critical properties in an embedded system are not all functional properties. There are lots of time related issues like real-time issues, fault recovery, right. In the case of an error, right, how do you cope with it? Especially in a safety critical piece of software or a system, like for instance if you have a pacemaker, right and it fails. You cannot say oh dear, how sad, never mind. It is a bug, let us fix the bug, you know, right. You cannot do those kind of things. So how do you sort of design a system so you do not have to get to this situation? And what becomes increasingly important and there is not enough experience in this area is how do you verify and validate these kind of systems? Formal verification becomes extremely important, right. That means you need mathematical tools and people with mathematical skills who can prove to you given a program that it will never reach those dangerous states that you want to avoid. That is extremely important. In fact, we are setting up advanced automobile R and D lab here in which much of the energy of the lab will be spent in verification and validation of the embedded systems in automobiles, right. Power, security, robustness as I mentioned are important, heterogeneity, right. Typically you are given legacy hardware and you are meant to build software for it or you are given software which has to be ported on to new hardware and also mixed architectures might be there. I saw a little company in Bangalore which was grappling with the problem in the sense that it had an old HP device and they wanted to port all the software which existed on this tablet based kind of hardware which was meant for industrial applications, data collection and all that. To a new device that they had and sadly there was very little documentation, right. So, these are the kind of challenges that this industry is faced with. Then you have concurrency issues, right interaction with multiple processes, right all of them operating at the speed of the environment and so on. And typically once you have been through this whole embedded system space you realize that you do not know what is hardware and what is software anymore, right. If you look at it even the electronics even the micro electronics engineers when they build hardware they are actually working with software they are working in VHDL, right. So, VHDL is essentially a high level circuit description language, right. But it is a program which then some tools take and compile into something which can turn into hardware, right. And the language that we will be looking at handle C will be able to let you do the same thing. It lets you take a program which is very C like in its look and convert that into hardware and you do not need to know about electronics. You do not need to know about gates and flip flops and this that and the other, right. You just write your program and it gives you hardware. The program has some has a slightly different model in which you have to think. But then to take this one step further I have a PhD student here who is working on a thesis where he can take a C program and convert it into hardware, right. So, part of his contribution has been to come to a hardware intermediate language which is like your Java machine or virtual machine or whatever. But this is for hardware, right where you compile any language that you want into this intermediate code and from this intermediate code he can map your design on to any architecture you want. Whether it is a processor or whether it is FPGA or whether it is some hardware that you have and so on. So, increasingly what is happening is that you are being invited to do your system designing at a higher level of abstraction in a very programming kind of environment. And then the tools will take this program and give you the actual deployment of the system on hardware. And typically the hardware is becoming generic whether it is an FPGA or nowadays even the processors have become so powerful that you do not need to build specialized hardware, right. These new processors can do all that you want to do basically. So, our definition of embedded software now is it is software that is directly in contact with or significantly affected by the hardware it executes on, right or can directly influence the behavior of that hardware this kind of definition we are kind of reasonably comfortable with. So, it is software which is kind of married to hardware in some way and again, right it is useful to know as a part of the definition what embedded software is not, right. It is like Nethi Nethi in Hindu philosophy, right not this not that, right. So, it is not things like application software which is totally generic and which can be recompiled and executed on any number of hardware platforms, right, where your typical application software is defined by vertical market segments, right. Application domain like banking and retail and this and that, okay. Typical application software has well established methodologies and architectures around written things like that and their hardware platform independent typically and they are portable. You take your C code, run it on some other machine, you can run it on a sun or you can run it on a Windows C device or you know a Linux system or what have you, right. You just recompile the software so it is not any software which has no relationship with hardware, right. This is, it tries to flesh this out but again you know once you start getting deeper into this space the way embedded system software is moving is that it is trying to become independent of the hardware as time goes on, right. So even our definitions will have to keep evolving, right. So do not, so take all definitions that you encounter with a pinch of salt, right and exercise your own judgment as you go along. And the kind of challenges that we are working with, right in this hardware space, right is useful to review, right. So designers main tasks are converting from processor integration to performance analysis. Increasingly what you are having is higher and higher level tools where you can at a very high level of abstraction at your program level itself find out what the system is going to behave like. Like for instance you can do a simulation of once you deploy the system what is heat requirements will be and its power consumption will be. What are the hot spots on the circuit board which will develop, right. Which components of your system will heat up the boards and stuff like this. In fact you can have, once you have done your board level design and all that it will give you all the hot spots on the board. This gets extremely important when you have high bandwidth, high power applications like in radar processing, right and target identification. In say the missile systems, right where you have a very narrow kind of body, right and you have your boards populating the body inside, right. And you have some chips which are doing a very heavy processing job. Heat dissipation becomes a major problem, right. So there are all sorts of technologies with which you can actually draw out the heat and spread it and what they typically do is that they extract the heat and they absorb it onto the chassis of the artifact, you know a missile or what have you, right. And how do you draw out the heat, how do you ventilate this thing and lots of kind of detailed issues like that. And you have more and more simulation tools which at the program level itself can give you a fair amount of idea as to how this device will behave once it is built. I will give you another example. This is a more generic kind of a phenomenon which is not only restricted to embedded systems. The way an automobile company designs cars nowadays is another example, okay. There is more and more work going on at the modeling and simulation end of the design, right. For instance, if a car company Mahindra or Tatas or whatever are coming up with a car design, right, they take the initial design of the car like say of the body, right or the chassis or the engine or whatever and build a finite element model and they do a lot of simulation tests on the model itself. So you do not have to actually build the body to see what its crash, the characteristics and all that will be, right. The model itself will tell you how it will behave, right, which are the stress points in the body, where it might give way in certain kinds of crashes and things like this. And even an engine design, right, it will give you a lot of information of your engine which does not necessitate you actually building the engine to see how it will behave, right or your chassis or what have you and you can do noise vibration analysis which is extremely important for cars, right by just giving it the finite element model of your automobile and it does the analysis of what might be the sources of noise, right and what the harmonics of the various parts might be and things like that which has caused a tremendous improvement in the time to market, okay. So the concentration on architectural exploration and performance analysis has become paramount nowadays that you should do as much as possible in the, right in the beginning in the design phase of your building of the system. So essentially what this boils down to is early validation of your system and solution correctness, right before you actually go to hardware because hardware is a bit more expensive place to do all this testing, right and parallel hardware and software development where you have teams where you do not do it sequentially where first you build the software then you build the hardware or first you build the hardware and then okay fine build the software for it these things are actually happening in parallel nowadays. So you need increasingly tools which can help these two teams keep in sync, okay more effective use of previous work, right companies like L&T, right and others are increasingly reusing their work, right by using proper software engineering technology and skills and things like that and typically you can reuse up to about 10 to 15 percent ideally of work that you have done in the past. So each time you solve a problem you do not design the solution from scratch, right. So what this encourages you to do is things like the things that you do not like to do things like good documentation and you know clean and simple design and all these kind of things make your IP if you like reusable and when you can reuse IP others can also use it and you can actually reduce the amount of work that you have to do to build a system and this is increasingly happening in the embedded systems domain, okay and this 10 percent saving that you have due to reuse, right boils down to your bottom line basically 10 percent improvement in your margins straight away, okay and more efficient and fast working, okay. So faster ways to build new elements of a solution is a challenge and ways to test more effectively efficiently quickly and so on we will talk about this, right. So just a quick slide here where software guys can learn from hardware experts hardware guys have been reusing their designs for many many years, right because it is easier for them because their interfaces are much simpler than for software guys unfortunately because software guys can pass around very complex data structures and things like that defining interfaces becomes very difficult while hardware guys have been used to very simple interfaces, right it is called a wire, right. So connecting things up on a bus or on a wire is much easier than sort of generalizing the idea of a data structure of various kinds and things like that. So there has been a lot of reuse that the hardware guys have been doing in the past there are things like synchrony abstraction and event driven modeling which they do of actually simulating the circuits like with VHDL and things like that, reusability cell libraries, right the design of a chip, right many things can be reused, right multiplexers and flip flops and all these kind of things and even a higher level kind of modules like signal processing per subsystems and things like this and they have been able to get high amounts of reusability as a result of that, right. So what I will illustrate here, right is the design process which typically we can abstract about how an embedded system is typically built, okay. So what we say is that the first person comes up with an idea that this is the system that I want to build, right and then they devolve that idea into a number of components, right like in a mobile phone you will have your RF module, you will have your screen controlling module and you will have various other modules that you have here and you would put them down as a blob here basically, right F1, F2, F3, F4, F5 and all that these are the various functional modules that you identified in your system and you put it down like that and then you put arrows, right to indicate which modules talk to which one in this case and so on and you got some idea in your mind as to what is the bandwidth of communication which is required for each of these parts of communication and things like that, okay. Then here is a hardware it might be a given, it might not be a given, if it is not a given then you can design it the way you want, typically you are given the hardware. So in this case you have something like a generalized PC box, right it can be a PC on a board or what have you and you can have some specialized hardware which might be linked on a bus like that like so, right and these are your various hardware modules and these could be connected to each other in some ways. Your PC has got your hardware interface, it has got the real-time operating system and the drivers and all that here and these are the silos in which you can run your various process threads, okay. So now it is up to you to figure out how this kind of system can be planted onto this kind of hardware that you have been given, okay. So you will figure out that okay fine, I need some high-speed processing here, high-speed communication in this case, right between F1 and F3. So I could put that down here and slightly slower speed communication which I need could be on the PC itself, right. So you put it down here and you need direct very high-band with communication like two modules which are doing some video processing, right. You do not want to wait for the bus, you want to just dump it onto another processor fast. You might put it actually between these two hardware units here, okay. And then you would want to migrate the actual modules that you have, the processes which are actually doing the work to various other bits of the hardware like F3 would come to hardware, this specialized piece of hardware, F4 would come onto this specialized piece of hardware. F2 does not require that fast processing speeds and neither does F5 and anyway you have the communication here. So you can put F2 and F5 here, right which could be more say the control part of your system, right which does not need very, very high speed. If you have things like video processing and graphic processing and all that it will go on to the specialized hardware here, right. So that is how you start mapping the system onto your various hardware components and if you are lucky you will also have some simulation tools, right with which you can see how this entire system will perform before you actually dump it on the hardware or you just put it there and you start working with it and building up your system, okay. So here is a little slide which gives the difference between what is happening in today's embedded world versus the traditional embedded world. Traditional world never small enough, never fast enough, right character based, right many of you do not remember that also maybe but a few years ago, right most of the embedded systems would only talk in terms of characters, boot and run from ROM and low level programming model that means everybody from the past who talks about embedded systems, talks about assembly level programming, right very few people nowadays do that because it consumes too much time, right they use typically Java or C or various flavors of C to build the embedded systems and the application is tied to a particular piece of hardware. Now obviously it is never functional enough always connected, right high integration tip chips like A6 applications specific integrated circuits and systems on chip and things like that. There is an architectural diversity common of the shelf components and custom hardware working together you have EEPROM flash and rotating media which can work in your embedded system like the older iPods, right had hard disks inside it very compact hard disk. The newer ones obviously have a flash ram kind of technology in it, newer embedded world is software intensive, right lots of web interfaces here because they might all be connected on the web. In fact the new internet which you will see more and more in the future IPv6 is designed for high bandwidth communication between embedded devices, right so increasingly these things will be on the net and if you look at the kind of applications which are coming up very exciting applications, sensor networks, right where you have sensors which are on the network and kind of they are distributed and things like this these could very well be on the internet itself, right and fantastic applications like in telematics, right and agricultural applications, right. Telematics is a very exciting space in India, right where you can do so many things with it. Telematics is software which is related to vehicles which can guide them in various ways and things like that. You have lots of products on the market which are actually used by trucking companies and fleet management companies which monitor the trucks and vehicles their day to day traffic and stuff like this and more and more Java applications, okay. So something will be repeating again and again, right. What is driving the entire industry is this innocuous phrase called time to market, right. The time to market has come down from years in the past to things like months. Often the time to market pressures here are so high they are about three months or four months and things like that. In that time you have to conceptualize and push out an application and especially with things like in the mobile phone industry the times to market have become very small apart from designing of the phone itself to the applications on the phone, right. Like if you have a UFR cup which is happening now, right. Tech Mahindra has done has got a big contract from UFR to build the football download, the video downloading software applications on the phone in Europe, right. They can't say that okay fine I will take a year to do it because it is happening in three months time and they have to be out there fast. So these kind of pressures you have and this is a short way that there is a tremendous shortage as you know of embedded software engineers, right. If you just look at microelectronics engineers, right, which are the bedrock for building chips and highly advanced circuits and stuff like this. India is turning out about 225 of them every year and it is not growing at a very fast speed at the moment. You can't build an industry out of 225 microelectronics engineers a year, right. So the whole purpose of courses like this, right is to take a software guy sensitize him in the right way, right and deploy them in the embedded systems space. It is time for some vocabulary here, okay. So design metrics of embedded systems, right. Non-recurring engineering cost is very important. Non-recurring engineering cost is essentially the one-time cost which you incur when you choose a technology. Like for instance the non-recurring engineering cost of building a design on a chip, a system on a chip is extremely high because to just build the masks of a high-end chip nowadays costs almost a quarter of a million dollars, right. That means that if you want to deploy something as a chip, your startup costs before you even built one piece of the product is about almost a million dollars, right. So that might not be the best way to kind of actually build it and I will give some more idea of the thinking in this space, right. While if you just build it using an off the shelf processor your non-recurring engineering cost is nil, right. You just take it and build it. I will come to that. So, network cost is a common design metric, size in bytes and gates, right. Power, right. You want your battery to last, right, ok. Flexibility, the ability to change functionality. You have software radios now where you can change the hardware. You might have some reconfigurable hardware or processors inside your mobile phone which can go from GSM to 802.11 and stuff like this. There are many different protocols by remapping the protocol processing inside your phone and things like that. Time to prototype has become very important. Time to market has become most important, right, which is what is driving all this changes in this industry. Nobody has time to write assembly code now, right. They want to build at a very high level of abstraction. Maintainability, which means reuse, right. One poor sword is going to maintain your code after you have written it. So, you better sort of design it properly. Correctness has become important. Safety, right, the possibility that a system won't cause harm. So, here are some key ideas I will leave you with. One is time to market the design metric, right. You can look at the window of opportunity that you have in building an embedded system or deploying a product as it is actually a bell shaped opportunity where the demand rises slowly then fast and then peaks and then goes down like a new mobile phone or a new device of some kind or whatever, right. You can abstract it as a triangle, right. It rises then it drops where here you have W, here you have length 2W, okay. If you are on time, you will try and maximize your peak revenue and then your market fall and then you get here. And the area under this triangle where you have revenues on the Y axis and time on the X axis, the area under the triangle is your revenue that you got out of the market, right. If you delay your entry into the market, that means you come down with a delayed entry D here. You rise again at the same speed and then you fall at this speed, right. So as you can see the difference between the on time and delayed triangle areas is essentially opportunity loss, right. And because we are talking about an area, right. You lose on the square of the time that you delay your entry which is why time to market has become extremely important nowadays, okay. That is why the race that you saw between the Sony PlayStation and the Xbox deployment and things like that, just a delay of a few days could cause millions of dollars loss. Average time to market today is anything between 3 to 6 to 8 months really depending on the complexity of a product. And this is to answer the question about non-recurring engineering costs, right. You might have, you typically have the choice between three different technologies or more, right, depending on the product, right. So if you take this example where you have technology A where a non-recurring engineering cost is about $2,000 and unit cost here is $100, typically like if you just take an off the shelf processor and you use it, okay or you can use FPGAs which are non-recurring is 30,000 unit cost is 30, that means it is a little bit less than this. And technology C where non-recurring engineering cost like say you are building an ASIC or something like that is pretty high but your unit cost comes down dramatically. This is why the early releases of your CD-ROMs and DVD-ROMs and all that, your DVD devices are so expensive because they are using off the shelf components, right, where the costs are high. But once they can get a much larger volume in the market, they can build millions of these chips and the cost dramatically comes down because they integrate a lot of components onto one chip and the cost dramatically comes down. So it comes down from say $100 to $2. That is how the cost of these devices comes down from 20,000 rupees when it comes into the market to about 1000 rupees after about a couple of years or one year, okay. So what you are encouraged to consider is that whereas if you use technology A, right, your just its non-recurring cost is very low and it is constrained by the cost of the device. So your price in volumes will rise like that where your total amount spent, your total cost versus the number of units here, okay. If you use technology B, your initial non-recurring costs are higher but you have this kind of slope, right, it is less steep than this, okay. And your third technology like if you do ASIC fabrication, right, it starts at a very high non-recurring cost and then it stays flat. So what you typically want to do is that you would choose your technologies to minimize the area under this, right. So you would start off with deploying with off the shelf components, right. So you have suboptimal in terms of cost design. Then when you reach this point here you would take this technology and move with it, right. And when you reach these kind of volumes here, right, then you choose this other technology and go with it here, okay. Typically that is how you would want to deploy an embedded system design and this speaks in the same way. This is number of units. So this is per product cost against the number of units that you build, right. Again you would want to run along this path, right. You start per product cost, you start with technology A, then migrate to B, right to keep the cost down. And then in the long term you would switch to technology C when your numbers really increase, right. Yeah, in this you must also keep in mind your time to market. That is much more important than anything else, right. You might, your technology C, right could give you the right kind of results if you start out but it will require much more design cycles to get it right. Like for instance, I was consulting with one network chip company in Bangalore, right. They had deployed a very high end sonnet networking chipset and they found after some time there are some bugs which means that once it is deployed in the field, right. Under certain situations it kind of, it freezes up and the, and it is throughput drops and stuff like that. That is because of the design had some bugs. They pushed too fast into the market and it did not do enough verification and validation and just imagine you spend so much money and then what do you do, right. Once it is out there fossilized in silicon, right. Which is all the more reason why you need to be able to do a lot of verification and validation beforehand before you actually go into the deployment, right. This is, just gives you the working as to how you derive the formula for working out how much you lose by delayed entry in the market space. As you know Mohr's law says that your transistor capacity on your integrated circuit doubles every 18 months, right. And in 1981 leading edge chips had 10,000 transistors, 2002 150 million transistors, right. 2007 you have a billion transistors at least, right on your chip and this is using 19 nanometer technology and if you read the press you already reached 45 nanometer technology now, right. And what is happening is that the, as you make it smaller and smaller it consumes less and less power but the noise on the chip increases because the wires have become so slim that you have all sorts of interference and capacitive effects happening on the chip as you shrunk it down and then you have to do very sophisticated kind of means to kind of reduce the interference of signals and things like that. But that is very exciting what this means is that you are able to compress more and more power onto these new chips which will occupy less of a silicon footprint, take up less power and things like that, okay. And designer productivity has improved due to better tools, right. Synthesis tools, IP libraries which are available, test and verification tools, standards and so on, right. So one more aspect of this which you should read in a book called the mythical man month which is almost about 30 years old but extremely relevant even now by Fred Brooks who is an IBM engineer, right. If you put more designers onto a team your productivity drops, right. What happens is that more and more time is spent in communication between the designers and that reduces the productivity. Like for instance I will give you an example here. Say a designer has productivity of 5K transistors a month. Each extra designer means there is a decrease of 100 transistors a month productivity, right. So one designer is you take 1 million gates, right or 1 million transistors divided by 5000 you get in 200 months you will be able to do the job, 10 designers, right. So you reduce the productivity by 900, right. That 9 extra guys each one is 100 productivity less. So 1 million divided by this you take so many months, 25 designers will take this many months and here as you start increasing the number of designers you actually time taken to build the chip goes up rather than down, right. Moral of the story always work with small teams, right where your communication overheads are less. This is what happens in a large organization also the bigger it becomes the more inefficient and fat it becomes, right because most of the time is being spent in meetings, right to keep everybody going in the same direction, okay. So you need what this means is that you need new design technology to shrink the design gap that means that you need to program at a higher and higher level of abstraction. That means you have to write fewer lines of code if you like to deliver the result that you want, okay. So our new understanding is that we have simultaneous optimizations in an embedded system of competing design metrics of speed, size, power, cost, complexity and all these kind of things. So we need a new kind of engineer, right who is acquainted with a more holistic view of the design process. We call it a renaissance engineer, okay with a holistic view of the design process and comfortable with technologies ranging from hardware and software and formal methods and things like that increasingly, okay. And what is happening is that the maturation of behavioral synthesis tools and other tools has allowed us to have this kind of an approach to building a system. There are just two instances, right. There are other interesting tools like a language which we teach here called Estrel for building control systems or a tool called Polis which comes out of Berkeley, right where you can build the combined hardware and software as one project basically and you are free to migrate the boundary between hardware and software at any point, right. So you can say that please give me a system where you have this much hardware and this much software. So it will put this as a program and on a processor and the rest as say it builds an FPGA for it, right or you can say give me most of it in hardware and only this much in software and it kind of delivers you a system like that, right. So what is happening is that design efforts are focusing now at higher levels of abstraction, right. Where abstract specifications are just refined into programs and built into gates of logic. So there is much more automation of your design process. Like if you are writing VHDL code maybe you do not need to write VHDL code also you just program at a much more abstract level. In fact one more example of this is the way you see a control system designer building say a control system in the past he do it through a program and assembly code and stuff like that. Today you would use MATLAB or SyLab and is not it wonderful that you do not have to write a piece of code, right. A control system designer does not have to depend on electronics engineers he does not have to depend on programmers and all that. He conceptualizes his control system and does it through the simulink visual interface on the computer gets and checks that all the properties that it conforms to are correct, right. Then he presses a button, right and it gives him a program which can run on a given processor, right. Or it gives him VHDL code through which he can reconfigure hardware and FPGN and things like this. So this is increasingly where embedded system design is going today, right. So there is no time to put in place all the paraphernalia of you know taking this design tossing it over the fence to someone who is a programmer, right because I cannot program so he will program, right. So he is programming and then after that he takes it and tosses it over the fence to a guy who is doing the hardware design and stuff like that. It is not happening like this anymore, right. So we are actually building at a high level of abstraction a design in an application specific design language if you like, like MATLAB or simulink or what have you, right. And then you press a button it gives you a system. So most of your energy is spent in actually solving the problem rather than doing all the Ghodagiri which is involved with building an embedded system. And increasingly as you go in the space you will realize that there is very little difference between what hardware can do and what software can do, right. Traditionally there used to be this divide because hardware was not very powerful in the old days. So you are forced to write in assembly or build specialized hardware.