Good morning, good afternoon, good evening. Wherever you're hailing from, welcome back to another KBE Insider show. I am Chris Short, host of the most of this thing we call Red Hat Live Streaming. I'm joined by a special guest host today, Steve Spiker, as well as our special guest, Maček Šulek. But, you know, and Maček is a great contributor to the community. I lost the page with all his descriptions, all of a sudden, the tabs, which are Rooney, hang on. He, we're going to talk to Maček today about, you know, being a software engineer at Red Hat, obviously, but also about what it's like being a double SIG lead in his work on the Kubernetes CLI and controllers. But first, the news. Mina, take it away. Welcome back, by the way. Thank you. Hi, good morning, everyone. Gonna talk about some highlights here as I do on all episodes, except I guess Gordon did a really, really good job last, last month, so I do have a hard part to uphold. But security has been a big issue, I think, with Kubernetes in the last couple of months. And one of the, a couple of the articles that I want to highlight, there's a new tool that wants to save open source from supply chain attacks. SIG Store will make a code signing free and easy for software developers, providing an important first line of defense. This is, I think, a really, really good first step in, you know, defending those attacks. And then there's a NSACISA Kubernetes hardening guidance, which also identifies the common areas of Kubernetes security risks, as supply chain malicious actors and insider threats. It aims to educate engineers to avoid common misconfiguration issues and safeguard applications. The guidance suggests that supply chain risks are hard to mitigate and can emerge in the container building cycle or infrastructure provisioning, especially in cloud environments. And then we have Helga Labas coming in, talking about how to secure Kubernetes as it becomes mainstream. This is actually an interview with the CEO of ARMA who talks about security and Kubernetes systems, what makes them susceptible to cyber attacks and what should organizations expect when deploying them. He answers, you know, attackers are looking for targets and how do they choose their targets by a combination of key parameters, the value of the target and how easy it is to attack it. So after talking about this stuff, obviously we need to have a way of knowing if our Kubernetes network security strategy is solid. And then I think there are four critical questions that must be asked to understand where these vulnerabilities persist and where steps need to be taken to ensure adequate protection within your container network. So before you decide anything, ask these five questions to yourself. Does your network inspection achieve complete visibility? What isn't protected by your security deployment or service mesh? What are the limitations of your existing web application firewall protection? Are you addressing security drift and how fast can your Kubernetes security mitigate threats? Again, very, very important theme in the world of Kubernetes now, I will drop in the links for these specific opinion pieces and news articles that I've addressed right now. And then going in, what are the main drivers and challenges of container technology today? Obviously security being one of the main challenges that are related to the application container technology, they limit its adoption. There's a lack of internal alignment and experience in Kubernetes management that are also named among the key barriers to adoption. Main drivers are increasing number of enterprises are opting in for the powerful deployment options and visibility over complex deployments, efficient distribution of workload across clusters resources and accelerated software delivery powered by Kubernetes. But despite the challenges, the idea of a simplified and automated service delivery continues to drive the deployment of Kubernetes across the world. Then we wanna highlight the five DevSecOps open source projects. Again, you can go in and look at this article to learn more about these projects, but teams that embrace the DevSecOps approach make security an integral part of the entire application life cycle and these specific open source projects aim to help that. Claire, six-door, KubeLinter, open policy agent and gatekeeper and Falco. So I will again drop all of these links into the chat. Feel free to go and check those out. Come back to Kubernetes KBE news page every week. We have great articles coming up today as well.  Thank you, Meena. Awesome. And yes, security has been a huge issue lately. Machek, take it easy, Meena. Machek, who is your daddy and what do you do? That will depend on the context and everything around it, but I think we can figure it out eventually over the course of the rest of the meeting. So your software engineer here at Red Hat, co-lead of two SIGs, sounds like you're like me. You wear many hats at Red Hat. And that has to be an interesting challenge. It is. Let's start that. I was at 6CLI lead for almost four years now. And I said was because last week I officially stepped down from the 6CLI chair role.  So theoretically, all of us are wearing both hats, but over time when we wanna appreciate someone else or I will be slowly stepping down, but I wanna help with the technical side of things. I'm giving away the organizational hat and we'll take care of the technical stuff, especially that I have a lot of knowledge that most importantly, historical knowledge and decision that we did over the past years. And I know that the other chairs and tech leads were asking me to be around to help them because that historical knowledge is sometimes helpful. For resolving conflicts and situations, which are basically on a daily basis. So that's that. Yeah, the context, why we did this this way or the other way in the past. Have we tried to look into this or something else? And yes, we usually have, but the decision from the past was that because there are those other stuff that might interact, we have to make this hard decision of doing this or differently. So this definitely saves a lot of time when I can look it up in my head somehow. I don't know how I managed to keep a hold of this many information, but somehow I do. But I think it has to be like... So how many people? Yeah, go. Yeah, how many people are you usually interacting with in the 6 July kind of like? 6 July varies, but I think it'll be somewhere between 10 and 20 people that are constantly on our... Well, currently we have this many meetings that we are meeting every week because the official 6 July meeting is every other week and that's in the other weeks we are doing box crops and just recently Katrina started doing customized box crops. So no matter what's Wednesday, there's usually a 6 July meeting, whether that'll be box crop or customized crop or a regular meeting, it's all in the calendar. So you should be good. Good one. On top of that, you also do work in SIG apps too. So as part of your community participation. Right, so I was part of the SIG apps basically since the initial days when I started working on Cube because my initials to my original story with Kubernetes started with jobs. Well, at the time it was called actually schedule a job. So that was the idea of adding something like Krons in Linux if you're familiar with Linux systems, you know that there's an ability to schedule some task at any given point in time. Initially that was called schedule a jobs over time. It was renamed to Kron jobs. And that was the original idea. During the initial discussions, we divided that into jobs and Kron jobs. So this is how we, how my story, I think that was around 2016 or 2017. Very early on. Yeah, that was very early on in barely a couple months after I joined Red Hat if I remember correctly. But since then I was jumping the train in a couple of places. And if you look at my contributions and I don't know what I was doing, but I was looking for something and I was looking for what I did, what I touched, I touched very different places in the Cube ecosystem. And even though I'm on a daily basis, the team that I'm leading at Red Hat is overlooking both 60 line SIG apps and also SIG scheduling. But thankfully I have amazing folks working with me that are handling the SIG scheduling. I don't have to do it because my mind would blow what I would have to look at the third SIG. But even still I'm also participating in SIG API machinery and trying to look into what they are cooking, both from SIG apps perspective because controllers are interacting with API one way or the other. A lot of primitives that SIG API machinery is working on is being used heavily in both SIG apps and SIG CLI. So it's somehow natural to me to also follow along with those folks. Interesting. So hello out there, everybody in the audience. Just wanted to make sure we get a hello in. I was just going to jump in. You mentioned like you're starting the Kubernetes and it sounds like part of it was your role in Red Hat. I don't know if you can talk a little bit more about how that kind of started. Well, that was an interesting turn of events. I was basically invited to a conference that was happening in Southern Poland pretty close by where I was living in a very small city nearby. And a friend of mine asked me, oh, there's an open source days happening in Bielskowiowa that was like seven years ago in March, if I remember correctly. And I was like, oh yeah, I promised to go with you on a conference a couple of months before but I couldn't make it, so oh yeah, I'll join. Also, that was a time when I was a couple months after switching my previous previous job to the current one at the time. And I was like very disappointed by the pick that I did. Like literally after a week of working there, I was like, yeah, that's not the place that I want to be in. Been there before that. Well, happens. And I went to the open source days and I've met my wonderful friends and co-workers until today, Zierka Folta, who's currently in charge of HR in Czech Republic, and Mihał Wojtek and Mihał is staff engineer in OpenShift until this day. And he was my team lead for a very, very long time. And I consider him and my friend. So, and we started chatting and it was like, oh, it would be so cool to be able to work with you. There was one little at the time is that OpenShift back then, that was seven years ago, was at the version two that was written in Ruby. And I'm being Pythonista. I was like, yeah, that's not my game. So I applied for two positions actually. One was for OpenStack and other one was for OpenShift. And because of being and having my heart with Python, I cared more about the OpenStack role more than the OpenShift. It turns out that I didn't get the OpenStack because I was missing some proper virtual machine knowledge, but I got the OpenShift role. Soon after OpenShift started working on V3 and we switched from Ruby to Go. And I was like, oh yeah, that's fine because I worked with Java before I worked with C. So switching from Ruby over to Go was pretty exciting for me actually. And that's how I landed over at Red Hat. I did touch the Ruby codes for quite a while. I think I was one of the last person that was still maintaining V2. I think folks that were joining Red Hat after me did not maintain the V2 already because they were already jumping into V3 and Go-based solution. So it was exciting. OpenShift that happened out, worked out for you. I mean, worked out for the team overall. So that's great to hear. The one thing that I think is an interesting story of hearing folks like you work upstream so much in the community is that there's a lot of pieces there that are kind of hard to pull together. But at the same time, you're managing delivering a one called downstream but a thing that's taking those bits from the upstream and then downstream China product as I'm dealing with the past releases. So you're working with many versions of CUBE or CUBE CTL, whatever you want to call it, right? And you have to deal with those challenges. So I'd be kind of interested to hear your story there what that's like dealing with not only the community parts but now you're kind of in some ways going back and porting forward like all the different challenges or ways of working day to day. Okay, so before I jump into that one, let me straight up one thing about the CUBE Cuttle, CUBE CTL, whichever. I'm going to use both interchangeably. Love it. Although a couple of years back, if you are familiar, CUBE Cuttle has a logo. And we struggled with it and talking with Phil and Sean at the time who were leading six CLI, well, are still on to today. We figure out that maybe something like Cuttle Fish for CUBE Cuttle, which is cuddling the CUBE logo. So if you haven't checked the logo, if you go to Kubernetes CUBE Cuttle on GitHub, you'll see our logo proudly presented on the front page. But both names, even though we went with the Cuttle, both names are perfectly okay. And I've seen lots of questions, debites. And it's actually something that we are being asked almost every single time when we're talking about six CLI during CUBE Cons. For the past three, four years, I would say. And now going back to your original question, I must admit that the fact that CUBE decided to switch from four to three releases a year was a significant improvement from my point of view because if you're thinking about just CUBE, you're thinking about past four releases, currently three releases. But for me, as you said, that means double the digit. So it was eight releases a year or six releases currently. Because for me, my life cycle looks like this. I'm done with, let's say Kubernetes 122, which was released a couple of weeks back. And I'm jumping immediately into OpenShift 4.9. Which will be, which is based on Kubernetes 122. And that will be released in a short while. And then immediately I need to jump on the track and start working on 123 already. And we will be slowly preparing for another version of OpenShift. So we're constantly between feature freeze and literally chasing every single date, whether that's CUBE feature freeze or OpenShift feature freeze, whether that's CUBE code freeze or OpenShift code freeze. And jumping with those dates is challenging at times. And it sometimes is overwhelming. But thankfully I have an amazing team, both AppStream and SIG CLI, as well as SIG apps. That does a lot of the work and can help me with pretty much delivering any single feature, whether that's downstream or upstream. So backing up a little bit further, when did you get your starting like open source? How did you discover open source software in general? Yeah, so with open source, the story goes back to Python and all the way back to my university years, like 20 years ago or something along those lines. I took a class on Python and I was like, yeah, well, man, not sure if that's something for me. A couple of months went by and I had an internship and during the internship, I got to work with Python heavily. And that's where I fell in love with Python. And over the years, I figured out, well, the community here with specifically the Python community was providing with this amazing tool for free. So I figured out that I wanna give back something. And my initial contributions were to Python itself. I think I did a couple of PRs to Python itself, specifically IMAP and SMTP libraries. Over time, I also helped with BoxPythonOrc, which is the buck tracker for Python. And that's, I think that that was the initial story where I started with open source. I was doing as much as I could in my free time. And I'm trying still to be active in the Python, although live work and everything else is not always in line with my willingness to work on Python stuff. It's interesting, you said that you get to play much with Python in these days or it's in a while? I wouldn't say that I don't have a time. Every single time I'm working on something simple that I wanna scrape data or somehow analyze the data, I'm gonna reach out for Python every single time that I'm doing something like that. Over the past years, whenever I was preparing some kind of a demo for OpenShift, or presenting some ideas, I was always preparing an application and that application always reused Python under the covers just because I wanted to give it a try. In the past, in the early days when we started shipping V3, I was also involved in Source to Image, which is the build technology for OpenShift. And I was the primary owner for the Python builder. I kick off that one. So I've always tried to use whatever I built and make sure that the experience that I'm feeling is actually legit and whether I should improve something and make it better or whether the UX simply to say is reasonable for a regular user. Source to Image. I think fondly called S2I. I'm dropping a link to that in the chat. If you're not familiar with it, folks. Yeah, the one thing I wanna know if you wanna maybe jump back into kind of what's happening in the CLI space around Kubernetes and SIG CLI. I don't know if you wanna spend a little time about talking about the plugin model, like exploration around crew and then kind of integration with Customize and any plugin ecosystem, kind of throwing a broad statement there as sort of like CLI topics. So kind of curious. Right, so SIG CLI itself, we have actually three main sub-projects that we are overlooking. You didn't mention Customize. And I also mentioned earlier today that we are doing box crops and one box crop is actually tomorrow. It's around 6 p.m. Central European time and it's around noon Eastern time, 9 a.m. Pacific. We'll be going through Customize box. We have a very talented group of people who is working on Customize and pushing this forward, listening to what the customers and users want to have added. There are cases where we are trying to simplify a lot of stuff for Customize because it was a problem for some time where Customize moved forward. And before that, we decided that we wanna ship KubeCTL with Customize embedded. And the fact that Customize went so far and with features and capabilities, we were left in KubeCTL with pretty old Customize. And the dependencies unfortunately made the problem even harder for us to upgrade. So we had to refactor a little bit of Customize to be able to update the version. And Jeff did an amazing job here and worked tirelessly to bring the necessary changes into Customize and then update the Customize in KubeCTL. So that's on that end. The next project crew and the entire plugin model. So that was basically in line with what the majority of Kube was doing. So Kube decided that the core would be pretty much closed and we would open up a lot of places how we can inject or add additional capabilities. KubeCuttle wasn't different. We looked at other tools, namely Git and other binaries, how they implement their own plugin models. And we came up with the current plugin implementation that your plugin, it just have to have a prefix as KubeCTL and that will make it a plugin to KubeCuttle. Out of that, Ahmed and friends figure out that it will be nice to have something to manage the plugins for KubeCuttle. That's how the crew started it thing. And it's pretty popular and we're very happy to have crew on board. And lastly, which is a pretty new addition to the 6CLI sub project is Kui. It's a project initially started by IBM and driven by Nick especially, which is a Kui approach to kind of like a wrapper to KubeCTL. It has a much richer capabilities of presenting the output of the KubeCuttle commands. So it's like a combination. It's not like a web console, but it's definitely a much richer KubeCuttle wrapper than if you would use a normal KubeCuttle. It has a live preview of, let's say, if you start watching pods and it allows a little bit more freedom around sorting and formatting the output of the KubeCuttle commands. So there are pretty interesting stuff. And lastly, because you did mention the plugins, during the work that we did on plugins, we extracted a library called CLI Runtimes and that exists on GitHub, other Kubernetes, where we are providing authors of the plugins with a lot of the primitives for printing data, for reading configuration, et cetera, so that you don't, first of all, you can be, your output, your way of doing stuff is similar to what a KubeCuttle does by default, but it also deals a lot of the stuff for you, so you don't have to write anything from scratch when you wanna, I don't know, parse KubeConfig, for example. Do you have a, is there a place listing kind of common or popular plugins that exist? I mean, I'm on the crew website right now. There's 154 plugins. I think there was, or I remember. Ork function, but. Okay, you can. If you have your own number of stars, I'll drop it in the chat. I guess you have any favorite or one you use often or one you wanna plug? My favorite, I would probably call out to Debug which was, which originally started as a plugin, but we're currently in a process of pulling Debug into the, as a default command in KubeCuttle. It's, it's rather lengthy process.  If you're in a core, the process is you just, you basically have to follow what Kube does, but on the other hand, what is something that we've been working for, I would probably say three years, maybe even four years is we're trying to simplify the KubeCuttle code so that we can move the entire KubeCuttle code to a separate repository. Even though that if you will start, if you check out GitHub, you'll notice that Kubernetes slash KubeCTL exists as a separate repository. It's actually not a repository where the entire development is happening on a daily basis. Kubernetes has a notion of staging repos. So if you look under main Kubernetes, Kubernetes repository, there's a staging directory. And if you drill down, you'll notice that there's a KubeCuttle directory. That means we are publishing the contents of that directory into a separate repo. The goal for that was that we can and we ensure that the libraries that are used within the staging repo are not using any of the dependencies from the main Kubernetes, Kubernetes repo. And that eventually we will be publishing from entirely new repo. We're currently discussing how to do it because it's a lot of challenges are still ahead of us for how to release. Because if you look at how Kube currently releases, it is basically publishing all of the artifacts from a single repo. I was talking with Sig release, I think that was last week or two weeks ago about us wanting to publish KubeCuttle code or basically KubeCuttle artifacts from a separate repo. It will take a little bit of time still, but we're hoping that within a couple of next releases to three maybe we will be able to publish from a separate repo. As soon as we reached that point where we have a separate repo, we will return to the discussion of maybe shipping KubeCuttle faster than Kube itself is. Because that was one of the goal. If we move to separate repo, we will try eventually cut the court for releasing. Obviously there are some challenges coming from that because currently we are required to support plus minus one version, which is a default policy for all of Kube. If we start, for example, publishing KubeCuttle every month, that means we need to make sure that the support matrix is not plus minus one, but we will be supporting about four or five releases back and forth. So there's a lot of, maybe not necessarily code changes required, but there's a lot of discussion that needs to happen around processes, mostly how to proceed with this approach. So there's a lot of work around that, but we're very hopeful with regards to that. Sounds very promising. Kind of curious in a lot of work that's going on in there. So appreciate it from you and all the, your team and the community members that are doing it. I was kind of curious as I think about, like if I was a plugin, if I wanted to develop a plugin, like either how would I look at what's available? And I think we talked about that and talk about what do I do to get started? You talked about this SDK that's available. I didn't know any other tools or recommendations you might have for them, and especially in light of this, making sure it works across multiple versions of whatever it's interacting with on the Kube and back end. Yeah. Right. So we also thought about that one. And there are a couple of resources available. First of all, a shameless plug with who on, we did a presentation during one of the past Kube cons about what it takes to write a plugin. If you search with my name and six July, I'm pretty sure that you should be able to find it. I think that might have been either Seattle or around that time. Additionally, within the main Kubernetes, again, staging repo, we are publishing a repo that has a sample CLI plugin. And if I remember correctly, the repo is literally called sample CLI plugin. Similarly to how there is one for sample controller. And I think maybe even sample API server, there is one. So if you go to GitHub slash Kubernetes sample CLI plugin, it's a very minimal plugin that allows you to switch namespaces permanently. But most importantly, it shows how to write a plugin and how to reuse the libraries that we are shipping the CLI runtimes I mentioned before, how to build on top of Kubernetes API, Kubernetes client go to achieve the necessary stuff to build your simple plugin. Put your app in a link to that right now in chat for you. Make sense. Thanks. I guess I was just thinking through some of the other pieces of the CLI. You mentioned customize or anything you see kind of coming down the road as other CLI integrations. People are kind of core features that people are trying to work their way in as far as for a sub-project. That's an interesting question. Honestly, I haven't seen anything new in that territory, although at the same time with this many duties that I'm dealing with and PRs and approvals and whatnot, both upstream and downstream, I'm not very closely following the area of either CLI or controllers. And it's always takes me, well, sometimes it takes me by surprise, but if people are showing up either for SIG apps or a SIG CLI with something new, then yes, I will be aware, but nothing like that showed up. Sounds like the pretty full plate there. The plugin model really allows for anything to happen at this point too. So that's it. Yes, that's true. Sounds like that's the right thing to allow there. So Curious a bit more, you talked a little bit about your involvement in SIG apps early days as far as jobs and I know kind of recently become the co-lead of SIG apps. So I didn't know if we'd talk a little bit about what's going on and kind of the key things in SIG apps these days. Right, so yeah, a lot of the, so equally as with SIG CLI where there's a lot of moving pieces going on, there's a lot happening in the SIG apps area as well. Most importantly, we're trying to align some of the controllers by adding the capabilities that were previously available in other controllers. For example, the ability to say, oh, during a rollout, I wanna have this many pods unavailable, which is something that we had since always in deployments or Damon sets, we're currently adding similar capability to stateful sets so that before stateful sets were always going one by one pod, now you will be able to pass a little bit greater unavailability rates. So for example, you will be able to move faster with your upgrade. There are other issues that we're overlooking from SIG apps point of view as well. The biggest one that we're looking at in the very long-term is we're trying to unify the statuses of all the controllers. If you've ever looked at the controllers, you need to know how to read properly deployment status, separately stateful set status, separately job or cron job or any other controller. There is literally close to zero common interface between those. The reason for that is because each of those controllers were written by a completely different person. So everyone had a different opinion on how the status should look like. The biggest downside of that is if you're building tools on top of the controllers, you have to write a logic that will know, oh, I'm dealing with a deployment, this is how I should interpret the status. If I'm dealing with a stateful set, well, the logic has to be different. So we're trying to figure out a way how to combine the current statuses in all the controllers and make them somehow unified so that you will be able to just write one implementation and that will have the necessary information, whether your workload is just starting or it's progressing, whether it is done or it's like running, and that will depend. There are various different cases because if you think about it, most of the workloads controllers, so stateful set, deployments, daemon sets, their end state is that they are running. But if you look at, for example, the batch workloads where you just run a task and the task has an end, their state will be a completed. So we need to figure out those common statuses somehow and present them in a unified way to users. So we're slowly working on enhancement for Kubernetes where we will try to combine those statuses and then eventually slowly over time, we will be implementing. I'm positive that during the implementation phase, even though we're already spent a couple of weeks or even months looking at the statuses and trying to figure out with something reasonable, I'm positive that as soon as we start implementing those additional edge cases will pop up and we'll have to modify the initial requirements that we put ourselves. Yeah, it sounds like a pretty decent task and I've run into this multiple times we're trying to build experiences around extensions and trying to get the status of what's going on and it's challenging to write that kind of common tool to roll that up. One thing is kind of curious, like where does SIG apps is, you can say apps, you can put anything under apps in a sense. So how do you define the scope of what really goes into SIG apps or how is it defined as far as the everything that's, is it, I know you mentioned workloads kind of aspects of Kubernetes, but I don't know if you talk a little bit about what all happens there when it's the decision of keep punting it to other SIGs. Well, that's a very good question. So I'll probably refer to the SIG apps charter. So basically every special interest group within Kubernetes has a, its own charter as, as, as it sends it basically lists who is the chair, what are the sub projects and what basically we do and what are our responsibilities. So if you look at the SIG apps charter, we are saying that everything from controllers all the way up to that is running on top of the platform is considered as part of the SIG apps. So there are multiple topics that went through SIG apps. Controllers are obviously the most primary one. I would call it that way. So whenever you want to discuss any changes whether to API or functionality to one of the core controllers the SIG apps will be the place. Although some of the controllers are primarily owned by a different SIG. So for example, endpoints or services those will be owned by the, by the networking SIG. SIG apps will be mostly controller. So all the stateful sets, daemon sets, replica sets, replication controllers, all of that and then everything on top of that is running. There was a lot of work around and we still have a sub project called an application which is actually in a grouping primitive for a set of workloads together. Just recently we had a very interesting presentation about operator for higher level, like operator that is overlooking the penises between deployments. That was last Monday if I remember correctly the recording is up and that was pretty interesting. And I remember that the person that was explaining the project, they mentioned that they are working on open sourcing the solution currently. So there's a hope that there will be more stuff like that available. If you look in the past, a helm was for a very long time one of the primary topics during SIG apps calls and probably a couple other topics. And it was sometimes hard or overwhelming but I think at this point in time the majority of the SIG apps calls are devoted to the controllers. If there are no topics, we started doing box crops and PR crops and go through issues because there's quite a big backlog of the issues that we have against the controllers and we're slowly going through those and we're trying to make sure that people's voices get heard. Yeah, that was got involved in SIG apps a long time ago and we jokingly refer to it early days as SIG Helma because of what's dominated as Helma is a topic. One of the things I was going to say is like if you look at the GitHub page talk about SIG apps it's one of the things I think is great about it is the non goals kind of part of what it describes it doesn't endorse one particular ecosystem tool it does not pick which apps run on top of Kubernetes does not recommend one way to do things or things I think that's really helps clarify what the group is there to do. So even to the point of the app definition I know there's the label recommendations that the SIG apps actually overseas as well. So overall kind of kudos to a complicated topic I think that SIG has worked pretty well to handle over the years as far as scope of applications. Yeah, exactly. So we only have a whopping 15 minutes left and obviously we don't have to take the whole hour if we don't fill it, but what do you think are some unique challenges of Kubernetes today? And people starting out the sharp edges they might catch themselves on potentially, right? Like if they're getting going with Kubernetes Hmm, that's a very interesting question. For me personally, I think the biggest issue is the volume of the changes. And something that I'm personally struggling is how to keep up with all of the changes all of the requests for reviews I know that there are multiple issues and pull requests with my name on it. And whenever I'm talking with people during KubeCon or during SIG meetings I'm always asking them to reach out to me on Slack because my GitHub notifications in my email are way off charts. And I'm always promising myself to keep up with those. And it happens every, I don't know, every couple of months. Okay, I'm gonna clean my inbox. I'm gonna go all the way to zero and then only two, three days later or I don't know, something happens that there will be other topics that I need to deal with for two, three days. I'm gonna neglect those emails and they will pile up very quickly. And then it just goes by for the next couple of weeks and then I have to go back to the initial, oh, I need to go through, I don't know, a couple hundred emails and figure out which I care about and which don't. So that's unfortunately a big problem for me personally. That's why I'm always asking if you care about your PR, please reach out to me directly on Slack. I don't mind. If you haven't heard from me because you pinged me once or twice and if you haven't heard from me ping me again in a week, I will respond. I've had many people ping me literally every week for extended period of time, like really extended period of time. And eventually I got it through every time I apologized for neglecting that. But I always try to, if I don't respond within a week feel free to ping me, I don't mind.  There's so many things going on in parallel that it just might slip my attention or plenty forget about stuff. So I don't mind being pinged again and again about PRs or reviews. That's how it works. Yeah, if you don't have- I couldn't imagine- Slack, I'm gonna mess it up. Yeah. Yeah, I couldn't imagine your inbox and the backlog you have there is, I used to use some of travel, dead time to like kind of catch up on those things and don't have that anymore. So, but also don't have travel, dead time. So anyways, the thing that I was thinking of sort of much is like kind of that involvement of the community and how you've adjusted because I think back that I remember in the 2019 in San Diego at KubeCon and we're, I think of three of us were probably at the same height, like we're all pretty tall and we're like talking, people walking by and just hanging out there between the exhibit hall. That's such a great way to connect with people and with KubeCon coming up in North America. Again, I was kind of curious how you've, have you adjusted to engaging with the Kube community and then more of a virtual presence or- So, since day one, I'm every mode at Red Hat, but as we were talking with Chris, I do enjoy meeting people in person. In the early days, I have a pretty big Red Hat's office in Czech Republic, which is two, two and a half hour drive from where I live. I was visiting the office every single month, just for a day, but that was nice.  So, even though we are stuck at homes for the past almost two years, I do miss KubeCon. I'll be missing it even more in two weeks, if I remember correctly, at the beginning of October, I can't join folks in LA, but I would love to be around because it is just nicer to talk with people. I think most of the communication, most of the discussion can happen. It's not, that's not a problem. Either through Slack or Zoom, that works, but the bonding part, you know, having a beverage of your choice with the person and just chatting about silly stuff, I don't know, Disney World trip, visiting parents about kids, about life in general. Poor transportation in Detroit. Poor transportation in Detroit, exactly. I mean, literally anything. And most often, that's not even work or project related. That would make a huge difference. And even though KubeCon did a pretty well job with virtualizing those events, it's not the same. I do miss the interaction where I can stand in front of the people and talk with them, ask the questions. We literally did, instead of doing any kind of presentation for SXC-Li back in San Diego two years ago, when we did with Phil and Sean, we stood there and we answered questions about SXC-Li, everything for 90 minutes. You can't do something like that with the current pre-recorded sessions for KubeCon. It is not that easy. And even though there are slacks, there are some virtual chats, it just doesn't work that way. The ability that I can come to person, ask the question, poke them, and or have most importantly, the hallway conversation, that's invaluable. So I do miss that part. And even though I usually attended KubeCon both in North America and then in Europe, that was enough for me for a year. I did those two conferences, then DEF CONF as well in Brno, and I was done for a year, three times. I did more once or twice, but I was like, yeah, that's way too much for me. I'm okay with doing a conference per quarter. That's enough for my introvert character. So yeah, it's a good point. I'm flying out next Saturday to KubeCon. Yeah, like I remember being in San Diego and at the conservators summit, and there was all kinds of technical issues. And then it's much easier to say, hey, you don't know Git, let's just sit down and run through it real quick. Like this is the bare minimum you need to know, now you're a good contributor. And having that face-to-face discussion where there's body language and everything else, it's a lot easier to interpret the work that's happening, it is very different. And even like life dream, like we are right now, it's not quite the same as sitting down at a table with our computers and talking about a problem, right? Like it's very much a, hey, we're gonna talk, we're gonna work, we'll talk some more, we'll work some more, right? Like it's not the same flow, right? Yeah, exactly.  So like the keynote sessions, I don't go wake in line, whatever. I stream them from my room. Yeah, so there I am in San Diego. It's a city looking around at poles, squished between people. Near heat away, more of the big work, you're talking. So finally being an introvert, I actually sat during all of the keynote sessions. And actually, if I remember correctly, the keynote sessions were the only ones that I actually attended, because the remaining ones, I usually end up talking with folks in the corridors or in the both halls or basically wandering around and eventually just popping in for my session or one or two other sessions. So the key is where like the ones that you can actually find me on and then the ones where I'm presenting others. Well, I usually try to set up my schedule somehow. Oh, yes, these are the stuff that I wanna see. I probably don't see, I don't know, like 23% of what I check. I'm like, yeah, I wanna check this one out. Yeah, we have the same here. I get a few sessions in that feels like about it. Yeah, I spend more time talking to people and figuring things out than I do actually listening to people talk, right? Exactly, exactly. Someone just mentioned in chat, Rapscallion Reeves. At least most people at those conferences tend to be introverts too. So you're kind of amongst your own people. And then, yeah, Tanawa 3 points out, acoustics for the exhibition hall in San Diego was awful. If anybody remembers that it was just constantly loud in this big domed space with music playing in the background and 20,000 of our favorite friends or whatever, can't remember the attendance numbers, but it was just loud. I mean, I remember when we were in London, I think that was the first KubeCon in Europe. And there was like a hundred and something people. We barely had like two or three rooms, just a little bit of people. Berlin was pretty much similar and then it just grew exponentially over the years. That was crazy. Yeah, and this KubeCon I feel like it's gonna be a little bit like that, where it's like a little smaller, more quaint environment compared to the tens of thousands we're used to. Yeah, but the downside of that one is that we will be missing a lot of the contributors to the core because of different reasons they're not traveling to US or they are not even traveling within the US. I spoke with many people and it's not as easy or they are just not willing to do so at this point in time. Yeah, no, I was just talking to a friend on Twitter a few minutes before the show started or before we got on air and it was like, yeah, no, they can't come because they're in the UK or Berlin or whatever. And yeah, the lack of international folks is going to be very obvious. Like it'll feel very, you know, US-based, right? Like as opposed to international conference where people kind of gather. But with two minutes left, there's no questions in chat for, oh, there is one question in chat. I don't want to ask, sorry. What's the best way for random people slash developers to help out with Kube projects? I have my opinion, but I like to hear yours or Steve's for that matter. Honestly, I always say that it's easiest to show up during one of the calls, whether that'll be 60 live or SIG apps, especially the ones that are going through box crops. So for example, we will be going through customized box crop tomorrow or there's a 60 live box crop in two weeks from tomorrow. Those are the places where we literally ask, is anyone interested in working on this one? Is anyone here? It's a good place for asking questions. If you're new, even during the SIG apps or 60 live calls, we try to give a little bit of space at the beginning for everyone to introduce themselves who they are, what they want to work on. So it's perfectly fine to also show up for any of those calls and explain, oh, this is the issue that I've noticed. I want to work on it. Can you help me and just ask questions? There's no dumb questions about any of those topics. So it's the right place to ask that. That's usually my simple answer. Yeah, and that's my answer too, to be honest with you. Steve, I'm curious if you have a different opinion. Yeah, I think also the contributions are very valuable across the board. So talking about getting started early and looking at some of the setup instructions might be wrong, helping fix those up, opening bugs for issues you see for different things that seem a little off. So all of those things are a good way to get started. And I think one time I started was I was even a go-coder and I fixed one of the CLI issues just because the new lines were screwed up. So I knew how to insert new line and compile the code and contribute that back. So it was like, I could even just fix it. It was easy enough, instead of describing the problem, it's like, here you go. So I think the little things like that are a good way. It just depends on your context and background, so. Yeah, I mean, I started off in SickDocs very early on and then made my way over to Contrabex and that's kind of where I live now. That's fine with me. That'll work for anybody else, I feel like too. Yeah, there are multiple options, so just pick one. Yeah, and if you really wanna talk about it, feel free to ping me on the Kubernetes Slack folks. Chris Short, wide open there. I'm sure Macha and Steve are also welcome to answer your questions. Exactly. Definitely. And yeah, so thank you, Macha. Thank you, Steve, for guest hosting. Thank you, audience, for attending. Really appreciate everybody here on this call, live stream out there. Thank you very much. It's good to talk. Yeah, coming up later today, we have the call for code for Rachel Justice. We'll be talking about Take Two. It's a project that will help folks analyze data about the justice system in a way that will make people rethink about sentencing and things like that. So it should be an interesting call and lots of fun stuff for the IBM team on the call for code side, so yeah, good stuff. So thank you, everyone, for joining and have a great day and stay safe out there.


In the last few lectures, we have seen the improvements that we can bring about over the standard buffer insertion technique by using low swing current mode signal. There were two variants that we saw. One of them used inductive termination to provide a high pass function which countered the low pass nature of the wire. The other technique actually boosted the high frequency components of the signal before it pass through the wire. That was done through dynamic over driving in which at every transition additional drive was added on through a strong driver. This boosts the high frequency components of the original signal and therefore even after attenuation of these through the wire, you get an undistorted signal at the end. As a result, we could get very power and energy efficient transmission at high speeds over wires which are essentially low pass. We had seen a comparison of the inductive termination method and the dynamic over drive method. There is yet another technique which has lately been suggested and it is worth mentioning this because it does essentially the same thing as the dynamic over drive but accomplishes it using much simpler components. After all, what do we want? We want to dump extra current into the line every time there is a transition and this can be done by putting a capacitor in series with a strong driver. The series capacitor will make sure that no extra drive is injected when there are no transitions and at every transition extra current will go into the line. So it is a much simpler way of boosting the high frequency components than using the NAND NOR combination that we have seen for the dynamic over drive phase. So let us have a look at this capacitive driving technique, what are its problems and how we overcome those problems. As we have seen inductive peaking counters the low pass nature of the wire by providing a high pass function at the receiver. Dynamic over driving provides compensation by boosting high frequency components before transmission by providing extra drive during transitions. The same effect can also be achieved by putting a capacitor in series with the driver at the transmitter. However, this causes a problem. The DC common mode voltage of the line will now become undefined because we have put a capacitor in series. To counter this we can put a weak driver to set the DC level and to provide low frequency coupling to the line. Otherwise we might in fact just by putting a capacitor in series go to the other extreme where the drive is much diminished at the low frequency end and indeed the DC drive is removed altogether. So essentially a combination of a weak driver and a capacitive driver would provide very similar functionality to the dynamic over drive solution. Let us look at the circuit which accomplishes this. So if you look at the circuit on the top essentially the strong driver is now a simple series of increased geometry inverters. This is a standard way of driving high capacitance loads. The inverted digital input notice the one inverter here. The inverted digital input actually drives an NMOS which is directly coupled to the line and this is a model of the low pass interconnect. At the receiver end we have a grounded gate PMOS transistor which essentially acts as the termination and also pulls up the wire to VDD because it is always on. The gate is grounded this is a PMOS and therefore it pulls up this line. The receiver is actually a comparator and we will see the details of it is working in a digital way. Now the grounded gate PMOS at the receiver keeps a line at VDD when the input is at 1 because when the input is at 1 this voltage is at 0 and therefore the NMOS is off. The NMOS being off but this is of course always on and that establishes a proper and determined DC voltage at this point. This point then floats up close to VDD. When the input is at 0 then this point is at 1 and the NMOS turns on. This pulls the line to a voltage which is lower than earlier. In fact the geometry and the current for which this transistor is biased determines the low frequency swing at this line because it normally when the input is 1 this will flow to VDD and it will be at a lower voltage because of the pull down provided by this NMOS and the amount by which it is lower will depend on the amount of current that this transistor draws when the input is 0 and consequently this input is 1. The drop is a combination of the current drawn by this and the resistance provided by this transistor. Now these two transistors together will consume static power when the input is at 0. Therefore we would like to keep the current level through these as low as possible. After all these are only providing DC and low frequency coupling and a high power is therefore not required through these. So, we would not like to waste a lot of power as static power in these two transistors by keeping the drive through these any higher than is required. The actual high frequency drive is in fact provided by this chain of inverters only two are shown here but any even number can be used. These inverters have progressively larger geometries in order to be able to drive a large capacitive load. This capacitor then provides the capacitive peaking only when there is a transition at this point is it coupled to the line through this if the input remains at 0 or remains at 1 then there is no drive through these capacitive. This is exactly like providing a sharp current pulse of positive or negative value to the line during transitions which is what we had done during dynamic over driving. So, it is a simpler replacement for the concept of dynamic over driving and now we do not need that NAND nor and feedback circuit. So, this is actually an attractive solution and it is now being used in addition to the dynamic overdrive solutions that we have seen earlier. There are various pros and cons of this technique versus the dynamic overdrive and we shall see that this receiver is a little harder to design simply because the head room available is small and this line actually swings from VDD to a few millivolts below VDD. Therefore, essentially amplifying this voltage this low voltage swing is not that easy because we do not have much head room for the transistors connected to this line and this comparator therefore, is harder to design. In fact, our group at IIT Bombay has worked on this technique also and modified this technique so that the resting voltage at this point is brought closer to VDD by 2 so that efficient comparators can be designed easily here without adding too much to the static power consumption. That combined with a worst case data sequence technique actually optimizes the behavior of this capacitive peaking and gives very efficient data transmission on long wires. However, all these techniques have brought in efficiency by reducing the swing on the line. This means that our design has to be very careful otherwise if there are small changes in device parameters which will always happen can have a disproportionate effect on the performance of the system. In the voltage mode this signal is swinging all the way from ground to VDD and therefore, small changes in VTE etcetera of the transistors do not have such a big effect. However, in modern short channel processes variations in transistor parameters are large some of the parameters can vary by as much as 60 percent and therefore, we have to design circuits so that they are robust with respect to batch to batch variations as well as variations between devices on the same die. What will these variations do? They can in fact change the operating points and the strengths of the driver connected therefore, we have to design our techniques such that they are practical and robust with respect to such expected variations. Dry variations are also important because after all we are talking of long wires therefore, it stands to reason that the transmitter and the receiver are in different parts of the chip which are separated by a long edge distance. As a result the transistor parameters at the transmitter end and those at the receiver end will not be identical. So, there are two kinds of variations which vary us and therefore, the design of interconnect or where design must take this into account. One of these is a batch to batch variation that means, if for one run the scheme works if we are not careful in a design in another run where the values of VTE and mobility and so on are different for the NNP channel transistors. The operating point may shift and because your swings are extremely small it is not guaranteed that your scheme will work as well anymore this is one problem. The other problem is that the transmitter and the receiver are in different parts of the chip and they may be mismatch on the same chip in the same run and this mismatch can cause malfunctions. So therefore, we need to have a style of design which takes these variations into account and permits our circuits to keep working in spite of these dynamic variations. So, what are our robustness requirements? We are saying that the process supply voltage and temperature variations popularly known as PBT variations will affect the core logic as well as data communication circuit. It is not only the interconnect which will slow down in fact, the rate at which we generate the data will also change therefore, the requirement for data transmission is not complete invariance with respect to PBT variation that is not our robustness requirement. We just have to ensure that throughput and delay properties of the interconnect are at least as good as data generations and clock rates. If we land in a slow version of the transistor parameters then the data generation and the clock that it can support will also come down. What we have to ensure is that the deterioration in interconnect properties should be no worse than the deterioration in general logic. Because of global interconnects by definition these connect remote points on the die and on chip variations must also be accounted for. Let me just give a simple example of how this local variation can be of concern. The batch to batch variation and transistor parameter variations with runs is easy enough to understand because after all a slow circuit when VTs are high, mobilities are low will not keep up to the speed requirements. However, it is a much more softer nuance to understand why local variations should worry us so much and why is that worry more in case of in case of low swing techniques that we have been describing. Consider this case and here at the receiver we are trying to resolve this small swing around a common mode voltage into a full blown ground to VDD swing which will then be used by the receiver. Now, if the switching threshold of the receiver is exactly aligned with the common mode voltage as driven by the transmitter then we do not have a problem. Designing an amplifier which will take this small swing and amplified to a full rail to rail swing with a comparator is not very difficult. But, let us say that because of parametric variations and mismatch between the transmitter and the receiver the common mode voltage at the transmitter is slightly below. In fact, it is solo compared to the common mode voltage at the receiver that even at the highest level of the swing at the transmitter it remains below the resolution threshold of the receiver comparator. As a result while we have a healthy swing around this common mode voltage at the transmitter this entire signal whether high or low is below the threshold of 0 at the receiver and as a result the receiver will be stuck at 0. Exactly the same thing happens if the common mode voltage is much higher than this one level and because this swing is rather low relatively small mismatches between the transmitter and the receiver can lead to problems and there is no problem for the rail to rail swing of the buffer inserted technique. So, while we have come up with a better technique which is energy efficient it brings in its own requirement of robustness of design which we must be aware of. So, to analyze this we have essentially a somewhat idealized model of either dynamic over driving or the capacitive drive case in which we apply an enhanced drive for a short time. This could be because of capacitive coupling or because of dynamic over drive 9-0 combination and then maintain the line at a low drive. Similarly, when there is a 1 to 0 transition we give it a large boost for a short time and then maintain it at low drive. At the receiver end we have a reference voltage Vm which is the switching voltage of this inverter at the receiver and a terminating resistance. This amplifier has a high gain provided this line is kept at Vm and finally, this drives a buffer which drives the load capacitance. There are various parameters of the transmitter and receiver which will affect the robustness of this solution. The value of Ip is the peak current supported by the strong driver during input transition that is the Ip value. Tp is the duration for which the strong driver is on and delta V is a line voltage swing at the receiver end. So, as a result of this drive shape in current at the transmitter we shall get a delta V at the receiver end after it has passed through this low pass line. And finally, the mismatch between the common mode voltage seen at the receiver and the operating point of this transmitter. So, these are the various parameters which will affect the robustness of a design. The scheme with feedback which we had described which has essentially a feedback inverter which stops the drive when the line at the transmitter end reaches a 1 or a 0 has a particular problem. The reason for that is that this sensor inverter which turns off the drive is at the transmitter end and this inverter which is very similar it transfers the low swing voltage to a range and to rail swing is at the receiver and these two might not match. In that case if the mismatch is too large we may have a problem. Let us look at this case and let us say that the common mode voltage at the transmitter end and the common mode voltage at the receiver end have a certain mismatch. Now what happens is that because the receiver tries to maintain the line at this voltage the sensing at the transmitter goes completely awry. Consider the case here. Let us say that the line was resting at 1 and we are trying to pull it down to 0. As we pull it down to 0 the feedback inverter after the transition is complete turns the strong driver off. However the common mode voltage at which this turning off occurs is much lower than the receiver common mode voltage. As a result the voltage here goes to a voltage much lower during than the receiver common mode voltage. And therefore as soon as the strong driver turns off the receiver starts charging this line up because the receiver is trying to keep it at VCM RX. As soon as it reaches a certain voltage the feedback inverter at the transmitter thinks that this voltage is too high and turns the strong driver on again. Notice the input has no transition at all. However because of this feedback there is this back and forth between the receiver and the transmitter. When the strong driver turns off the receiver starts charging it to its common mode voltage. This common mode voltage is too high for the feedback inverter at the transmitter and that again turns the transmitter on which then takes it down to the low value which it sees as the appropriate low voltage. And when that voltage is reached the strong driver turns off. As soon as the strong driver turns off the receiver tries to take the voltage to its common mode voltage and because these two are not the same you get a an intermittent turning on and off of the strong driver which reduces the average swing of the line which can cause robustness problems. These problems are removed by a technique which we have advocated and which is a fixed pulse width driver and this gets rid of the feedback. Notice that this circuit is not feedback and the drive is now provided for a fixed delay. That means the strong driver is not turned off on sensing the line we are not sensing the line anymore. The strong driver is turned off after a delay which is process dependent. We would like to minimize this process dependence and this we have done in some work done at IIT Bombay by developing bias which actually senses the current process. This whole thing depends on a short channel PMOS and a long channel NMOS or a long channel NMOS and a short channel P. A long PMOS and a short channel NMOS. This system relies on the following fact that the short channel transistors have a much higher variation than the long channel transistor. So consider this because this short N channel NMOS will vary with the process whereas the long PMOS will not at least to 0 level. Therefore it acts as a it sends more or less a process independent current through this diode connected NMOS and as a result this output tracks VTN. If VTN is higher this voltage also becomes higher and that corrects the bias for transistor parameter variations exactly the same thing happens for this PMOS. So using such auto bias circuits we have developed a system in which the drive through this is in fact correct corrected for process variation and also it does not use any feedback. By combining these two techniques in fact we have been able to come up with a very robust technique. We have simulated these techniques and we find that the degradation for the scheme that we have suggested these are the three schemes this is the current mode scheme with feedback this is the current mode scheme with fixed pulse width and this is the current mode scheme with the smart bias which I have just now described. And we find that the degradation and the mismatch is much reduced in case of delay the percentage degradation can be as much as 25 percent for the feedback case 10 percent for a fixed pulse width case and only 4 percent when we combine fixed pulse width with a smart bias case. Similarly the throughput degrades by about 33 percent in case of feedback about 14 percent in case of fixed pulse width but only 9.5 percent when we use this technique which combines the fixed pulse width with a smart bias generation. So by using essentially good VLSI design techniques it is possible to meet the robustness requirements so that the current mode solution can in fact become practical. You can see that the ring oscillator frequency degrades by about the same order 23 percent here and the one with bias is much smaller than the ring oscillator frequency due to process variation. Essentially what it means is that the ring oscillator frequency will determine the digital rate of generation of data. If this degrades by 23 percent then as long as we degrade by less than 23 percent everything is fine and we notice that the voltage mode fails to meet this requirement. So does the current mode scheme with a fixed pulse width whereas the scheme that we have suggested and the scheme with feedback they can meet the requirement for the process variation notice this is not local variation this is process variation. However the feedback circuit is not so graceful as we had just seen in case of on chip variation between transmitter and receiver this table is for global process variations and for that the feedback scheme is not very good. For local variations the fixed pulse width scheme is okay but this is not very good but the scheme that we have suggested which is the current mode scheme with smart bias that meets the requirement in both cases. I think we will skip this to go to a bidirectional link. Now notice that bidirectional links are very important we had talked about this earlier and we need to have a scheme which will permit bidirectional transmission of data. This can be done in voltage buffer mode by using back to back connected tri-state buffers where exactly one of these is activated however as we had seen that this leads to problems first of all the delay of a bidirectional repeater is more than that of a unidirectional buffer because of the loading and a direction control signal is required by each repeat repeaters if there is a bus then the direction control signal is loaded by a large number of such transistors in parallel and the buffers carrying the direction control signal are heavily loaded and they consume additional power. So we need a repeater less signaling scheme and this can be done in the current mode bidirectional link essentially we have across the line a transmitter as well as a receiver connected to the end of the line notice that nothing needs to be connected in the middle of the wire at either end of the wire we have a transmitter and a receiver. Obviously the transmitter and the receiver must have the information of who is to transmit and who is to receive in any bidirectional scheme that is the case since that information is available we can use it to turn on either the transmitter or the receiver at either end of the wire and thus achieve bidirectional transmission quite easily this is possible because there is no active circuitry in the middle of the wire and as a result we see that as a here we plot the regions in which the current mode bidirectional drivers consume less power than the voltage mode bidirectional power. The plot is data rate versus line length and for all combinations where the current mode consumes less power we have this shaded region that means for this line length and this data rate and beyond the current mode will consume less power and you notice that most of the usefulness useful range is covered by that region for example line lengths greater than 2 millimeters and data rates which are say a few 100 megabits per second for all such combinations whatever the line length whatever the data rate the current mode consumes less power compared to the voltage mode and this is a very important point because these are in fact the robust designs that I have described just a little while ago. There is one additional advantage that current mode has and this is the power drawn from the supply the voltage mode buffers draw huge amount of power from the supply and as a result cause spikes on the supply voltage this is a source of additional noise to the entire system because current mode draws less power from the power supply the spikes that it generates on the supply voltage are much smaller and as a result the noise level injected is much smaller consequently a current mode interconnect runs quieter than a voltage mode interconnect. So, therefore, we are talking of a 68 percent reduction in peak current and hence contribution to supply noise is smaller and 80 percent reduction in active area therefore for bidirectional data transmission current mode is indeed extremely attractive. Well many of these ideas therefore sound quite attractive we would like to show that they work in silicon under practical cases and there is one problem which presents itself when we contemplate doing this and that problem is the following the overall delays of wires of any practical length are quite small these are of the order of a nanosecond or less measuring such delays is not an easy thing and if you couple it through a pad and bring it out to external instruments which might present loads of the order of picofarads it will be extremely difficult to demonstrate which of the techniques that we are talking about is in fact faster and therefore we need to develop test circuits which will allow us to compare the performance of various suggested schemes on chip itself and the output of these test chips test circuits should be such that it is either DC or some low frequency which can be brought out from the chip easily and can be measured using inexpensive instruments. We shall illustrate this by only a few representative circuits consider this suggestion what we have here is a multiplex demultiplex circuit and we have a choice the MUX and D MUX ensures that there is a ring oscillator here and this ring oscillator will oscillate at a particular frequency. The frequency of oscillation will depend on the total loop delay now what we can do is that in one of the arms of this MUX D MUX pair we can put the transmitter wire and the receiver of the suggested scheme the other is a dead shot now we measure the delay using the dead shot first this measure the delay through these inverters this MUX and this D MUX apart from that the delay of this short wire which provides the shorting path L 3 is also included. The other option in the other position of the MUX D MUX what we have are these approach lines L 1 and L 2 and apart from L 1 and L 2 we have the transmitter the long wire over which we are measuring the data rate and power etcetera and the receiver. It is laid out in such a way that the transmitter and the wire loops back to the same region this is the shorting wire of length L 3 L 1 is the length of the approach wire to the transmitter and L 2 is the approach wire from the receiver when the MUX and D MUX is in this position we ensure that L 1 plus L 2 is the same as L 3 as a result the total delay which is common for the two cases includes the entire delay of this path that is common and because L 3 is equal to L 1 plus L 2 this delay is also the same. Therefore, if we take the difference of the two delays then it measures accurately the delay through this. So, essentially what we have done is that we have converted the measurement of very short delays to a measurement of oscillation frequency. We have this ring oscillator we put the MUX D MUX in the L 3 position and because of the much smaller delay through L 3 this ring oscillator oscillates at a much higher frequency using a low frequency signal we now switch this MUX D MUX to take the lower path when it takes the lower path then the delay of the transmitter and receiver is included in the path and therefore, the ring oscillator still oscillates, but at a much lower frequency these two frequencies are indicative of the delays in the two cases and if you take the difference of the two delays in that case all the common delays cancel out leaving only the delay of the path which we want to measure. So, therefore, by measuring the frequency in the two cases which is as simple as this formula. So, therefore, the net delay of the transmitter plus wire plus receiver is given simply by this which is 1 by F RO which is the ring oscillator minus 1 by F system. So, system is when it is shorted and this is the ring oscillator with the transmitter receiver in notice that this system is much higher this was assessed by doing first simulations in simulations of course, we can see the delay and we can also see the frequencies. So, when we simulate this circuit we look at the frequencies and compute the delay using this formula and compare it to the delay which we see in from the simulation transient simulation case and we find that the percentage error is very very small. Similarly, by using a time to voltage conversion in which the application at the transmitter of the digital bit starts the charging of a capacitor and the arrival of the bit stops the charging through a current source. We can convert this delay to a DC voltage and this voltage can be read from the outside circuits. So, this essentially points out that there are circuits which are possible these circuits can be put on the same chip as the interconnect and by using these circuits we can actually make very small differences in delay and power visible through signals like frequency and DC voltages which are very easy to measure of chip. So, we actually implemented these various schemes on silicon and use these measurement circuits on chip. The high frequency of the ring oscillator was in fact scaled down by a factor of 32 to 64 to come down to a level of frequencies where we can measure it easily using inexpensive frequency meters. So, this is a chip that we actually made this was this is a photograph not a diagram and the transmitter receiver all the wires and all the circuit are here. We built an external test jig which provides all the voltages control signals trial signals and so on and the hold I was packaged in a 44 pin QFN package. Using this we measured the actual delay the power and the energy used by the three schemes and looking at the data rate and the measurements we can see that the proposed circuit which is the CMS bias remember this is the circuit which counters both the batch to batch process variation as well as the transmitter to receiver on chip parametric variation. So, using CMS bias we can see that we get about 22 percent improvement in delay and as much as 85 percent improvement in the energy delay product over the voltage mode scheme. This establishes the fact that this scheme is much superior to the widely used buffer insertion scheme and at the same time is practical against process variations and on chip variations. Therefore, it is possible that in future circuits in the interconnect aware design will make use of circuits of this class. Remember this has the advantage that the general design style of the digital circuits which constitutes most of the complexity of the VLSI design does not change at all. The bits are still rail to rail they are the conventional voltage mode bits it is only the transmission of these signals which has now been reduced to current mode. So, essentially just to summarize the behavior there is at least 7 times lower power in the worst case process corner 78 percent gain in active area this is the area on silicon and 65 percent reduction in the peak current which then translates to generation of lower supply noise. Another factor which must be pointed out is that the voltage inserted buffer have to be redesigned for every wire length if the wire length changes then the placement and sizing of the buffer inverters has to be changed. On the other hand the current mode signal is very robust it is designed once and for all and remains unchanged for all wire lengths and this is an advantage because then you can put it in a library and then not worry whatever the length of the wire the same component is pulled out and then used. The proposed dynamic over driving CMS scheme and by the proposed scheme I mean the one that we have proposed which corrects for robustness from batch to batch and on chip variation using a smart bias circuit offers 26 to 40 percent improvement in delay for 2 mm to 8 mm long lines, but also compared to other schemes it offers a substantial improvement in the energy delay product. Compared to other current mode schemes like the one with feedback there is 22 percent improvement in power delay product which is much smaller of course with voltage buffer all current mode schemes perform much better than voltage buffer schemes. So, this 22 percent improvement is over the other current mode scheme a factor of 7 improvement over the voltage mode scheme and the CMS scheme with feedback is sensitive to intraday variation whereas the current mode scheme with a smart bias remains faster than logic circuits even in the presence of intraday and intraday process variations. We have also made measurements with bidirectional links and we noticed that current mode bidirectional links offer very small delays and small consumption of power compared to traditional traditional voltage mode buffering scheme and in this because the simulation showed that the performances are not even comparable we did not actually compare these 2 on silicon. We actually did an extraction of transistor parameters from some extra patterns that we had put on the chip and then we can show that if we use the transistor parameters which occurred on the exact run on which we have made measurements then we can reproduce the results that we measure. So, in conclusion we can say that global interconnects form a major bottleneck for performance of a digital system at scale down technology. Use of current mode signaling is promising to remove this bottleneck through simulation circuit fabrication and actual measurements on silicon. We have demonstrated that current mode signaling has overwhelming advantages over the currently used voltage mode buffer insertion schemes. We have demonstrated that the particular configuration suggested by us for a current mode scheme is superior even to other current mode scheme and this particular configuration has apart from a fixed width over driving pulse, a biasing scheme which controls the amount of current dumped by the over driving in a process independent and variation independent way. Our scheme is robust with respect to batch to batch parametric variations and to on chip parametric variation and therefore, it is a practical option for use in modern systems for implementing both unidirectional and bidirectional data links. With this we bring this discussion on current mode and voltage aware data links to an end. So, essentially what it means is that the interconnect wires which were not even considered important earlier have become performance limiter and very careful design has to be done. The widely used methods are running out of power now and fortunately new schemes which combine mixed signal design with VLSI design which can give interconnect aware design and they can continue to boost the performance of integrated circuits as we scale down the dimensions at least for the foreseeable future. And it is the use of these techniques which will result in interconnect aware designs of tomorrow. We will bring our discussion of interconnect aware design to a close with this lecture.


Pass the pink car? Yes. Roger. Roger. You hear that? This way. We're going to push on that? Yeah.  Hey, we're pushing on this.


Could I please please please please please get some coochie please pretty please with sprinkles and cherries on top? I promise I won't ask ever again. Please is a little bit of coochie. Please That was in my Instagram DMs yesterday Yeah, I thought I would share that with you boys to start this episode of wheel of nuts So if you ever think to yourself wow, I just said I am down so bad trust me my friend You are not down bad until that appears in my Instagram DMs. You are not down bad. You're doing alright soldier Don't worry about it. I think I got my swagger back Listen, I don't know if you need to hear this, but you're not gonna clap every single girl's cheeks, okay? I hope so you're gonna get curved. It's gonna happen move on pick yourself up. Have a positive attitude Okay, go get the next one champion. You got this buddy.  Okay. Okay. Okay dial it back in I'm on back-to-back wheel of month mode. You can tell it's getting dark out probably not a good idea But I did just come off a super hot W. You got to go watch that episode. No spoilers go watch it It's a W. So I'll tell you Joe Burrow was locked in last episode Definitely gonna be our endgame QB as well as von Bell who's not gonna be our endgame strike safety But hey, we're building, you know the rules ladies and gentlemen, I'm not gonna ask for any wheelspin There's so many different things I could use on this team I'll be grateful for whatever I get our pack is training This is kind of good right now fact. This is really good right now So I can get any pack from the training store and get to so I don't know team of the year pack is still in it is I don't want to double up on team of the year packs. I know it makes the most sense But it's super lame. I'm not gonna do the team near fantasy facts.  I'm gonna do two ninety three plus overall NFO draft past players I do have the chance to pull the 97s. I'll know the animation instantly Hate when they do that. All right Well, I just pulled the 99 that I just want to kill myself because I'm not gonna use that We're opening two more. That's not the animation. It could be a 93 or 95 Anthony. This is perfect Yes, I have no linebackers right now Anthony Walker. Hello there That is faster than any of the middle linebackers on a team of the year All right, first one was clutch Anthony Walker very usable very solid pole not the animation, but Another linebacker. Let's go. Thank you.  That's huge honest to God. That's amazing KJ right I do not like him, but I do really like Anthony Walker. So this is a really good start All right. Next up absolutely need a tight end like I don't care how we get it I just saw my tight end. What do you got for me? I like it. Okay, so any 95 or 96 overall player power-ups included, but they must come from the Eagles It's maybe just earths get up to that overall. I don't think so.  Oh, what about the 96 is who in the 96 Eagles players got her. Oh my god Dallas Goddard, I did not know that Let's go that's so clutch Dallas Goddard vertical threat 96 overall Easter tight end with 91 speed also a man who helped my fantasy squad this year as soon as earths went down Dallas Goddard Started going ham, bro So we're in 84 overall just from our new linebackers and Dallas Goddard now comes in makes us up to an 85 I kind of want to put abilities on him, but I just like all the abilities on burrow right now I'm gonna leave everything as is 85 overall team. We're really climbing those ranks really fast right now I love this I'm really excited the big hole in our team right now is the fact that we're gonna get edge rush like crazy It's all offensive line is trash, but six more wins. We got one win under a belt We got one loss and as you can tell I've been doing a crazy amount recording.  Let's get this Money that leaves the challenge really so clutch right now in those insane packs are still in the store So I would love to get this not 90% completion. Just not 90% completion tell opponent red zone plan and I must score Okay, I've done this one before this one's kind of nice Big Ron, I love you is that really your team or did it glitch out?  Who is your team?  I feel so rude. I have to tell him He's got Joe Burrow as it dude.   Let's get the man some reps early.  All right. We got a score down QB draw. He knows I'm doing it presumably if he was paying attention Go burrow. Okay That is not the touchdown we need. Okay. Wait, wait. I just have to score with it.  I have to dodge this user. I'm gonna fumble.  I can't score from here with QB draw.  Oh Okay, okay, whatever honestly more than anything it's important that I lock in these players like when I get opportunities like this So this should probably be a safety Like okay, we probably have the same overall teams How's that not I just got a roughing the passer. Oh, no, I didn't intentional grounding. Oh, I want this ball back I need to score like that. I'm setting prime time off the edge big blitz I got to cover the whole right side of the field though.  No lie run play action. I want to sack you so bad Second 11, this is a bangles team team Heater he's playing well for bad team. He's playing really well pretty much the only time I feel confident right now up Vombell against your own team This is how I will get my QB draw touchdown. I should have chosen a way better play. Why did I choose this play? All right, burrow, can you do it? Can you lock up the QB draw this challenge complete? And there's a really good chance we're getting a ragecoat too. Honestly, this is just a gimme This is a total freebie handed down from the Madden Gods. There we go, baby. All right, we're going with the fake Yup flick it up. There's Dallas Goddard Did I get I want to play really infuriating so that he ragequits which is basically just sending screaming hot blitzes I'm gonna bait that tight end. Oh Got the sack anyway second and 17. This is either an interception from that tight end or a sack. Let's see what happens.  I just feel bad, bro. I really do he wants to throw the tight end I know he does Awesome, Muka at fourth and five. Let's get this ball back and then uh, just make this guy hate himself Basically kind of the game plan here. Oh Why am I in why am I in why am I in run from it? Well? I can't really lose. I guess it doesn't matter He just missed the p.a.t. Ladies and gentlemen. He actually did not have enough power to kick the p.a.t. And out of bounds kicking is not his forte. I'm fairly certain. I really could run anything in score I'm gonna who Leo could just outrun his team No, but Jerry.  Let's get Lucas Nyang involved Lucas Nyang is literally a right tackle Five for five one hundred fifteen yards. Let's get that perfect passer rating pretty sure I could just throw Julio at the end zone and aggro I don't want to risk it I Don't want to risk my His first season of wheel of mud, you know, and he's got this trash team first and ten play action Don't do it man third and 11 He's got to pick up serious. That's why I'd open but I'll just do a horrible ball. Oh get up and pitch it It's not your fault man.  It's funny. It's like I'm gonna tell you what I'm running and I'm still gonna score He just went out sad not only do we get a rage good wheel spin But we get any pack in the game Let's start with our pack because we can't determine what we're gonna get in our pack But we can determine what we'll get with the spin potentially so and all the page will be pull here I would love some offensive line our draft player is I get another tight end Dan Arnold who I also love so I'm super happy about that tight end backup Tommy Harris 95 de tackle dude my pants on these are insane. We got a backup half back Eddie George Absolutely Reggie Wayne and that's trash Patrick Queen.  I would love a good de tackle. Are you kidding? All right, let's put Tommy Harris in for sure. He can Jones can go here. That's amazing actually Let's go and this Dan Arnold this Dan Arnold just might be a menace We'll have to see and then 92 Eddie George as a backup half back. That's amazing. I got the hiccups. Come on Go away.  Let's go. Let's get through this.  Oh focus up. Come on. What you got for me, baby?  Let's see what serious redux Rams players there are I know there's a Cooper cup and since I just got my haircut. I look exactly like this Cooper cup right now What he might be a little more handsome than me. I'm not gonna lie, but okay, so damn Aaron Donald is a serious Redux for the Rams, but obviously we already have nice rain lane could be an insane safety He'd be a lot better than non-Bias and we got it safe because he's super physical so 96 97 was pretty solid 94 95 probably gonna go night train lane here. Oh Nothing else the Rams do not have a lot for me. I thought there's a 97 Cooper cup.  It's a 92 Cooper cup I don't know why I thought that was a 97.  Like no lie Asamuga is my backup corner if anybody gets winded he'll come in and I train Lance a new safety All right boys before I literally throw something because of these hiccups We have an 87 overall. We shot up so fast so grateful for that two straight wins. That's the big part We're like a snowball. We're rolling down the hill and we're picking up steam and we're making it work. All right I love you boys. Thank you for watching this always. I'll see you the next video next one. I'll be in Hawaii I'll see you then peace out