Enabling the chip technologies of tomorrow – how Python helps us

Speaker 1 [00:03]

Thank you very much. So I'm working in the semiconductor industry, and I would like to talk about what we are doing with the chips today and how the technology is evolving for the chips of tomorrow or next year maybe. And since this is a Python conference, I will also talk about how we are using Python in our company to enable these steps. So, a quick overview of me. I'm a physicist, I'm hired as a system engineer, but I do at least partly software development. I'm also active in the open source community. I'm in the core development team of Tech Studio, which is a LaTeX editor, and also Matplotlib. And I've contributed to many other projects, which I really can recommend, even if these are just small contributions, just go there. If you find something, even if it's just an error message which is maybe not clear, just send a pull request to the project. They are very happy about that. So, about my company, Zeiss is an optics company, and you may know it maybe from lenses, or you may know it from microscopes, but we also have a business group which is active in the semiconductor industry, and you may not know this because we're just selling to business partners, but probably everybody of you has a device which is created with our technology. And we have about 2,900 employees in our business group, and of them, approximately a thousand our researchers and developers because to get the high-end technologies of tomorrow is really not that easy. So we do a lot of work to get that. You all know Moore's Law, which essentially states that the number of transistors on a computer chip doubles every two years. and it's been quite successful in the prediction. It's going on for over 50 years now. But actually, one has to say it's not really a prediction. It's a self-fulfilling law. Because to enable that, the semiconductor industry really decides on a roadmap which is oriented at that. So this is not by chance. This is because people are saying, we want to do that. And we put a lot of effort in there to get there. And to maybe illustrate what that really means, I mean, we're doubling every two years the number of transistors. Essentially, we're shrinking the size of the chips because the chips are not getting larger. So if you want to get more transistors on the chips, you have to make the transistors smaller. And just to give you an idea what that means in practice, I'd like to compare the computing power which we can carry around now to some supercomputers from earlier times. So we can all now carry around a supercomputer from 25 years ago in our pocket and operate it just with a battery. And to be able to do this, we have to produce the computer chips. And I will give you a quick introduction how that's actually happening. So how the chip manufacturers like Intel, Samsung, TSMC are making a computer chip. So you start with a silicon crystal. You cut it in slices, which is called a wafer. they are now 30 centimeters in diameter, you apply a photoresist, and then you make an image of the structures which you want to have on your chip. So the circuits you want to have, you project that image on this photoresist. This means it's developed in certain areas where there's light, and in other areas where there's no light, it's not developed. and then you do some chemical processing to remove selectively just the areas where there was light or where there was no light and then you remove the resist and you have a structure on your chip. And since these structures can be quite complex and also since you have layers for a single, let's say logics chip, at the moment you do this 40 to 60 times and in the end you have a chip on your waiver, you cut it, you package it and then you can sell it. And really the key part to make these chips more efficient and put more transistors on the chips is this imaging part. So you have to to make really, really precise images of tiny structures on that chip. And that is what we are essentially doing in our company. This is called photorelectrography, and I will just show you a quick video to get maybe a better idea what that involves. There's some sound.

Speaker 2 [06:08]

whereby the chip structures are transferred from a photo mask onto a wafer through optical imaging. The SAIS Semiconductor Manufacturing Technology segment delivers the optical components and modules needed for exposure. These are integrated into the wafer scanners produced by strategic partner ASML. lithography systems use light with a wavelength of 193 nanometers extreme ultraviolet light has a wavelength that's 15 times smaller and enables even smaller chip structures we are making this technological leap possible through EU the optics which are made up of mirrors instead of lenses Exceptional precision and cleanliness are essential when it comes to producing these increasingly complex objects.

Speaker 1 [07:11]

The extreme required.

Speaker 2 [07:16]

were as big as Germany the biggest unevenness would be smaller than half a millimeter to guarantee the precision of the optics in the sub nanometer range highly accurate measuring technology is consistently used to check their quality another big challenge is EUV lithography EUV light is absorbed by the air which is why the optics are qualified in a vacuum their subsequent integration occurs in a clean room where absolute cleanliness is essential in contrast to

Speaker 1 [07:58]

leader of air.

Speaker 2 [08:10]

are thus among the cleanest places in all of Germany. What's more, we develop photo mask and process control solutions that optimize key stages of microchip production. Chip manufacturers across the globe use our products and solutions. The bulk of all microchips and thus all electronic end devices contain our technologies. Our EUV systems make it possible to produce smaller chip structures than ever before. They are just 20 nanometers wide and as such, 4,000 times thinner than a human hair.

Speaker 1 [08:53]

Okay, so much for the advertisement, but I hope this gives a sort of an impression of what it involves to make these chips. So, as we've seen in the video, this is a current system, a lithography scanner, which you will find in the current stage productions. and to get even smaller sizes we have to switch from the wavelength 192 nanometers to 13 and a half nanometers, which is this so-called extreme ultraviolet lithography. And to do that, if you want to make smaller structures, of course you build larger machines. and not only are the machines larger they are really much more complex because we've heard this extreme ultraviolet light is absorbed by everything so we don't have lenses anymore we have mirrors and also because it's absorbed by air you have to put everything in a vacuum so these machines are really getting more and more complex and how can we develop such a machine? Well, essentially, we just have to do it right, because we cannot afford to build any prototypes. If you want to build a prototype, you would essentially have to build a whole factory for the machines, which means you have to build dedicated measurement equipment, dedicated fabrication equipment, which is just there for this specific type of machine. And if you want to build a prototype and then change something, you would have to change all your equipment. So that's not feasible. Second reason is to build this equipment and a prototype that would take several years. So this is not an iteration loop you can take when you design a new machine. So what we really have to do is we have to simulate everything. We have to simulate the whole machine with all possible influences, and just to give you an idea, there are thousands of effects you really have to take care of and be sure to include them in the right way. For example, you have to know that the Earth is not round. Well, approximately it is, but not perfectly, and that means that the gravitation here And the gravitation in Eastern Asia is not exactly the same. And therefore, if you have a mirror, which is just mounted on some hold, it will slightly bend. And due to the different gravitation, it will bend differently in Eastern Asia. So you have to take care of that because you want to optimize the machines for the places where they are operating later on. And that means we really have to have a lot of simulations, mechanical simulations, optical simulations, material simulations. And this is a place where Python really can help us because we have to do a lot of optimization. We have to work a lot with data. And that's actually what I'm doing. So now we're getting more to the Python side of the talk. I'm working in a system design projection department and essentially it's our task to make sure that a new product that we are developing is working afterwards without having any prototypes. So we are doing a lot of simulations, we are doing a lot of analysis, and this is done essentially by technical experts. So these are mathematicians, these are physicists, but currently we don't have any software engineers. Still, we do a lot of programming, we do a lot of simulations, and you have to make sure that that works. And I will tell you a bit about that now, how we organize ourselves so that we can do that. so we write our own software we don't give the task of writing a simulation or writing core libraries for our task to some external place for a number of reasons first, most of the things we are doing they are really deeply involved to the technical details so communicating these technical details to some external parties is either not possible or allowed, or even if it's company internal, you have to make sure that the people who design then the programs, they really understand what's the important parts of this. So we need a lot of domain expertise in the software we are building. The second part is we have quite complex systems and processes, and we really need the software to do abstractions so that we can think of the system in different layers so that we can do automizations and do calculations without having to do everything manually. And the third aspect is, well, I said we have to do everything right the first time. That's true when we start actually building a physical machine. But before that, in the development process, of course, there are a lot of changes in the design and a lot of new ideas coming in, ideas about new technologies, ideas about new methods, and you quite quickly have to adapt to them. You have to evaluate, is this something we want to pursue further? So we have to adapt our code quickly, and that means sometimes within a day or so to be able to do new things. And this all is the reason that we are writing our own software. And historically, if you go like 15 years back, much back before I joined the company, well, actually everybody was doing their own thing. So there were people using C, there were people using Perl, there were people using MATLAB, there were people using Excel. and everybody just did their own analysis and there was a lot of duplication and the results from one person were not comparable with another person. So that's not a way you can work. And then at some point we decided we need a common software base. At that time, still more than 10 years ago, that was Perl. But approximately 10 years ago, then we switched to Python as a common code standard. So we are now using a lot of Python, in particular the scientific libraries, but I mean, that's just some examples. And on top of that, we have a lot of our own code. So we have around 60 specialized libraries for simulations and related stuff. And on top of that, still some user-friendly tools. And of course, it's not all Python. For example, the core simulations are not run in Python. They are run in other specialized simulation software, but we can interface this software with Python. And that really helps. There's also some other code relics, but you will know that's always the case. Okay, so now we have a common software landscape. We have decided we all use Python, but still that doesn't mean we all work together in the same way using the language. We still had at that time the problem that there were some duplicate developments that some people didn't know about things other people did, And if you're on that scale of, let's say, 70 people, that's something really you have to take care about. And therefore, we decided to establish a so-called software council, which is a group of people who are responsible within the department to organize the software landscape. That means these are usually the people who have the most experience with software development. We try to collect what other people in our department are doing. We actively give back knowledge to all of the people. So, for example, we do trainings. And one really important part, these people are a point of contact for questions. So if you have any programming questions, you can come to us and we have dedicated time reserved for that so it's not something running on the site but there's a small but dedicated amount of time we got just to have the ability to help colleagues do that and that's really something important. And then we do also other things, so we decide how we want to develop software, we give out some rules and best practices, We support the developers in that aspect and also we think about what do we need in the future? What technical skills do we need? What kind of programs do we need? And we initialize that we plan to build these tools or gather knowledge in that field. So, this is still sort of a collaborative working, and since it's like that, we adopt a lot of mythology from the open source community. So, what did we learn from there? Of course, we use the established tools like version control, like testing. We also do documentation. exactly in the same way as the community does it. We also have implemented roles, not as positions, but as logical rules that you have a maintainer, you have a developer, and you have a user, and these different roles, we take them into account when we, for example, develop some new library. We think about what would the user want, what does the developer need, and also who will take care of the code. So it's really important to have a maintainer. If you have a lot of tools in your toolbox, make sure there's always someone responsible for each tool. And that also means if someone is leaving the company or leaving the department, find someone new to take that responsibility. That doesn't have to be, or in our case, that doesn't really have to be a very good programmer, but it should be someone who knows the tool, who can help people working with this tool and who, if he cannot fix something himself because he maybe is not that experienced a programmer, who can at least organize that someone else can fix or extend that if you need that. So what we also use from the Python ecosystem but not in exactly the same way We have a software environment, and for that, we want to have everybody to use the same environment, the same libraries, the same versions. And currently, we are basically doing this by using the distribution mechanisms of our Linux distribution. and additionally we are setting a global Python path which is accessible from every computer which has some additional libraries which we didn't distribute via the distribution. It's still possible to have a virtual env or a conda env as a developer if you want to but really it's not recommended to do that too much because then you end up with a lot of different versions and we really try to keep the environment consistent for everybody. We are still also looking for other ways to do that. And a small remark, if you are using PIP behind a proxy, that's always a bit of a problem. We are solving that with a small shell script, which temporarily sets the HTTP proxy variable, including the password, which is at that time of execution plain text, but it's removed directly afterwards. So it just stays in the memory for the time of the execution of the script. And with that, we can go through a proxy, which still needs some authentication information. We use a documentation server, which is basically custom built. So we dump all our documentation in a certain place. There's an Nginx server with a really simple handwritten overview page, and we have a small script that allows a full text search so that the information about all the tools is available to the users in our department. And we don't use a package repository in the sense like we have a PyPy because we are directly installing the tools from our Git repositories into the production systems. So we are at the moment not using any separate packaging instances. But what we do instead, we list the available software in our wiki, and essentially that's just a small script which runs automatically, looks what's there, and generates a page in the wiki. And to be able to do that, every file should have a really small header for that. We really want to just insert the necessary information, which is who has written it, who is responsible for maintaining it, so who do I have to go to if I have a problem, where can I find the original code in the repository if I want to see if something's changed or something like that, and where's the documentation? And then you use a regular Python doc string to give a short description, and this information is extracted and put automatically on the wiki, so we have a nice overview of the state of our software. So a small example use case. We also use a lot of production data because it's really valuable not to simulate your systems in isolation, but use the production data from former systems to get a more clear view how your simulations or the changes you want to do to the systems actually turn out. And for that, we have a server which automatically can process this data, store this data in a structured way, and we can retrieve that. So I can say, for example, for this product, I take the data, and I say what would happen if we had done a different manufacturing process on that product, and I can simulate that, and I can compare the result of the simulation with our product, what we have, and I can say, okay, that was an improvement, or, well, that's making it a bit better, but it's really not worth it. So, this is also really valuable, and this is also Python-powered, so this is a Django server, and the automation, the automatic data analysis in the background is also based on Python. Okay, so to transfer the knowledge from the more experienced people in the team to newcomers or to the broad part of the team, you have to really do something because the knowledge just doesn't appear by itself. So we are having currently a training program specifically for data analysis. We have something called Python Nuts, which is just tiny, short, five-minute infos, which you can take to your weekly meetings and say, okay, and here's something I want to tell you about Python. And that's really getting knowledge to the people. And as I said earlier, we have contact persons with dedicated time for support. You also have to acknowledge that not everybody wants to be a programmer or is not interested. They may just want to get their stuff done and they don't really care if you say use Python 2.7, use Python 3 something, use this library and object-oriented programming is good for something. They don't really care and don't do it there. They don't really care. They just want to do their stuff. And you have to acknowledge that and not give them too much details. On the other hand, there are people who are really interested in programming, and you should try and use that and train these people further. You don't need everybody to be an expert programmer in such a team, but at least you need some people who have the knowledge, because if you're building larger structures and you don't have that and we have that also before. Unexperienced people tend not to design a library that well that it's maintainable or easy usable in the long term. And we have something called programming tandem which is sort of unequal pair programming so you take someone with more experience and someone with less experience and the person with less experience has the main job of doing things, but there's a close interaction between these two so that you can transfer the knowledge. And also, it's important that you go to the people and find out what they want to do and how they do that. Because with physicists and mathematicians, they are really creative in doing things in bad ways, and they are amazingly self-sufficient with that. So they can do really complicated stuff, and they say, okay, that works for me. And you say, but it just looks so complicated. Just do it that way, and that's much easier. So you really have to look at what the people are doing and what they want to achieve, and then you can give them the right tools. And the last topic. Unfortunately, not everybody is using Python in our company. We are sort of in a happy place there in our department, but you have to accept that there are other people and you just have to work with that. Luckily, with Python, that's quite easy. So Python can adapt to almost everything. You can interface to MATLAB and we're using that. We're pushing code into MATLAB, taking MATLAB functions, throwing them into Python, interfacing with other libraries, going to databases. This is all not a problem. The only important thing is if you work together with other people who are not using Python, define your interfaces. Make sure you have a consistent format how you exchange your data, because then you can work with your Python tooling on that data. If someone wants to send you MATLAB files, that's fine if they are always in the same format. I can just write a parser and use them every time. If they mess up the data and it's always different, then you have a problem. So you have to define your interfaces. And then you can happily work with everybody else together. And also, So if you want to spread Python, don't try to do it over eagerly. I have learned the best thing to do is just convince with your results, convince with what you can do. And also, if people are interested in using Python, offer them some support, some training, some help, maybe even some code, which they can reuse from you. but don't try to evangelize everybody. Some people are perfectly fine using other tools as well. Okay, so to sum up, I hope I could tell you a bit how you can also use Python in a non-programming background. But of course, to do that, you really have to make sure you create the right environment for the people. And if you want to help us with that, we are also hiring. You can talk to me outside later on. And one final word. I'm sure everybody of you uses hardware that's produced with our lithography optics. And every of these optics is optimized with Python. Thank you.