Hi, I'm Sergeant Asia Schmitz and I'm an 0-4-31 logistics and embarkation specialist. I joined the Marine Corps not for, I would say, I would say for the average reasons of wanting to travel, wanting to be a part of something bigger than yourself. One of my friends actually brought me to a Marine Corps PT because she was in the debt program and from that moment on it seemed like that was the only option available for me like that was the perfect fit honestly. I wanted to re-enlist so I can better support my family and also just so I can further my career within the Marine Corps. I plan on this being my last enlisted enlistment. I honestly love what I do as far as embarkation is concerned and I want to take it a step further in staying in. The re-enlisting isn't a matter of whether you really love the Marine Corps, whether it's giving you everything you wanted, it's a matter of if that's what you want to do in your life and you're not less of a Marine for wanting to get out, you're not more of a Marine for wanting to stay in, you're a Marine once and you're a Marine for life.


Good afternoon everyone. I hope you all are having a good day and have had a good week here at the OpenStack Summit this week. Thank you all for joining us this afternoon. I don't know, is this the last session of the summit or is there one more after this one? Okay, so there's me and one other person in between you and freedom. So I will do my best to make sure that we give you useful information and that way you're not inclined to go ahead and leave. How many people are leaving to go home internationally perhaps tonight? Anybody flying home? A few here and there? Okay. Well we wish you safe travels and thank you for joining us. My name is Scott Lowe. I work for VMware in the Network and Security Business Unit. And that is the team that is responsible for creating VMware NSX. And we're going to take a few minutes this afternoon and talk about deploying NSX with OpenStack. Before we get started, let's, there we go. Make sure my thing works. Before we get started, just a couple of things. Feel free to ask questions throughout the session. You're more than welcome if I say something and you don't understand and you'd like some additional information or some additional clarification. Please feel free to ask a question. The session is being recorded. So ideally we'd love for you to get up and go to the mic and ask your question. But if you can get my attention past these very bright lights, then I'll repeat the question so that the recording gets it and everybody else in the room can hear it as well. But I may need you to speak up if you don't go to the microphone. You're more than welcome to take pictures or post tweets or updates or whatever. We do ask that you try to minimize whatever noise your mobile device makes. So turn the volume down on the little picture taking sound so that other people don't get interrupted during the session and turn off ringtones and that sort of thing. Just out of courtesy to everyone who's here. Okay, so a quick look at who I am and why I'm up here and then we'll take a look at what we're going to talk about. So I am a longtime veteran in the IT industry. I've been working in the IT field for over 20 years. I am a blogger. I write a lot on my own website, blog.scotload.org and you've probably visited there at some point. I've been writing for about 10 years on that site. I have had the opportunity to publish a number of books and so you may be familiar with Mastering VMware vSphere. That was a book that I wrote last year. I was very honored to be able to participate in a book sprint when we produced, along with a number of other individuals, we produced for the OpenStack community the OpenStack Architecture Design Guide, which is available in PDF form off the OpenStack.org website or you can read it online in HTML form on the OpenStack website as well. My current focus at VMware is on open source projects. I do a lot of work with the Open vSwitch project, open virtual network, Docker, OpenStack naturally. I'm here so open source, cloud computing, networking and virtualization and just to show that I am truly a geek, I do run OpenStack at home. Anybody else out there running OpenStack at home? A few, okay. Yeah, so you know how it is. My kids are asking me to spin up Minecraft servers for them so I tell them to go log into the OpenStack cloud and spin up their Minecraft server. All right, our agenda. I'll provide for those of you that aren't familiar with NSX, first a quick overview of VMware NSX. Very high level but if you are interested in more detail then you can see me after the session and I'll be happy to talk with you and answer any questions you may have and go over any of the elements in more detail but I don't want to bore everyone. We'll start with a high level view. Then I want to look at some of the means or the channels that you can use to deploy NSX in your OpenStack environment. I'll provide some examples of some customer deployments using these various channels, right? I was asked to remove customer-specific information so I have to be very kind of generic about the customers but I'll give you what information I can share and then perhaps the most exciting part at least for me and hopefully for you as well. I'm going to talk about some of the future things that we're going to be adding in a future release of OpenStack and I've been told that this is one of the first times publicly that we'll be talking about these features that we're planning on adding to OpenStack so you guys are among the very first to publicly hear about some of these features that we have planned and I have a section for Q&A or questions and answers here at the end but as I mentioned earlier you are more than welcome to ask questions at any time don't worry about interrupting me you are more than welcome to just stick your hand up or get my attention in some fashion and ask your question. So let's start with a quick overview of VMware NSX as a way by uprace to hand how many people are in here familiar with the NSX architecture? I'm going to block the light so I can see. Okay, a fair number of you, okay. So we still have a pretty fair number of folks who are not familiar with it and therefore I think this will be helpful. So what is VMware NSX? It is a network virtualization solution we leverage a network overlay so what we are doing is we are focused on creating a solution whereby you can create logical networks that are decoupled from the underlying physical network fabric using a network overlay this overlay mechanism and the software and orchestration that is wrapped around that as part of NSX allows you then to create and put into effect distributed L2 and distributed L3 across all the hypervisors in the system so you will get distributed layer 2 switching and distributed layer 3 routing and that functionality is distributed across all the hypervisors that are involved in OpenStack so if you have 500 nodes in your OpenStack deployment then every single one of those 500 nodes will be performing local L2 switching and local L3 routing and it will all be centrally controlled and centrally orchestrated by NSX the part that does that orchestration and that control is a scale out control plane so we have a scale out controller cluster that performs the functions of understanding where your instances in the OpenStack cloud are running on what hypervisor they were turned up and how to provide connectivity to those instances that information down using control plane protocols to the hypervisors and the hypervisors are then responsible for actually doing the work. It's very important to note although I don't have it noted here on the screen but just as a point of reference here that the control plane is completely out of the data plane there is a total isolation and separation between the control plane NSX and the data plane and hopefully that makes sense and as an example of doing that in some cases when you have a central controller or a central controller cluster the hypervisors end up having to forward traffic to the controller to understand what needs to be done with it and so some architectures incur additional latency when they receive a packet they don't know what to do with that packet they end up sending it to the controller the controller has to process it and then send it back NSX has a complete isolation between the data plane and the control plane so the hypervisors will never forward traffic to the controllers we use a proactive method of programming the hypervisors so by the time a packet reaches the hypervisor from a VM the rules have already been inserted into the hypervisor to tell it how to direct that traffic and so we don't ever punt traffic to the controllers which gives us an improved latency versus solutions that may need to punt to the controller NSX is supported in multi-hypervisor environments and I'll show you an architecture in a minute that shows it running on Linux hypervisors when you are running NSX in a pure vSphere environment and perhaps you're using VIO and there have been a couple sessions prior to mine on VIO this afternoon so I won't spend a lot of time on VIO I'll mention it briefly but I won't go into detail because the previous speakers have already done that for me but let's say you're running VIO and you're running NSX that would be a completely vSphere environment there are additional network services that we can offer in that pure vSphere environment when it's running with NSX that we today can't offer outside of that environment so one of them is for example a fully distributed and fully stateful firewall where the enforcement of the firewall rules occurs at the vNIC layer on every hypervisor so just like we distribute all the L2 switching and we distribute all the L3 routing across all the hypervisors in the system when you're running a pure vSphere environment underneath OpenStack we can offer fully distributed firewall functionality that is also stateful so L2, L3, L4 firewalling also logical load balancing and when using conjunction with VIO you can consume that through the Neutron LBAS project and also logical VPN it's not yet integrated into the VPN as a service efforts from Neutron but that is something that we are actively exploring so here's sort of a graphical view of what this looks like this is a really high level view and you know I wouldn't take it as a technical sort of deep dive architecture this is more of a logical representation of the pieces that come into play but you can see and I wonder does this thing have a blazer pointer you can see some of the key elements of the architecture that I reviewed already for example when we're operating in an OpenStack environment we operate as a core plug-in into Neutron and that core plug-in by the way is fully upstream so there's nothing proprietary about that plug-in it is developed fully upstream with the rest of the Neutron plug-ins available fully upstream runs through all of the existing OpenStack gating and infrastructure so when we're running NSX in conjunction with OpenStack the interface would be the Neutron plug-in it would be talking API where you see I have mentioned API access from the Cloud Management Platform that's where the Neutron plug-in is going to be communicating down taking the requests that are coming into Neutron which you're submitting via the Neutron command line client or some other API client or Horizon, whatever mechanism that might be it's taking those requests it's feeding it down to the controller cluster the controller cluster and also some management plane elements that aren't represented here but also are involved we'll then take that information pass that down to the hypervisors in this particular case I'm showing open source hypervisors we're running OpenVSwitch which is a you're probably all familiar with an open source project Apache licensed that supports programmable networking on Linux hypervisors and so we will interface with OVS and pass down the information OVS will then use the encapsulation protocol the overlay protocol there's a number of different protocols that are supported STT, VXLand, GRE and also not listed here but also a new one called Genev or Genev which we are developing in conjunction with Red Hat and Microsoft and Intel but those are the encapsulation protocols that are used in the data plane that's what allows us to decouple the logical networks from the underlying physical fabric so when you build your physical fabric you'll build it for scale so you'll do full L3 and you know possibly a spine leaf type of arrangement with your L2-L3 boundary at the top of rack and L2 only in the rack and all that kind of stuff all the sort of things that network engineers really love to be able to design but often are prevented from doing so because they have to maintain some sort of weird adjacency or connectivity and then the logical adjacencies the logical networks are built on top of that scalable L3 fabric we also offer these logical to physical gateways so where your logical networks which are encapsulated running one of these encapsulation protocols need to talk to the outside world because we all have workloads that need to communicate with other workloads outside of our OpenStack cloud I don't think any of us is fortunate enough to have everything running inside OpenStack just yet then we have these gateways and I'll come back and talk about them more in a moment but their responsibility is providing both layer 3 routed access in and out of the logical networks as well as layer 2 bridged access in and out of the logical networks and the APIs for the layer 2 gateways if you've been sitting in any of the neutron related sessions this week you know that the neutron project hasn't finished formalizing the APIs for the layer 2 stuff so that is implemented as an API extension supported with NSX so we offer that functionality but the full neutron project hasn't formalized how those layer 2 gateways are actually implemented yet but we offer layer 2 connectivity so this is really cool because it would allow you to bridge a neutron network with a VLAN outside on your physical network so they would be the same broadcast domain they would share the same IP address space it would give you a way to do IP mobility so that you could take a workload and migrate that or something of that nature into your OpenStack cloud and maintain its IP address and its connectivity but we also do layer 3 routed access which is far more common so using neutron logical routers and NAT or floating IPs we would be able to provide access to that as well alright so that's kind of a quick overview of the architecture in terms of kind of adoption and where we are right now OpenVswitch as I mentioned is a key part of the NSX architecture so this is something that an OpenSource project that NYSERA launched back in 2009 and it has since grown and seen a lot of growth it is a project that VMware still heavily invests in and we recognize that it is the foundation for a lot of the work that's going on in the network space the network virtualization space so pretty much almost all of the network virtualization solutions out there on Linux today in some form or fashion will leverage OBS they may not leverage the OBS Datapath they may leverage all of the OBS user space or they may be leveraging both the kernel Datapath as well as the user space the kernel Datapath is upstream as part of the Linux kernel it has been since version 3.3 of the Linux kernel and we continue to work closely with the Linux kernel community to push features into the Linux kernel to support the broader Linux networking community as a whole so OpenVswitch is important we continue to invest there and we have at last count or at least when this slide was produced we had 60 different organizations that were contributing code to OpenVswitch that included contributors from Red Hat Cisco, VMware, Citrix and others and the core committers to OpenVswitch earlier I think it was last year a gentleman from Red Hat became a core committer Thomas Graff is a core committer for OpenVswitch and then just this week they added Russell Bryant who also works at Red Hat Thomas may actually be at Cisco if I'm not mistaken I forget but either way so we've got some core committers that don't work for VMware which kind of again just reinforces the fact that we are doing this in conjunction with the community it's not something that we're off you're kind of doing on our own right 20% of our production deployments of NSX currently run under OpenStack and some of these production deployments and these are some of the customers who have publicly allowed us to refer to them as NSX customers these are some of these customers who are using NSX in conjunction with OpenStack and this bottom number just shows that we have some very very sizable deployments of NSX and OpenStack and in one particular case we have over 100,000 KVM VMs that are running in a single NSX deployment so it is scalable it is seeing traction in the OpenStack community and it is being developed in the open in conjunction with the community so let's talk about how we can deploy NSX with OpenStack what are the ways that you as an OpenStack administrator or operator or someone who is implementing OpenStack in your environment how can you deploy OpenStack in your environment what are the sort of the channels or the ways that we can go about doing that so VMware supports a lot of different ways of consuming NSX just as you have a lot of choice in consuming how you a lot of choice in how you consume OpenStack there is also a lot of choice in how you can choose to deploy NSX with OpenStack and so as a matter of example you know there are this spectrum of ways to deploy OpenStack in your environment you may choose to go with sort of the pre-packaged pre-configured route VIO is a good example of that you lose some flexibility because some choices are already made for you but in return you get some ease of deployment ease of maintenance ease of upgrades along that route and VIO is not the only one there are other companies out there that offer this sort of rolled up pre-done for you OpenStack piece you can also use the distribution packages that are available maybe you are going to go with a partner or an apprentice for example or you are going to choose one of the packages that is offered for you through a Linux distribution or Red Hat, a SUSE, a canonical something of that nature this may give you a little more flexibility in terms of how you deploy it and what you deploy it and some of the configuration settings but you still sort of have a vendor that you can go back to for example if you say hey I want to deploy OpenStack and I want to use canonical to help me with that then you can purchase support options and know that you have somebody you can go back to if there is an issue and then finally there is sort of the do-it-yourself I want to set up my own CICD infrastructure I want to run off of trunk or close to trunk I am going to do it that way I am not going to use distribution packages I am not going to go through a partner I am going to do it myself along the same lines we have different ways that you can consume NSX you can choose to consume NSX through something like VIO I will just mention it where it fits in here but you have already had a couple different sessions here talking about VIO in great detail you can also say hey I want to go back and I want to look at some of the partnerships that VMware has announced and formed with others within the OpenStack community and I want to deploy NSX in conjunction with one of those partners or finally you can take it the do-it-yourself route and all three of these routes are perfectly fine we don't you know let's look at these in a little more detail first what about using VIO this as I mentioned earlier sort of falls on the pre-packaged pre-configured category there is code already present to help with the integration of NSX I don't know if the VIO guys showed you that in one of the previous two sessions but when you go to deploy VIO there is a section that allows you to say here is the IP address the manager for NSX and off you go and it kind of does everything for you and it walks through its setup scripts it deploys all the pieces that need to be there it configures all the pieces that need to be there and they all talk to each other and off you go and that makes VIO a really great choice if you are an existing vSphere customer and if you have an existing vSphere infrastructure and you are interested in deploying OpenStack I would encourage you really look at it as a great option because of the fact that this is a pre-packaged offering and we are doing all the integration work that means VM work can provide end to end support for the entire piece so the hypervisor, the storage platforms the networking, NSX, OpenStack all the way through you get some nice features that I am sure the VIO folks have talked about really easy upgrades really easy deployments really easy upgrades including a rollback feature VIO 2.0 which allows you to deploy the new version and if you don't like that you can rollback to the previous version which is really really nice and because we are running in a pure vSphere environment as I mentioned earlier there are some things that we can do with NSX when it's only vSphere that we aren't yet able to do in multi hypervisor environment so this allows you to take advantage of for example the fully stateful firewalling that's available with vSphere or logical load balancing that's integrated into NSX so that's one route to go down if you are currently thinking of deploying OpenStack I firmly believe that you need a strong network virtualization solution to go with OpenStack and NSX obviously we'd love to have you guys choose NSX naturally if you are an existing vSphere customer I think going down the VIO route is a really great way to get started very very rapidly but there are other options as well and we fully support those so over the last couple of years since we have really been involving ourselves in much greater depth with the OpenStack community we have announced relationships with a lot of different partners in the OpenStack space so partners like Canonical where they will package up and include support for vSphere and NSX in their packages and then their support is coordinated with VMware so if you buy a support package from Canonical then they coordinate with VMware support to help you resolve issues right so that's one route for example we've talked about partnerships with Mirantis and their distribution and how again their distribution will include support for vSphere and NSX and back end support coordination HP is another example we are in discussions with a number of other partners right now and all of those are customer driven so as we have customers come to us and say hey we'd like to work with you in conjunction with let's say the company that's in the line or SUSE then we want to work with those partners and continue to expand our relationships so that that's another avenue for you to deploy OpenStack and NSX some of these partners may provide some advanced technical integrations some of them may just be that we're going to package it up and we're going to offer you support and then like I mentioned there's a coordination on the back end so if you have a support package with one of these partners say a Mirantis or Canonical for example we'll call them for support and then they will coordinate on the back end to help with any resolution of any NSX specific issues finally there is the do-it-yourself route right we have a number of very very large customers who choose to go this route and that's fine if you have the existing expertise and or the staff to support this sort of method most of these are non vSphere customers so these are customers who are running very very large Zen or KVM installations these customers have the internal expertise they build OpenStack themselves they might be deploying packages from a distribution but more often than not these guys are setting up their own CICD they may actually be active OpenStack contributors and therefore they have their own CICD infrastructure they are deploying patches into their own production environment as well submitting them upstream so they are very very deeply involved in Linux and in OpenStack very very deeply involved in how this works so they do it that way and we support that method as well in that particular case we don't support the full OpenStack piece because they're building it they're supporting it but we will provide support for NSX and the integration of NSX with OpenStack so we may be submitting patches on the customers behalf up into Neutron for example where we uncover problems in Neutron as a result of the implementation so that's another route so you know the whole range of options are open to you as you are looking at deploying OpenStack if you want to go the route of a pre-packaged appliance a pre-configured piece like VIO that's fine we can do that if you want to partner with somebody either from a professional services or intellectual property or packaging route, morantis, canonical on HP, platform 9, something like that then we work with those partners as well and if you have a sizable enough implementation and or staff and you want to go the full do-it-yourself route that's fine we support that as well so we want to support customer choice in how you consume OpenStack and how you integrate NSX with OpenStack so let me talk just briefly about a few examples of some customer deployments and again I did have to couldn't name these customers by name necessarily but we do have a very very large retailer that is going down sort of the pre-packaged route so they've chosen to use VIO and underneath VIO they're running vSphere and then they're running NSX they're using this VIO vSphere NSX environment to run their web presence in production so this is a very well-known brand name that is running their entire web presence on VIO and vSphere and NSX they're currently running around 5000 VMs on this installation all managed by OpenStack, VIO all running on vSphere and the networking and security all provided by NSX they anticipate growing obviously they're seeing a lot of success in their business so we'll probably see this grow by about I'd say 20% over the next year or so that's kind of what they're anticipating we have a couple of different financial institutions that are working with us these guys are at different stages of deployment so one of them is very very early in a POC but is already committed to a particular partner we're working closely with Morantis on this opportunity and so they're using Morantis OpenStack and be leveraging NSX with that so they're a little earlier in their deployment we have some other larger financial institutions that are farther along but also partnering a couple different opportunities there with HP with their Helion Group and some others and then as an example of the do-it-yourself route we have a couple of different options there but we have one service provider this is a full DIY installation they are in full production this is NSX with Zen server running underneath OpenStack so it's a very very large non vSphere environment and they're leveraging a whole set of tools open source tools in conjunction with their Linux hypervisors and NSX to provide services to their customers so this is some examples across a variety of industry verticals and examples of the different sorts of ways that customers are choosing to consume OpenStack and NSX in conjunction with each other alright so before I move forward with a look at some of the future features we're going to be adding are there any questions that you guys have from me yes I'm sorry I said that again multi hypervisor environment right so that's fine yeah don't worry about that so the question was around multi hypervisor was there a specific question I mean I've been talking at both points about how we fully support KVM and Zen I give you examples of customers who have deployed that we also have customers who are running only vSphere I don't not immediately running customers who are running a mixed hypervisor environment we run an internal cloud that runs both vSphere and KVM last time I checked we were somewhere around 300 hypervisors both KVM and vSphere running under NSX and managed by OpenStack but the operational challenges of running a mixed hypervisor environment often customers will choose not to go down the route maintaining multiple images for the hypervisors maintaining metadata and glance to know which image goes to which hypervisor and stuff creates a lot of operational challenges but the idea of running a mixed hypervisor environment is something that you can certainly do with NSX does that help? Great other questions before we move on just going to shield there so I can see if anybody's hand is up okay great all right again if you do have any questions or if you want any additional information if I'm able to provide additional information I'll be happy to do that just catch me afterwards and I also have my contact information on the last slide you're more than welcome to email me or hit me on Twitter whatever works for you okay so let's talk about some of the things that we have planned for a future release of NSX now everything that I'm saying here is committed to a future release but we haven't provided any dates on when this future release is going to hit right so you can't go back to your boss and say but Scott promised that it would be here at this time because I'm not promising you that okay we anticipate availability for this release early next year but again you know there's the whole sort of you know lots of things may change between now and then right but these are the features that we are currently projecting to be able to deliver in that future release I'm going to list them first and then we'll talk in more detail about each of the features so the first thing up what we're going to do is we're going to we're going to work on improving our multi-hypervisor support and I'll talk about that in a little more detail in just a moment it's not really sort of I've talked about it some here it's not really a secret that you know there are some things we can do when we have a pure vSphere environment and NSX that we can't do when we start putting into our other hypervisors right I talked about the distributed firewall for example and so one of the things that we are really shooting for in this upcoming release is improving that multi-hypervisor support and bringing additional parity to what we're able to do to non vSphere environment that's one and I'll talk more about that in just a moment we are also going to be addressing some issues in scaling our management plane our control plane is already a scale out control plane so we use some advanced clustering mechanisms and a consensus algorithm if anybody's interested it's the Paxos consensus algorithm you can go look that up on Wikipedia and you know to blow your mind on how it works but that is our control cluster our central control cluster which is already scale out but we didn't have a sort of scale out management cluster and so one of the things we're aiming to provide on in this upcoming release will actually be a scale out management cluster so that will allow you to scale the control plane and the management plane and be able to scale independently of one another right so that if you are seeing lots of API requests scale out the management plane without having to also scale up the control plane or vice versa so that's really cool we're going to be improving our logical to physical connectivity I'll talk more about that in a moment so we're adding some additional options for improved performance on the logical to physical connectivity and then also we're going to be adding dynamic routing support for neutron logical routers so this will mean that you can create neutron logical routers and have those neutron logical routers exchange dynamic routing protocol information with your physical routers so that you can have networks in OpenStack that are essentially routable networks and are visible in the routing tables if that's what you wish to do right you can do this today with static routes so we already offer the ability today in NSX to say here's a here's a neutron logical network and I want this logical network to be passed out to the other network and I don't want to perform NAT so in other words I want to take this address space that is assigned to this logical network and I want to just represent it out on the rest of the network I know I'm a geek but I actually do this in one of the logical networks in my own OpenStack lab so I just have a subnet off of my overall routing table and that is a neutron logical network and then what I have to do is program a route to say that this subnet this route is available through this neutron logical router right what this will allow us to do is actually use BGP to establish peering relationships between neutron logical routers or some sort of entity it may not be the logical router itself but a BGP speaker on behalf of the router since routers may come and go and then have those exchange routing information right there is an effort I don't know if any of you saw it it was a session the end of the day not yesterday day before yesterday so today's Thursday that was Tuesday there was a session on some of the work that's going on in the neutron community around being able to add BGP routing support I mean so that's an area where we'll be working with them to to kind of standardize that functionality as we bring into NSX so let me dive into a couple of these in a little more detail I'll start with the multi-hybridizer support so again I mentioned you know there's not really a big secret that we have these differences in functionality between what we can provide in a pure v-sphere environment versus what we can provide in a non-v-sphere environment and part of that has been because you know as the company who also provides the hypervisor we can add functionality to the hypervisor perhaps sometimes more quickly then we can also add features in open source by working with the community now that's not you know I'm not knocking one or the other just different modes different ways of a development model right each of them has their advantages and their disadvantages but one of the focuses for this next release of NSX is taking some of these features that we were able to add in v-sphere and now we've invested a lot of time and a lot of effort in making them available in the open source community as well and one of these examples is the distributed firewall so this is one that in the next release of NSX we'll be able to give you a distributed firewall which is a fully stateful firewall L2 through L4 on KVM right not just on v-sphere but also on KVM and NSX will manage the rules across both hypervisors so that when you do have a mixed hypervisor environment you can define one set of security policies and it'll apply to wherever the instance lands what we've done to do this is we worked very very closely in a number of different communities one we worked closely with the OVS community we had features and functionality to open v-switch that allow open v-switch to integrate with something called the connection tracking module in the Linux kernel now the connection tracking module in Linux kernel is the same module that IP tables uses so when you create some IP tables rules that say hey I want to allow this and I want to allow related or established connections I want to maintain state that's actually being done by the connection tracker to the kernel module and so what we did is we worked with the OVS community and the OVS developers and committers to add extensions to OVS and extensions to OpenFlow that we hope will eventually make it their way into OpenFlow proper but in OVS is implementation of OpenFlow that allow it to integrate with this kernel module and then we also worked with the Linux kernel community to update the open v-switch kernel module which is part of the Linux kernel to support that stuff from the OVS piece and so this all got merged up it's already upstream in the Linux kernel it's going to be part of the 4.3 kernel that will be officially released and so in the 4.3 kernel there will be support in the OVS kernel module to do connection tracker based rules in OVS which means you can write rules for OVS that will allow it to leverage the connection tracking state that is maintained by that kernel module to allow in port 22 and related or established connections for example where we're actually maintaining and tracking the state of connections inbound and outbound to the firewall this is the same thing by the way that IP tables does but what this allows us to do is to bring it to OVS and so the reality is because it's being done in OVS anybody who leverages OVS actually gets this functionality we believe it's necessary and it's an important part of what the community has a whole needs but it will also find its way into NSX so we're real excited about that and that's a big feature one of the other things in terms of improving our multi-hypervisor support is that there is an OVS port that is currently underway to Hyper-V we're working closely with a company called Cloud-Based Solutions they're based in Italy and they've been working very very closely on bringing Windows into OpenStack which is predominantly sort of a Linux story and so they've built tools like a cloud and knit piece for Windows which allows you to use cloud and knit and the instance metadata to customize a Windows instance which is very cool but the other thing that they've been working on as part of the OVS community is actually porting OpenVswitch to run on Hyper-V they've already released a beta of that it comes with the full graphical installer where you click next next next on a Windows machine which allows OVS and then you get a set of command line tools to configure it and once that kind of is fully baked and fully ready then this will give us an avenue to be able to bring Hyper-V support in for NSX this isn't kind of fully committed yet because we're still working through the OVS port but we are looking forward at that as something that we want to do so any questions about this before I move on? I have a microphone, it's okay I'll repeat the question okay, great so the other thing that I wanted to talk about here is the high performance logical to physical connectivity so I mentioned earlier that NSX offers these gateways that provide these logical to physical connectivity so they sit at the edge of your logical network or the edge of the physical network where this edge between where that cloud sits and where the rest of your stuff sits whether it be virtualized on traditional hypervisors whether it be bare metal whether it be whatever they sit at the edge and they're responsible for taking the overlay network that is used by NSX using an encapsulation protocol unwrapping that and putting it on to the physical network and then taking traffic from the physical network and then determining where that traffic needs to go to which tenant does that traffic belong and then passing it on into the cloud in our current solution we offered a couple of different options so when you're running in a non vSphere environment you could run these things bare metal so we would give you code that you would install directly onto a server and it would run right on the metal so no hypervisor required and that would create a gateway out of that out of that server and it would start acting as your device and then we had some logical abstractions on top of that where you would host multiple logical routers on that and then we had failure zones and all kinds of stuff to make sure that this is all redundant and scale out right? If you're running in a pure vSphere environment we only gave you the option to run it as a VM and NSX sort of spins up that VM and it manages that VM and it deploys the VM for you and that's it and what we're really excited about being able to do is in the next release actually give you both options on either side right in other words whether you're running in a non vSphere environment or in a vSphere environment or in a hypervisor environment you'll have your choice of being able to deploy these gateways as physical workloads or as virtual machines or as a mix so you'll be able to say hey look I might have some customers that really really need extremely high performance I want to stick 40 gig nicks in these guys for example maybe that's a use case where you need a bare metal gateway you may have other use cases so the consumers where that throughput isn't quite as necessary and say okay you know 10 gig connectivity is fine or multi gig connectivity is fine let's deploy this as a VM or as a cluster of VMs that's fine right so both form factors are going to be supported regardless of which form factor you choose what we'll be incorporating is support for something called the Intel Data Plane Development Kit or DPDK this is a hardware offload mechanism that was developed by Intel that allows you to offload a lot of the packet processing that occurs onto the underlying CPU and this gives us very very high performance even when it's at very small packet size small packet size is kind of the Achilles heel for software switching right if you know it's one thing to say I got a 1500 byte packet but it's another thing entirely when you're looking at 64 byte packets now in an open stack environment you're primarily looking at 1500 byte packets right maybe 9000 because you went jumbo frames so DPDK will offer some great performance benefits it's when you take that sort of stuff and use it in more of an NFV oriented environment where those smaller packet sizes are far more prevalent that you'll really begin to see some huge performance improvements the other thing that you'll be able to do is use ECMP and what this means is you'll be able to take a cluster of these gateways and create active active active uplinks out to your physical network right and then assuming and this is the caveat with ECMP like ECMP is not the freebie that a lot of people describe it to be but assuming that your packet your traffic distribution allows you to leverage all of those uplinks equally then you'd be able to be able to pass multiple 10 gig interfaces worth of traffic in and out of the network at line rate we've talked about doing like up to eight links so 80 gigs of throughput in and out of these logical gateways which is pretty significant right now again I made the caveat that it depends on your traffic flows right one to one traffic flows like one instance in your cloud talking to one server outside your cloud it's not going to do it ECMP is not going to do anything for it any vendor that tells you that ECMP is going to fix that is off their rocker because ECMP only takes only helps when you have multiple traffic flows that's just how it is but nevertheless it does provide a great way of scaling up the traffic when you have multiple instances on your logical network that are exchanging traffic with multiple endpoints outside the logical network so any sort of many to one one to many or many to many traffic flows will all benefit from ECMP all traffic flows one to one as well as many to many or many to one will benefit from the enhanced hardware offload that DPDK will be able to provide some of the stuff that we're talking about which I think is pretty cool so that's really all that I have I'll be happy to address any questions that you may have at this point feel free to stick your hand up or catch me afterwards and since you guys know that we're asking questions I don't need to do that slide up here's my contact information you're more than welcome to contact me if you would like I know a lot I'm based in the states and I'm here in Japan this week and in New York City next week and in California the week after that so it may take me a few days to respond to you but I will get back to you and if you have any questions feel free to let me know but otherwise I will go ahead and let you guys get out of here move on to your next session I'll stick around for a few minutes off to the side here if you have any other questions I'd be happy to address those thank you very much for your time


What's up everyone it's your girl Kenzie here from Layton sports cards, and I'm ripping a personal for Troy a we've got a 2022 Panini select UFC Holly box that's the block here Troy Let's see when get you It's like the price We've got a Shogun Rua on the red auto light heavyweight division That is 17 of 99 And Paul Craig on the rookie tri-color concourse B base Max Holloway and new silver of Usman and a Pennington silver Ormson finally scored Max Holloway Peterson we've got Puellis on the rookie tri-color premiere level Lasvich Alice we've got to 49 a Giuliana Penya nice one there for you Troy on the blue octagon action signatures And yeah, I still can't believe she beat Nunez The first time and we've got lime green of Glover Tex Terra. That is 41 out of 49 They pull a lot of greens lately, too It must be a good case I would say so silver rookie of Taporia Murphy rookie McMahon We've got in Ganyu on the octagon side and scope rookie Austin lingo. Well, we've got a boob car Nirmagomed off tease Gary a sterling tri-color concourse To share of what did I say? Yeah, I knew that there's a baseball player with the last thing That's right. That's St. Pierre and bronze rookie Tucker Lutz The featherweight 163 of 175 Now you just have to remember that Conor McGregor Paula Costa, Poirier. We've got silver of Cunitz Skya, Cunitz Skya, Cunitz Skyla. I'm trying I mean, I feel like I know that usually like the top top fighters how to say their names There's some that's still tricking me up though. Got Jorge Mazadol on the silver patch there. Nice They smash with all Santos silver John Jones scope rookie of Tallulah Talia Santos And last pack here for you Troy We've got Joel Alvarez rookie octagon side and light blue rookie of Quarantilio Alrighty Troy that will do it for your box. Thanks again for hopping in and we'll get this right out to you


So, welcome to this lecture on advanced digital system design in the course digital system design with PLDs and FPGAs, in the last lecture we have looked at how to go about designing a complex system like a CPU. We have taken an example of an 8 bit microprocessor, we have said that it cannot be designed in a flat way in one shot, it has to be partitioned into the functional blocks which requires domain knowledge and we have to decide on the interface between this block. Then at the next level I mean at that level top level we have to decide the function timing all that, at the next level we will handle each block separately and try to design and go to the third level and when we are kind of we end up with the known blocks like registers multiplexers and counters, then we can stop you know that the neat way of designing. In the industry we call it RTL design, the same it is same what I am talking about. So, we have looked at the example of the CPU we have seen the level 0 block diagram level 1 partition and then for the level 2 we have picked up 2 blocks, one was the register CPU register which is fairly simple. Then we have taken a program counter and designed it in detail and we have also discussed the division of the data path and the controller to bring clarity. So, that is what we have covered in the last lecture and today we are going to look at the behaviour of the controller and we will try to from that behaviour from that idea we will try to kind of come out with the structure for the controller and look at the properties and check what a whether a generic architecture which fits for all cases whether we can come out with such a thing. You know from this we are working out little bit backwards from an example to the basic normally in a textbook the other way is done and which is sometime difficult to kind of understand at the beginning because we learn something formally the structure and you try kind of later on apply or sometime the textbook does not show the serious application it only deals with very simple cases and then it does not bring clarity that is why I am kind of going from an example and kind of working backwards and that brings clarity so that is the idea. So, before turning to today's part on the controller we will have a brief look at the last lectures part then we will move on to today's part. So, let us move on to the slides of the last lecture and so we have looked at an 8 bit microprocessor but the thing was that it has 8 bit ALU data bus 16 instruction 64 address space 64 kb address space which means 16 bit program counter and stack pointer the controller is hard wired on microcoder no separate IO space and so on okay. So, and we said that we have to partition this in the blocks with interfaces we have to do a top down design at each level we have to handle the functional timing and the electrical aspects of it and so we have looked at the top level which is CPU with clock reset interrupt as input read bar write bar address as output and data as a kind of bidirectional pin and we said this is a kind of we have decided now you have to decide on the functionality we said this is there is no kind of pipelining. So, it fetches then decodes execute then it goes and fetch it so it makes it multiple clock cycle CPU for one instruction to execute it takes multiple clock cycle it is not very current design you know the current nobody design like that the CPU can be designed for a single clock cycle operation in most cases. So, but we are just trying to kind of grasp the basics so we stick with it and when it comes to the timing spec and of course you have to decide what are the instruction which are supported what is the instruction format and so on. But we will not get into that kind of detail and our idea is in the process of you know design how the design process goes on and this you can refer to some book good reference book some books on microprocessor or you can computer architecture there is a good book by Hennessy and Patterson on computer architecture two volumes are there both deals with the CPU design in detail and here the clock reset interrupt as some basic timing the clock may have some duty cycle the frequency the reset as some timing interrupt will have you have to decide whether it is a level triggered edge triggered or both and what is the timing pulse width and so on. And one important timing detail is the bus cycle how this bus is kind of behaves whether it is synchronous or synchronous how many clock cycles it takes and so on. So, and these are the and the electrical spec because these are to kind of support lot of load and this should have enough sourcing and syncing of the current and we have seen the second level of partition level one wherein there is an internal data bus, instruction register, decoder, temporary register, ALU, set of registers, program counter and stack pointer. Everything is connected to a single bus in the current high performance CPUs it may have multiple buses so that and all the high performance CPUs will have multiple buses that means the registers can feed the ALU, ALU can feedback the register. And while that is going on instructions can come on to the instruction register and so on okay or an instruction fee 4 or a queue. So, so many things can go in parallel and that will be synchronized and so on. And we said there is a difference one is a data path where the data moves or the computation happens and there is a controller which sequence all the operation okay. So, this partition is very good because when you functionally partition it you do not have to worry about the sequencing of operation. You can concentrate on the functionality concentrate on the interface and the timing details can be worked out later you know like in what sequence these condo signal come that can be decided later. And the controller job is to give the sequence operation give the condo signal latch signal enable signal and select a max path to enable data into a particular path and so on. So, that is a job of the controller and we said in a synchronous case you need only one controller if everything is synchronous. But if there are kind of two concurrent activities which is not synchronous to each other then you can controller to handle two concurrent activities which are not synchronous okay. And but in any case in a very complex scenario it is very difficult to manage with a single controller for modularity ease of designing and debugging and testing and all that it will be ideal some time you have multiple controllers handling the multiple parts and a top level controller coordinating with the bottom level controller. So, as in a top down approach you can even imagine you could have the second level partition some of the blocks together having you know separate controller and so on that can be thought of one can think of a hierarchy of controller. So, there is a top level controller which is you know coordinating the second level controllers and so on. So, that is a data path and controller and we have picked up an example of a register and we have designed it seen the design in detail. So, the idea of register is that it should be connected output should be connected to the data bus when it is enabled the data should come. Similarly, when the latch signal from the controller comes and the clock comes the data get latched and we have seen a kind of circuit for that say this is a possible circuit 8 flip flops clock is common and input and output is connected together through a tri state gate to the same data bus. And the clock and the latch signal is ended together so that when the latch signal comes only then the clock comes. So, at this level we know all the components flip flops and gate and registers the design is over ok. And that can be coded in a VHDL or verilog things like that but as the node says there is a little timing issue with it because we are ending it with not proper there could be multiple pulses here and we will see that later you know that issue can be handled later. So, there is another possibility which avoids it that means you do not do anything with the clock path clock goes continuously and that is problematic because every clock the data gets latched so we have to take care of that. So, the idea is to put a 2 to 1 MUX and when the latch signal comes the input goes directly when it is 0 it is recirculated ok that is a basic idea. And the next thing we have looked at was a program counter which has various operation the data when a jump or a call comes the address has to be latched in you know byte by byte when there is a call the return address is stored back again 16 bit register byte by byte it has stored back and then the latch signal. So, there are 2 8 bits registers inside which are separate I mean this has to be handled properly there are different input path one is from the data one is an increment path one is a reset address one is interrupt address. So, that is this input select output select is when the both address need to be transferred to the data bus you have to select byte by byte. So, that is the address output select then they enable for the output to be connected to the data bus and that drives the address bus and we have seen a possible design. So, you have 2 8 bit registers which has latched same latch and we have a temporary register to transfer the least significant byte because the address come least significant byte first and the most significant byte. So, first it is transferred which has a latch signal separate from the controller then when the MSV comes this particular green path is selected and both together this least significant byte and the most significant byte coming on the data bus is latch simultaneously on here. So, the latch signal is common for both and when it is need to be incremented it is incremented this way and this red and blue path is selected and is latch packed. When the reset comes this address is loaded parallely interrupt comes that is loaded and when the program counter output need to go to the data bus this particular MUX operates with the enable and this is the address bus being driven by the program counter. So, it basically means 3 8 bit registers 2 4 to 1 8 bit MUX 2 I mean 1 2 to 1 8 bit MUX 8 tri-state gate and 1 16 bit 2 to 1 MUX the design is over this can be easily coded ok. So, that is how we design and we said so, essentially it has to be top down design any complex system and you should have the domain knowledge and you should at each level you have to look at the functionality timing electrical characteristics may be power dissipation where it is critical. Nowadays everything most devices are mobile or which can be kind of transported and that needs a battery and which is better if the power dissipation is controlled. And there are many devices now sensors which is kind of installed in one place which is which is supposed to work over long years. So, the low power dissipation is very important. So, let us come to today's part today's part we are going to look at the controller this part what is the behavior of it what is the structure of it may be possible an introduction about how to go about designing it you know that is our focus today. So, for the sake of illustration let us take an instruction ok. Because basically a CPU is executing instruction and depending on the instruction these control signals are generated ok. So, now I am going to take one instruction ok. So, but that can be extended to similar instruction and other instruction. So, I am only kind of discussing a part of the game, but that is enough to capture the idea. So, let us take an instruction like add A and B ok. That means we are essentially adding the content of the register A and the content of the register B and putting the result back to the content of A. So, it is a kind of two operand instruction like the indel assembly language instruction or the machine language instruction where when you say add A B it is nothing but A plus B is loaded to A ok. So, let us see what happens when such an instruction is executed. So, it is simple you move the content of A to the temporary register then move the content of B to this temporary register 2. Then you give select the ALU operation that you say that it is add operation ok. You can imagine there are multiple arithmetic and logic units doing computation which is all parallel which is MUX through a MUX and you can think of this as selecting the path in the MUX ok. This is a select line of the MUX which is choosing and the connecting the output of the appropriate block to the output of the ALU ok. And this enabled is a tri-state gate because only one device can drive the bus. So, that has to be enabled when the result is. So, you give the operation selection then you enable it then register A is loaded with that result ok. So, that is a kind of macro step of adding A and B. But let us look at little more detail because our idea is the controller has to generate appropriate condo signal. So, we have clarity in terms of the condo signal ok. So, the first operation is moving the content of A to the temporary register 1 ok. So, what we need to do is that we have to enable the register A output. So, you give A1 to register Ae which is register A enable then the data comes on the data bus ok. And that goes to all inputs all the register input goes. But then the controller has to give a pulse to the TR1L which is a temporary register 1 latch signal. And it has to be in synchronous with the clock very important then the clock edge comes and the data gets latched ok. Unless it is not synchronous it is not going to happen. So, when it is 1 when it is high the active clock edge should come ok that should be taken care. And then you disable it ok. So, that is the game. Now I can tell you a very simple idea. So, what we should do is that we give a pulse to RAe and we can give the same pulse to the TR1L assume that it is synchronous with the clock. Then the A value is enabled because it is a pulse and it comes here and the clock edge comes it gets latched and the pulse goes to 0 it is disabled ok. Similarly, you move the register B content into the temporary register 2 enable A give the same pulse to the latch signal clock comes it gets latched and when the pulse goes 0 this is cut off ok. Now specify the add operation and that can be some bits from the instruction directly there is may not be kind of decoding is not required you can kind of maybe you can kind of you know encode if you need in another fashion. But may not be required same pattern can be given here from the opcode and that can select the operation or there is a kind of a further encoder which encodes into some less number of bits which can come here and select this operation. And this is enabled after a clock period after a wait and this is enabled and that same signal is given to the register a latch same signal means the controller will generate at the same time another signal of the same timing. And so it is enabled and on the active clock edge that is latched and when the pulse goes 0 that is disabled and the add operation is done you know. So A to TR1 B to TR2 add operation enable and the result back to A. So enable is given a pulse latch is given a pulse upon the clock it is moved it is disabled. Register B E is given a pulse TR2 L is given a pulse and upon the clock it gets latched here and that is disabled. And this is given a selection this is enabled same pulse is similar pulse is coming at the latch signal and the data comes here it gets latched and it gets disabled automatically. So that is a kind of sequence. So I have written that here in detail move A to TR1 move B to TR2 ALU operation wait and ALU output register A okay. So now what I am showing is I am showing a possible timing waveform which will achieve this. So assume there is a clock you know going like that which is a say assume a square wave clock. Now this is the timing okay these are two separate output instead of you know drawing it separately I am showing it together. I mean this is separate output coming from the controller this is not the same signal do not assume that it is same signal it is two separate signal with the same pulse okay. So A enable and TR1 L gets similar pulses like it comes with the delay with respect to the active clock edge like that. So at this point the data is A is enabled data is flowing on the data bus. So it has enough time before the active clock edge comes. So if you go back to this like when you enable something it takes some time for the tri-state gate to get enabled and propagated and set up at the input of the register then only the clock can latch it. So that is taken care of by this kind of timing. So we are enabling it here at this point data start flowing and it will be ready at the input and when the clock comes data get latched and the output is disabled okay. Similarly the B is enabled at this point and in the temporary register 2 it is latched and B is disabled. And I am not specifying the early operation but that can be taken from the opcode with an encoding if needed. And this is ALU is enabled and the ALU is enabled and that data is coming here and gets latched to the A and it is disabled okay. So this symbol scheme achieve this operation instruction add A, B okay. Now the question is of course you know there are other instructions and one has to maybe if say you can imagine say add BC add AB everything is same. So all that can be easily captured by this behaviour maybe subtract again things are same only thing is that the subtract operation is different. So the controller which is designed the part of the controller which does this can be generalized to do many other things okay. So that is the basic idea but for you it might look little convoluted that I am kind of orchestrating a scheme very clearly I am pushing the edge little bit to the right hand side so that you know the clock edge comes here. But you will see that what we practically come out with will match this at this point you take it I mean you may think it is a kind of manipulation but it will turn out to be true correctly like the structure will mimic this behaviour okay and also you should know that we are kind of going to have everything in terms of integral number of the clock cycle okay. So the basic unit of control is a clock period okay nothing less than that. So we will have a pulse of at least one clock period not half clock period. So everything will be decided per clock cycle that should be kept in mind. Now the question is that can the controller be a combination circuit okay because we have studied combinational circuit and sequential circuit. So we know that for a combinational circuit if given an input say n input it can produce an m output but it cannot definitely produce given an n input to a combinational circuit it cannot produce a pulse like this you know every clock like for 3 clock periods. So this controller cannot be a combinational circuit it has to be a sequential circuit okay. It is like given an input it generates a sequence of pulses okay. In this case it looks very neat one pulse then the second pulse and third pulse and so on. So the question is that what type of sequential circuit can generate such a pulse okay. Like the answer is that unfortunately we have studied only the counter now synchronous counter. So I want to straight away ask can we have a synchronous counter generating this kind of pulses you know that is the question we are asking can we use a counter to generate timing pulses. A mode 3 counter like we have a counter which is designed like this you know you have a state flip flops which is decoded with the input to generate the next count. Can we have a counter generating a mode 3 counter generating this kind of pulses okay. So like this thing and we know that a mode 3 counter will count 0 1 and 2 and it has 2 bits okay. But what we require is separate outputs okay. Now so why not we decode this particular pulse from that 00 count okay and we decode this 2 pulses from 01 and we decode this 10 I mean these output from the count 10. So that is the basic idea. So we take a counter and what we do is that we do not need 00, 01, 10 we need some outputs. So what we do is that we put a combinant circuit here and we generate the output as a decode of the state here okay. So when it is 00 we will generate 2 outputs 01, another 2 outputs 10, another 2 outputs okay. Now we have to design this output logic this is called output logic which the input is a present state and the output is the various outputs we need. So we can write the truth table for the output logic in this case. So we have input which is present state in this case 2 bit Q1, Q0 and there are 6 outputs okay. I said for convenience I have shown these as together but it has to be separate because luckily in this case these are similar pulses. But if you are adding B to C then the TR1 latch and the B will have the same kind of pulses. So it has to be separate. So we know that in 00 at least for this case these 2 as 1 in 01 this register B enable and the TR2 as 1 and in the 10 ALE enable and the register A latch as 1 okay. Now it is very simple for each output you pick up 1 form the minterms in terms of Q1, Q0 optimize it come out with the equation. So like for an example we take this register A enable that you will get as a function of Q1 and Q0 which is a present state similarly you can work out for all other 5 outputs. So we can say output is a function of the present state you know. So the output is decoded from the present state and then we say output is a function of the present state okay. So that is how we generate this timing process it is complex because we are only considering now one instruction we have to kind of combine all similar instruction and there may be this mode 3 business may not work it may have to count in a very complex way making branches and so on depending on the various inputs. So you can imagine these are various instruction various group of instruction these inputs and depending on that it will make lot of transition and each transition is decoded each state is decoded to produce the output by this output logic. So from a counter we have graduated to a next level having another logic at the output which is decoding the present state and producing the various outputs okay. Now you see I have the before coming to this part this kind of delay now that this enable and the latch is delayed by some time with respect to active clock head looked artificial. But now you look at the diagram we are putting a logic here. So the clock comes and this present state will change after TCQ time delay. Now the output will come after the clock head after TCQ and output logic okay. So when you implement when you use such a structure to generate this kind of outputs then you can see that there is a delay with respect to the active clock head which is nothing but TCQ plus T output logic. So everything will be delayed and which is required unless it is delayed this edge cannot you know latch the data. So it is very important that there is such a delay and that is automatically achieved by this particular structure okay. Now the next question is that we have come out with a structure which is an extension of a synchronous counter. We have added an output logic to the synchronous counter the next question we ask is fine it can do add A plus B can it do everything what we require. You know can we generate whatever timing signals required say example let us forget about particular instruction let us pose a question that okay. Now the register A enable and TR1L has a different pulse shape or a timing. So at the first clock period it is high then it is 0 then in the third clock period it is high. Similarly for the second set it is high for consecutive 2 clock cycle which is second clock cycle and third clock cycle. Let us forget about what instruction it implements I am only pausing a hypothetical question you can form any kind of pulses okay. The question is that can we generate whatever timing signals required. So if you look at this particular structure we can say very definitely yes okay because we are decoding the present state.  So then that is done. So it is very simple that yes it is possible A register A enable is nothing but Q1 bar Q0 the 00 or say Q1 Q0 bar that is 1 0 okay this is 00, 01, 10. Similarly when you come here it is nothing but 01 and 10. So you get equation for that register A enable in that case is Q1 bar Q0 bar Q1 Q0 bar which will be kind of you know you simplify to Q0 bar okay. Similarly register B enable if you look at this it is Q1 exclusive or Q0 bar. So what I want to convey is that this particular structure is very generic you know whatever may be the timing requirement in terms of clock period this structure can generate it you know you do not have to worry saying that the instruction is different or it is a very complex thing it is something to do with the program counter the call has come. So the current address has to be pushed to the stack new address need to be stored how this can be how this is possible and all that okay. So maybe the diagram I have shown requires some modification for little bit modification probably I do not know maybe some shadow registers are required but whatever it is it can be done from a controller perspective number of it requires to generate different type of pulses and this structure is able to generate it. So what it comes to is that when you talk about a controller this structure or this architecture is very generic it can be used for as used as any controller like you have a multiplier you need a controller and then this can be used only thing is that depending on the application this next state logic will change because depending on the input and application this transition will change and at each state the output a number of outputs and the timing of output will change so this logic will change. So depending on the problem depending on the timing this next state logic will change output logic will change number of flip flops will change the transition will change but we can say this is the architecture of a controller. General architecture of a controller only thing we have to decide for a particular problem is this how many bits are required what is the next state logic what is the output logic okay. So that is the conclusion. So this is called a finite state machine because this machine goes through the finite number of states it transit through the finite number of states in a complex way it is not that it likes a counter it can take branching decision it comes to a state then depending on an input it can go branch to a one particular state or branch to another state another set of states and so on okay. So the transition can be complex unlike in a counter so that is it it is very generic the next question is that is a counter need to be ordered is a state in need to be ordered that means we said for add instruction we said it count 0 0 0 1 and 1 0 does it have to be ordered can we count 3 0 and 1 or a 3 0 and 2 yes it does not matter it can transit the state does not matter because we are worried about the output and given some set of inputs we need a sequence of output and we do not care too much about how this counter part keep track of the state as long as it is distinct state for each step then we can decode accordingly. So it is not very important how the state particular numerical value of the state okay need not be very ordered it can be arbitrary so that problem is called state assignment okay. So we care only about inputs and output state can be assigned with useful values and that could be of some use okay. Maybe question is that if you assign the states in a particular order maybe this logic get minimized or this particular logic get minimized okay. So the state transition the numerical values are of no consequence we can decode we can change the decoding of two table of next level logic and two table of output logic to reflect the state you are assigning the designer is assigning and as I said it can be assigned to reap some benefit out of that assignment like having the minimal area for the logic and so on okay or to solve some timing problem okay. And so what is what it means to design and as I said this is called a finite state machine or FSM okay. So that is the expansion of this finite state machine. So basically it means that you have some inputs depending on the inputs the transition happens state transition happens because in an add a b instruction we have three states which is transited and each state generate some output. So this is the specification okay this is the algorithm and we while designing at the end of it we design this next state logic and output logic. So the what it means to design an FSM is that you have a specification of the input the state transition and the output or the sequence and then from there you come and design the next state table and output table okay. So that is the basic what it means to design a finite state machine. So the basic finite state machine or controller is nothing but a finite state machine idea is that there is a counter part which go through various states it is a material whether it goes through in a particular sequence and states are decoded to generate various pulses to control the data path okay. Maybe this control signal will select the MUX give a clock signal to a latch will enable clock to a register, increment a counter and so on okay that is what these output signals are used for okay. They do the sequencing operation of the data path like as I said enabling something in the register, incrementing a counter, selecting a multiplexer path and so on of course these are the important thing we do with the sequencing pulses okay. So let us come back to the slide so here we look at this particular architecture and you see here the output is generated as a decode of the present state okay. Now in some cases it is convenient we will see that later what is the advantage of doing that or when we can do that. Sometime it is convenient to generate the output not only as a decode of present state but as a function of both present state and input. So you can imagine this input is coming here and you decode the output as a function of present state and the input okay. So it may happen that some outputs are decoded from the present state, some outputs are decoded from the present state and the inputs okay. Now when you decode an output from the present state it is called Moore machine or Moore output this is after the mathematician Moore and when you decode an output as a function of present state and input then it is called Milley machine okay. So we have two types of output one is a Milley output when output is decoded from the present state and input a Moore output when the output is decoded from the present state only. So we can modify that earlier architecture or structure that where the output logic gets not only the present state but also the inputs okay. So we say here when you say the decoding the next state logic decode the next state as a function of present state and inputs and the output logic when generate some outputs as a function of present state which are called Moore outputs and the output logic decode some output as a function of present state and inputs which is called Milley outputs okay. Now I should mention that most of the textbooks you have studied in the undergraduate program talks about a Milley machine and a Moore machine okay. It is kind of very kind of simplistic view many a times you would have noticed that the finite state machine you have kind of seen example is just with many a times one input and one output okay. In such a case it is very easy to call the Milley machine because there is only one output which is Milley output or one output which is Moore output. So you can call a Moore machine and a Milley machine but in practical cases the controller or state machine has lot of inputs lot of outputs. So you cannot call kind of you know Milley machine and Moore machine because even if there is one output which is Milley then you will end up calling that the Milley machine that could confuse the design. So let us keep this kind of distinction. Now one thing to notice is that now you look at this next state logic it the input to the next state logic is the present state and the input and it decodes the next state okay. Now if you look at the output logic the input way there is a present state and the inputs and it decodes output okay. Now why do not we like if you look at the inputs are same. So why do not we combine this together in a block and we call it logic the output of the logic is next state and the outputs okay. So we get a two block view which is nothing but we are combining the next state logic and output logic. The logic looks at the input and the present state it decodes the next state and is also decode output. So it is a very useful view because for when we analyse the timing when we do the VHDL coding this kind of three block view and the two block view is useful because when we analyse maybe while doing the timing analysis this is easier to look because it is much simpler it captures all the kind of data various paths together and when you VHDL code maybe you will code this separate and this separate but there could be advantage in coding the logic together in a various ways. So these two views are very useful please keep this in mind and these two views and as I said any finite state machine the architecture is same only the logic differs depending on the application depending on the input output timing the logic changes and the number of flip-flop change transition change the architecture essentially remains same okay. So that is the description of the two block. Now let us look at the timing issue of the state machine the finite state machine we will use the two block view because it is a much more kind of concise. So one important thing to look is that there are now two paths from a register output through the next state logic to the register other register or the same register we cannot say like if there are three flip-flops three I mean three inputs three output then there could be nine three into three nine distinct path maximum okay. But very important thing to notice is that there is another path from the through the flip-flop through the output logic to the output okay. So when we consider the maximum clock frequency if you consider only the clock to clock it is not useful because the clock comes then it propagates here propagates here and the setup time is met say we say tcq plus t next state logic ts should be kind of less than the clock period or the clock period should be greater than this. But suppose if the tcq plus t output logic is even greater than that the transition will happen correctly but the output would not appear at the output. So what I say is that we will say the clock period the minimum clock period should be maximum of the tcq plus t next state logic plus t setup time comma or tcq plus t output logic because output has to appear at the output okay. And normally in most cases if it is kind of close together we can imagine that this is kind of larger than this quantity. But one issue is there we do not know where this output is going suppose if this output is going through a combinational logic and going to another register as part of the control then in that case we have to analyse the path from this particular register through this output logic through the combinational logic to the destination register okay. So since I do not have any a priori information about that I have written that but in real life there could be term like t logic plus t setup time of the destination register may be coming here that you should not forget okay. So the slack is the margin we give and the whole time violation is that the tcq min plus the mean t next state logic min should be greater than the whole value okay. So that the like when the clock comes because of the clock the data at this point changes but that should change only after the whole time as I said it is with respect to same clock edge okay. So that is the essence of it now. So that is basically the timing so when we maybe the controller design we can take in the next lecture so or maybe we can look at this. So the question is that when you implement a control algorithm basically what we have is an input output timing diagram okay and from there we have to kind of decide depending on the input what are the transition okay and in each transition what are the outputs required okay. So normally you have a verbal description and a timing diagram from there we have to with respect to input we have to come out with various state sequences and output at each sequence and at that point there are a lot of possibility is not that there are only unique kind of way of solving a control problem. So there could be different ways you can solve it something could be optimal. So essentially what I am saying is that it is very difficult to go in one step from a waveform to a next stage logic and output logic. So we need to play with it and we need to design that refine that algorithm and you know that in software before writing the code we have an algorithm then we use the flow chart and all that. So when we try to think of control algorithm it is good if we can play with the graphical it is graphically so that we can capture the basic idea. So similar to the flow chart we do something called a state diagram in designing this state machine that helps us to kind of visualize the control algorithm refine it remove the redundancies and group them and all that you know that is a thinking process with graphic symbols capturing basically it should specify what are the inputs with respect to input what are the transition to the state and in each state what are the output this particular diagram should capture that we will see in the next class and it is called the state diagram or sometime it is called ASM chart algorithmic state machine whatever you call that is basically the idea of designing a control algorithm and that part we will handle it in the next lecture. So today what we have looked at basically is one quick run basically we have looked at an instruction called add AB and we have seen what are the essential macro steps involved in executing that and we have seen what is a corresponding waveform for that of the signals for that particular operation. And we have laid out a possible waveform and we kind of worked out how this pulses can be generated and we said it cannot be generated out of a combinational circuit we need a sequential circuit and in this case we said that it can be generated out of a mode 3 counter by decoding the out the present state and putting an output logic to decode it. The next question and that can be you know kind of implemented by writing the truth table and that is the truth table we have seen and you can kind of get a function output as a function of the present state. Then we the next question we have asked and we have seen that this particular delay comes naturally because of the tcq and the t output logic and then we asked whether this is enough to generate all kinds of timing signals is it a generic architecture. So we put some arbitrary waveform and we said yes it is fine because that output logic can be changed the truth table can be changed to generate any kind of waveform in terms of the clock period does not matter. In this case the answer was yes and we have seen that answer we have seen that decoding and we also said that there is no necessity that the state transition goes through a particular neat sequence it can be any arbitrary sequence as long as we properly decode it. So there is no need to worry about how it counts this is a counterpart but that can be made use in minimizing the area of logic and so on. And essentially what we have is an input output waveform so we come out with state transition and output ultimately from that we generate this next state table and output table. And we have captured the finite state machine as a counter going through various states with an output logic to decode to generate the output logic. And we said that sometime it is convenient to decode the output as a function of present state and input then it is called mille output if it is a decode of present state it is called a moore output. And we also said there is another convenient way of looking at is combining these two blocks together because both get the same input. So that is shown here where the logic generate the next state and output. And the last thing we have looked at is the timing issue which is similar to a counter but additional path is an output. So that is captured in the clock period definitely it comes for I mean that has to be analyzed because this output can go through another combinational circuit and reach a register in that case this has to be modified. So which looks similar to the counter because after all the counter is a finite state machine. So counter is also a specific example of a finite state machine where output is not decoded. So now though for illustrating I said I kind of work from the counter to the state machine okay. Don't think that the state machine is a counter but it is other way you know state machine is more generate we can say a synchronous counter is a finite state machine is a specific case of a finite state machine not the other way just for grasping it you know from kind of evolving it from the counter is convenient that is why I have discussed this way but don't say that the finite state machine is a counter a counter is a finite state machine other way. So please now it is a very important topic once you grasp this basic architecture the timing you can master the design this is very many a times very much lacking in textbooks because textbooks to show some practical cases it takes lot of pages and pages it is very difficult to kind of describe in textbook that is why people don't handle it. So please revise this go through the reference book understand it well we can continue in the next class with the designing. So I wish you all the best and thank you.


Why hello and welcome to my YouTube channel. My name is Sandy all knock and I'm an artist and this is not my art studio This is my car. Yeah, I am in the car because Sadly the cable company fixed something this week They came out to my neighborhood and they had big orange signs up everywhere and warnings that the cable was going to be out for a while and After they left they finished the cable was about half the speed that it used to be I Do not know if they were fixing it to try to throttle it I don't know if that was their intent, but that's what happened And I'm hoping to get somebody out to fix it because I cannot survive with half speed internet This is so it's so slow. So I am working on my phone this week Thank you to Verizon for charging me so much extra for all the data that I'm using But that's why I'm here on my phone I figured I'll at least try to shoot a video to get up on Saturday for you since that's the day I normally get to share with you So I'm on my way home from my drawing group And my hands are fortunately for the first time in a long time not black from charcoal We got some new soap and I am kind of excited. It smells funny, but it gets your hands really clean so that's good and I had somebody in my drawing group ask me if I would Maybe make a video about how I do my gesture drawings Because we don't get to watch each other We just get to see each other's work after we're done and she just wanted to see my process So Tuesday hopefully if all the internet things work out I will have some drawing for you just some quick gesture drawings They will not be naked people like we normally draw in my life drawing group I will find another subject to do that with so that it won't be creepy then on Saturday next week one week from the day that you are seeing this hopefully if you watch it on day one on February 3rd the watercolor bouquets class will be officially ready But I'm again, I'm hoping that the internet thing works itself out part of the class is done and ready So what I have done is put a link in the doobly-doo to the product page Where there is a pre-sale going on so if you sign up between now and the end of February 2nd Which is like before the official launch date Then you get an extra ten dollars off the class So if you want to say ten bucks go check it out if you scroll down the page There is a video that shows you a little bit about what you're gonna learn in the class So you'll get to see a preview of what's coming and know whether or not you want to take it There is a pre-class lesson that's free that you can get into and see all the supplies Just make sure you read all the notes that I put in there because you don't need to buy all the supplies You can use the colors you have and if you decide then that you want one of my colors then decide I don't want you to have to like spend a whole lot of money on paints then also, there's a lesson one has some information on How to do sketches because we're gonna do some thumbnail sketches and I'll give you some exercises and Stuff to do in lesson one so that you'll be prepared when class starts Officially and when I say starts it means you can start it anytime Just February 3rd is when I will have all the other lessons ready and linked up for you Now I wanted to have something for painters to work on during February Which is why I was rushing to try to get this in your hands for February because I'm gonna also be busy with the people who like to draw because on February 1st, which is coming up next week We are going to have a whole bunch of people taking the 30 days to more confidence sketching class That's a class that I've had up a long time ago, and I'm just gonna redo it I'm gonna be taking taking the class Myself Revisiting the lesson seeing if there's any tips that I've learned since then that I've missed so I can add some content to the class And then I'm gonna redo the drawings myself I'm not doing new videos for it, but I'm gonna put new content in the class. I might put some notes I might do an alternate photo reference or something for some of the sketches So if you've taken the class before then when we get to that day Hopefully I will have new something new a new nugget for you in each one of the lessons So you don't have to pay for the class again You just take the class again if you would like if you already signed up for it And if you haven't already that one is on sale not the big $10 off sale But it's on sale as well if you would like to join us for that And where are we doing all of this sharing and everything is gonna be on art venture So go sign up for our adventure. Again, I'll link him and do really do Now for those who have stayed for all of this nonsense and blathering You get a special reward because if you leave me a comment on this video And you tell me what your favorite flower is to put in a bouquet anytime of year You can tell me what time of year it is that those flowers grow if you want But tell me what your favorite kind of bouquet of flowers is Then I am going to gift the watercolor flowers bouquets class Watercolor bouquets class. Yeah, that's what it's called I'm going to gift that to one person who leaves a comment on this video telling me your favorite flowers And if you comment and you didn't tell me your favorite flowers, then guess what? I will know you didn't listen to the end of the video So I think that's about it for me. I'll see you on tuesday with some gesture drawing And yeah, we're just gonna hope that the cable company gets everything fixed because I can't I can't keep doing this I'll see you guys later. Bye


This is where you write in one, really happy with that performance today. I thought with Charleston was just incredible up front and all those you say you can't play up front prove today that he can. I really did think it was a good performance from Everton. I thought we stepped it up again in the second half. But in the first we were decent as well. We kept all the possession. It was all looking good from Everton and a good ball from Guilfee Sigarton, you know, perfect weight on the pass into the Charleston with a well-class finish for me. That is a well-class finish and it's what a good striker does, you know, get that chance and make sure that they take them.  Brighton are poor, Brighton are poor sides, let's get it right. And we were dominating them and against them on the play they get a goal and I think we were prepared for the corner to come in with his own remark. And I think what's through his off is the fact that the short corner got taken and a ball into the box and you know he's doing, we get caught out and it's a good header from Dunk to be fair but it should have been really prevented. I just think the short corner routine really threw us off. A great goal from Brighton's perspective but a poor one from ours. Went into the second half, we really stepped it up. I thought we went up a notch. I thought with Charleston was excellent, you know, I thought Andre Gomez was my matter of the match but it's so hard to choose. He was your matter of the match. I thought well got stepped it up a little bit probably not enough to deserve it. Andre Gomez was excellent guy and was excellent thought but now it was decent and what he done, his quality was there but not up to match fitness yet. A good ball by Andre Gomez into Coleman and that's a fantastic finish and listen it wasn't Coleman's best performance today but that'll give him the confidence you know to kick on. Brilliant from Sheamus delighted with him. Not sure about the angry celebration but he's probably justified with the amount of criticism he's got and the criticism has been probably due if I'm being honest. You know he stepped off a little bit as a recent performances but he has picked it up today. He's got his goal and that's what really kicked us on even further for the Rich Charleston goal which was a mistake from a Brighton point of view. Rich Charleston knocks it around the right hand side of Dunk and runs around the left. It was a brilliant skill and then takes it round the goalkeeper and finishing it. It's all done and dusted the professional performance from Evan and we get that home win and the home form is what I'm worried about and if we can see teams off like that maybe get rid of the horrible scrappy goals that you know that we all can see in the home such as Brighton's today then we'll certainly get that home form that we had during Cuman's first season which we look like we're going to win every game against those that were lower than the top six under Cuman and I think the away form is so much better than what we're seeing under Cuman so we're actually going up that further level so I'm really made up to see that. Everton 3, Brighton 1, good performance from the Blues.