Advanced Micro Devices, Inc. (AMD) Earnings Call Transcript & Summary

All right, we are live and broadcasting. Hello everyone, and thank you for joining us today. My name is Jeffrey and I will be your host for today's webinar. Today is -- we're going to be talking about the Kria App Series here. We're going to be unlocking KD240 capability with MATLAB and Simulink. So we have a couple of speakers for you today. We have Kevin Keryk from AMD and Noam Levine from MathWorks in the house today. So we're going to have a great presentation from them. We -- let's see here. Okay. Cool. Before we jump into our presentation, I just wanted to go through some housekeeping. So if scroll down from the video player, you will find a toolbar with a few headings. So in the overview tab, you'll find a summary of today's webinar as well as a little bit more information about our speakers. And then in the surveys tab, you will find a survey. If you could that out for us before you leave here today that would be super helpful as we try to give you the best webinars and information possible. And then in the resources tab, you will find a PDF of today's slides as well as a link to last week's webinar, where we gave a quick introduction to the K24 and the KD240 SOM Starter kit. In that PDF copy of the slides, you will find a ton of links at the back end towards our wrap-up. So you'll be able to jump into so many resources from that one PDF. And we will also have a question-and-answer session at the end of the webinar [Operator Instructions]. All right. And last but not least, this webinar will be made available for on-demand viewing, and you'll be able to come back and watch any time via the same link that brought you here. All right, with that housekeeping out of the way I will go ahead and hand the ball over to Kevin to begin the presentation. Go ahead, take it away.

All right, sounds good. Can you hear me okay, Jeffrey? Okay, great. Thank you, Jeffrey, for the kind introduction, and I'd really like to thank you, the listener, for dialing into or watching on demand afterwards this next installment of the Kria App Series. We have a lot of interesting material we cover today. So let's go ahead and get started. So for nearly 40 years since 1984, AMD's adaptive and embedded computing group has brought over 60 product families to market, mainly in the form of semiconductor devices. These components would be placed as chip-down on custom designed print circuit board, designed by product engineers for production deployment in end applications. Just 2 years ago, in early 2021, our first in-house manufactured and branded system-on-module became available for sale directly from us and through our channel partners. Today, we will highlight many of the features, value and system capabilities of this offering for new product designers, and how it could be combined with solutions from our technology partners like MathWorks, who's joining us here today in order to help you solve unique and challenging real-world design problems quickly and with excellent results. So it's important to note that system designers, leveraging our technology deploy, using our hardware and software, technologies in a variety of ways. And this is because our entire portfolio is supported by development tools, IP and comprehensive software stacks, including libraries and supported framework models to enable a wide range of deployment methods for our technologies. So using the half a credit card-sized Kria K24 SOM from AMD, you can cut your power consumption, increase torque and other performance characteristics while reducing motor noise and vibration. And you can also employ predictive maintenance with over-the-air software updates for a longer service life with every motor. This is all possible through high performance and power-efficient DSP capability that's built into our technology. The K24 has 2x latency advantage over competing solutions, along with the determinism, reliability and security for functional safety applications. The K24 SOM complements the K26 SOM that we've had previously with connector compatibility, and that gives you scalability between the 2 devices. It's adaptable to support a variety of access control or many different motor types. And it's not just for motor control, really any DSP intensive application. We just highlight a lot of these right here on this slide here. So one of the best things about Kria SOMs is that you don't have to be an FPGA expert to use them, just like prior Kria SOMs, we're geared towards software engineers, AI scientists, roboticists. The K24 SOM supports Python as well as MATLAB and Simulink flows for control systems engineers and in addition to those traditional FPGA flows that many hardware designers have gotten used to. And we have a number of new apps that are available inside the Kria App Store, and we'll talk a little bit about those. And we also have full support for industry standards like Ubuntu, Linux and Docker and [ handlers ] built in as well. So like the K26 SOM, the K24 SOM is complementary because it's based upon the same Zynq, UltraScale+ MPSoC architecture. And that means you get quad 853's cores, dual RF5 cores and you get this terrific peripheral set along with hardware Root of Trust cyber security capabilities. It's a scalable option from the K26, where the size, cost and power efficiency are the primary design criteria. You have about 154,000 logic cells. You get Ubuntu 22.04 server available. We have 132 flexible I/Os, 2 gigabytes of LPDDR4 RAM. And specifically for our industrial grade K24 SOM, that 2 gigabytes of LPDDR4 RAM is ECC protected. And as you can see by its listed support for AMD AI inferencing, we have deep neural network processing unit support. The K24 can do a notable amount of AI on board, but we believe it's more likely to be deployed in a lot of applications that create the data sets that AI inference can be applied to, either on the K24 or up in the cloud. With all the talk of AI out there, something has to be generating that data for AI to be used on. And we think that's more of the role of the K24 SOM. So the Zynq, UltraScale+ adaptive SoC used on the K24 SOM. This is specific to the K24 enhanced capability for mixed criticality, where some user functions can be given a real-time priority and others best-effort priority or anywhere in between. These are very important functional safety-critical systems that we often find these being deployed into. And so we have a hardware Root of Trust for cyber security that gets augmented by the TPM 2.0 that's on the SOM itself. And we also have visualization capability built in with a GPU. So with that programmable I/O structure of the device, you can connect up to virtually any sensor from environmental, orientation sensors and also vision sensors. It can drop in IP to support industrial networking. And for those that aren't familiar, there's over 40 industrial networking standards out there, and we offer support through our own in-house developed TSN IP. And there's also third-party IP available for EtherCAT, EtherNet IP and so on. And lastly, it's important to note that, that smaller size of the K24 SOM, that's enabled by this InFO packaging that we've introduced recently for the Zynq, UltraScale+ family of adaptive SoCs, and you get to leverage that on the K24 SOM. So the AMD Kria KD240 Drives Starter Kit, it is a K24 SOM based development platform. It targets motor control and DSP applications. It enables embedded software and control system developers without FPGA expertise to develop multiple target applications, such as robotics, drives and actuators, industrial Ethernet gateways, smart grid, DC to AC conversion, EV charging stations, medical equipment, patient care systems and motor control systems and interfaces that are used within the public transportation market as well. Now the KD240 Starter Kit, it's focused on the ease of use and support it through a variety of prebuilt accelerated applications that we have available from the Kria App Store. And developers can benefit with greater flexibility from Ubuntu support and PIN-based development flows on a competitively priced FPGA-based platform. Now the prebuilt interfaces and accelerated applications make KD240 an ideal platform to accelerate DSP innovation, primarily in drives, and it also allows developers to take their ideas into volume production deployment with commercial and industrial grade Kria K24 SOMs. And we'll talk a little bit about that as well. So for those of you that aren't familiar with the SOM concept, SOMs speed our developers' time to market by enabling those hardware developers to focus more on their application differentiation, and enable their software developers to start sooner with prebuilt hardware. And Kria SOMs are intended for production volumes, but we offer starter kits that house the SOM on the board. So our developers, customers, and engineers can quickly prototype their application while they design their own custom carrier card for the production SOM to plug into. And then they can come back to AMD, and they can purchase the SOM directly from us and build that into their end closure for their end system. So up next, we'll talk a little bit about the developers that we -- the developer personas that we've enabled. So if we start here at the bottom and kind of work our way back up. Down in the lower right-hand corner, we have our traditional hardware developer and system architect. Now these are the folks that do have FPGA experience, and they want to leverage that knowledge and continue designing in RTL, Verilog or VHDL. And then over to the left, we have our embedded developers. These are folks that are writing application software and firmware development. These folks tend to design at the C and C++ level inside of their application. And for these 2 personas, we fully support them through Vivado tools and Vitis tools, and we'll talk about how we can enable these higher-level developers on the top here. So we have our Python developer, they typically develop with Python and take advantage of the vast libraries that are available. They like to have the hardware and the firmware abstracted away, so that they can focus on purely software development and accessing the hardware through well-known APIs. And then up in the upper left-hand corner, we have our control systems developer. And they like to implement enhanced functionality and maybe around a motor control application, but they typically like to leverage industry tools like MATLAB and Simulink. And that's what we're here to talk about today, how we can enable those control system developers to more fully leverage the Kria SOM. And to do that, we'll talk about model-based design. So you may be wondering what is model-based design, and why would somebody use it? Well, model-based design is a mathematical and visual approach for developing complex systems. And with model-based design, virtual models are at the center of the development process in order to improve how you deliver complex systems to the market. So using model-based designs with MATLAB and Simulink software, you can shorten your development cycles and reduce your development time by 50% or more. And the main advantages of model-based design are that you can try new ideas and perform fast, repeatable tests with modeling and simulation, which can result in shorter development cycles. And you can also eliminate manual steps and reduce human error involved by automating key steps such as reporting, coding and verification, and this even further reduces your development time. So if we dive into what is Vitis model composer in a nutshell. So in short, Vitis Model Composer provides an extension to model-based design by allowing you to kind of traverse this staircase. So we'll start at the bottom here. So we have these drag-and-drop programmable logic or HDL optimized blocks that are provided from the Simulink library browser, down here at the bottom. Now these are targeted to AI engines, for DSP applications on our Versal family, this can be HLS Math functions, and it can also be HDL DSP-IP functions as well. So you can take full advantage of these libraries that we have available. In fact, we even have like Vitis Vision libraries that you may have seen on our previous generation SOM that gets used in many vision applications in order to do computationally complex, but -- tasks that can be done in parallel, such as video scaling, color space conversion and things like that. And if we work our way up to the next step on here, we can co-simulate our designs with programmable logic and processor system functional blocks in this level here. And this is done by moving code back and forth between the HLS environment and the AI engines, HLS environment and the adaptable engines, it can move between HDL and AI engines, and also target into the adaptive engines through simulation. And if we work our way up to the next step, here, we have the ability to generate HLS and RTL code plus the tool generates the necessary test benches for you on the system. And then finally, as we work our way up to the top, we have our hardware validation flow at the top of the staircase. And here, you can select your board from within the tools, you can validate that your design results match the simulation, and then you can move your design into the hardware with all at the click of a button. All right. So the Vitis Model Composer provides a library of performance-optimized blocks for design and implementation of algorithms on Xilinx devices using HDL, HLS and AI engine blocks. And System Generator, the previous stand-alone design environment for developing DSP algorithms and generating HDL as an output, is now part of Vitis Model Composer. Furthermore, you can develop new algorithms by using HDL library, HLS library, AI engine library, if you are targeting a Versal device, but today, we're talking about MPSoC. We also have a utility set of functions, which most importantly, contains the model composer hub block, which is useful for code generation and hardware validation flows that we mentioned on the previous slide. All right. So then we'll move in to talking about how you can start with the KD240 Starter Kit, evaluate the technology and then target your own motor. So we have a sort of step-by-step process, and then we'll dive into a demo that shows how we targeted a motor onto our KD240 kit. So here's a diagram that kind of shows 3 different phases that you'll migrate through during your technology evaluation and moving towards production with the SOM. So if we start here in this left most pillar, where we talk about the starter kit out-of-box evaluation. On our AMD cloud, we have prebuilt designs that are made available through our Docker incidents. These are applications and reference designs that are provided by AMD, and they're built on top of our run time libraries and our SOM enablement layers, and they run on top of a base OS. And that's Ubuntu 22.04 server for the KD240. On top of that, once you download those pieces and target them on to your board, this gives you access to the example applications. There's sensor-based control. That app is built on top of our ecosystem, which gives you the one -- run time libraries and frameworks, all of which are open source and made available so you can modify them as you see fit. And those frameworks are built on top of Linux, where we're taking advantage of the Linux IIO infrastructure, and we also provided a tool called xmutil for accessing hardware level functions on the board, so that you can do things like update your programmable logic bitstream, you can update firmware on the board, and you can unload and load new hardware overlays using xmutil as well. And this is all built on top of our AMD Kria SOM hardware, and the AMD SOM hardware is plugged into the AMD 240 carrier card. Okay. So that kind of walks you through the out-of-box evaluation. We provide everything as a prebuilt hardware and binary, so that, that way you can speed through this step of the evaluation and move on to more advanced valuation flow, which is what we're showing here in the middle. So in the advanced valuation flow, we've replaced the cloud with your development machine. So on your development machine, you may be running CentOS, you could be running Red Hat Enterprise Linux, you could be running Ubuntu or you could be running on a Windows PC. For here, you may gather up the source code and start customizing the example applications that we've provided, but you would still using our KD240 Drives Starter Kit, Vitis platform, and also using tools like Vitis and Simulink that you have installed on your PC. And if we move outside of that black box over to the target, we can kind of take a look at the pieces on the target that you may start customizing right away. You may start customizing your accelerated application and making your own bitstream. You may start introducing your own ecosystem run times and libraries onto the board, but you're still running on top of the AMD Kria SOM and the AMD KD240 carrier card. Now as you continue your advanced evaluation, at some point, you'll have developed your own custom Kria carrier board. And in that point, you've moved into what we call productization with the SOM, which is the right most column on this slide. So here, you also have a development machine. You have a more fully customized application. You may have started customizing that Vitis platform and the root file system that gets baked into your operating system. Here, you're using Vitis and Vivado to create the hardware platform and custom accelerators. You may be using MATLAB Embedded Coder or HDL Coder tools on your platform. But you're doing so all to fully customize your application, building on top of your own ecosystem run time and libraries, you may be mixing and matching the ones that we provide, along with ones that are provided by third-party partners. You're basically creating a customized Linux image on there. They have all the underlying libraries that you need for your end application. But you're reusing the same AMD Kria SOM that AMD provides. It's just that you're building this now on top of your custom Kria carrier board that is more fully targeted towards your custom end application. But the whole idea is throughout this process, we're taking step in order to minimize those barriers for you to migrate from evaluation all the way through to production with the SOM. And if we flip over to the next slide here, you can see a little bit more detail around the development migration and how that involves the tool flow. So if you kind of imagine those 3 pillars, we've kind of shrunk them up and put them up at the top. And then we'll talk about like what sort of tools are needed to get you through these stages of development. So for the starter kit out-of-box valuation target, our goal is for you to have no tools needed other than maybe a terminal emulator to see the output of your terminal console. Outside of that, you shouldn't have to install Vitis tools or Vivado tools. You should be able to run prebuilt binaries and start evaluating that technology right away. And as you move into the middle column and you start getting to more advanced evaluation flows, this is when the tools come in handy, because you can take the provided source code that we have for these applications and the underlying hardware platforms, and you can fully customize them through tools like Vitis Model Composer and our Vivado ML tools. You may also start simulating your systems. So this is where MathWorks tools like Simulink will come in handy. And we have a demo here coming up, where we'll show how useful that -- these tools can be in this advanced evaluation stage. And finally, as you move into production, you're using the same Vitis Model Composer tools, Vivado ML tools, same Simulink tools, and you may be simulating against target hardware. But now you can introduce things like Embedded Coder and HDL Coder, and we have the MathWorks folks here today to tell you a little bit more how those fit into the picture. But again, the idea is to provide the tools and the resources that you need in order to minimize those barriers to move from evaluation here on the left, all the way through to production with your SOM, on the right. So I'll talk a little bit more about the applications that are involved in this. So this is a sensor-based field-oriented control app that we provide on the Kria App Store, we make all the source code behind it fully available. I'll just kind of walk around this block diagram here. So you can see on the right, we have TSN subsystem. This allows you to connect remotely with peers. It could be a PC, it could be another Kria board. And then as we move down here, we can see that we're diving into this PID control system here. And this PID control system is for controlling this permanent magnet synchronous motor here at the bottom. This is a sensor-based one, so it does have a quadrature encoder on it, where we see the quadrature encoder inputs into our system. Here, we have -- we're fully leveraging our new Vitis Motor Control Library. This is giving us the quadrature encoder position feedback for our PID control loop. It's giving us a field-oriented control block and a space vector pulse width modulation with DC link compensation, all inside the programmable block, so we can put this into a very tightly-nested hardware setup. And then the output of that go into our gate drive production, which drives out the different voltages that are needed to drive Phases A, B and C on our permanent magnet synchronous motor. While we're doing this, we monitor the current voltage and ADCs, and we feed that back into our DC Link motor current, voltage capture block, and we are also monitoring for faults inside the system. We -- if we see a fault, we disable the gate drive. So we have -- we can protect the gates with that. And so what we'll do is we'll kind of use this as a map for what we're going to be doing inside of our demo, we need to come up with PID coefficients for our system, and we need to be able to simulate this so that, that way, we can target a new motor. So really quickly, what I'll do is I'll cover some of the fully customizable capabilities of this control app that we're providing. This is using our new motor control library, which is available with C, and C++ source code under Apache 2.0 licensing. You may be wondering, well, wait a minute, C and C++ code that sounds like software, and I thought you said that this PID control loop is implementing inside hardware. And that is correct. We do have programmable logic hardware blocks, and we generate RTL code from our motor control library that's written in C and C++ code using our AMD Vitis HLS tool. So here, you can kind of see those 3 different box that we showed on the previous diagram, and this is basically the foundation of our PID control loop that we use for controlling the motor. And for each of those pieces, we have different -- we have access into these blocks that gives us some run time access. So for the quadrature encoder, we can change the number of sensor counts per revolution. We can change the sensor encoding type that's used inside of our application. For the FOC blocks here in the middle, we have control modes of stop. We can set it in the speed mode. We can set it in the torque mode, and we can set it in the field weakening mode. And that also gives us access to different set points so we can change the RPM. We can set the torque target that we're aiming for inside the torque mode. And then we can also, at run time, change the proportional and integral gains that are used on the motor that we have connected, and we can change the open-loop motor period as well. And as we move into that space vector pulse width modulation block on the right, we also have the ability to change some of those run time parameters as well through the AXI interconnect that is built into that block. So we can change things like phase-to-phase shift, DC Link source, voltage, the PWM frequency that gets output as it's generated by this block. And then we also set the dead-time period for different drive stages. There are things that get set at build time, particularly the PL clock frequency. Those are things you're going to want to set upfront and have those well-known at build time. And then also any motor model parameters that you need to load, that are targeting your specific end application motor. So the whole idea behind this is that you can start with the KD240 Drives Starter Kit. You can simulate your end application, and you can develop on that platform. And then using the K24 SOM capabilities, you can migrate that into a full production system on module that's targeting your own carrier board. And it's also targeting whatever motors, it is that you need to control in your end application. So this is a fully flexible system. We mentioned that the source code is available under Apache 2.0 licensing. But one of the interesting things about it is that you do need to kind of understand what it is that your motor -- how your motor is constructed. There are some parameters that you may find inside the spec sheet that would be useful for helping you model that device. But we view like the K24 SOM has a lot of flexibility to it. And so you can target a number of different motors being run concurrently. And this is where we excel over our competitors in being able to target multiple motors simultaneously while also giving you those tightly coupled and low latency control loops inside your system. Okay. So this takes us into our Simulink demo. So let me go ahead and get my screen share activated here. So I had my control console here, but let's go ahead and let's see here, let me go into notes here. So we have a model composer, let's get that launched first. That will be the first step. So we got model composer to launch, and we'll take a peek at some of the tools that we have available for doing programmable logic designs. So first, I'm going to need to start Simulink. And then I'm going to open the sensor-based FOC app model, which represents what our Kria motor control app. We'll be doing within the programmable logic using our Vitis motor control libraries. So, if -- let's see here. Okay. So I have my block open here and let me get zoomed in on it so it's nice and visible for everybody. So within this model, we can open up the library browser and scrolling all the way down to the bottom, when you see the Xilinx toolbox that we mentioned earlier. And since this is the 2022 version, it still has a Xilinx theme on it. Our new versions, you'll find it have the AMD toolbox name on it instead. I still have the 2022.2 version, which works great for what we need it to do for KD240 development work. You can see that we also have those HDL, HLS and utility subcategories under the Xilinx toolbox that we mentioned earlier in the slides. And under HDL, you'll find all the basic programmable logic elements that you'll need for things like discrete map functions. There are DSP functions, which might be really useful for K24 SOM users, who are looking at some more advanced digital signal processing functionality for their end application. We also have available blocks like -- see here, open up some of these things here. You also have available blocks like a direct digital synthesizer block, fast fourier transform block, our finite impulse response block, which allows you to generate these highly parametrizable, very efficient and high-performance FIR filters. If you're curious about what a block does or what type of inputs it can accept, you can always right click on that item, and you can click on the help for that block. And this actually pulls up the documentation from Vivado, so that you have access to all that information for -- the Xilinx tools at your fingertips within Simulink. You also get access to basic logic functions such as blocks, local memories on blocks and so much more. Now if we turn our attention to the HLS functions here -- I think it's still trying to load up the help for that here. So when you right click on the help, since it's pulling up that documentation from Vivado, sometimes it can take a second for it to launch Vivado in the background here. So I'll keep on going through the HLS functions while I wait for that to load. We can see that we have a pretty rich set of functions under HLS, including bit and logic functions, there's map function, signal routing functions as well as data sources and sinks that you can choose from. And then there's also a utility subcategory, which can help you specify which device the board is selected by the small composer and you can drive those options for the output flow, and that allows you to specify the targeted design flow that's used for generating outputs. So here's that help that loaded up on the fast fourier transform. Talks about all the different inputs and the theory of operation that's available for this block. So I can go ahead and close that, and then we'll go back into our model here, and I'll finish showing you a little bit about these utilities. So we mentioned that there's -- dive into here. There's a doc block that will allow you to kind of go around and document your design using -- it allows you to create and edit text and help you document different parts of your model. All right. So let's go ahead and collapse all these back down, so that way we can get into our motor control block set and start putting together a field -- sensor-based field-oriented control or FOC model within Simulink. So first, we need to go to our motor control block set here, and we're going to go into our electrical systems and look at the motors. Here, we have a surface mount permanent magnet synchronous motor block and we're going to drop that into our design here. So we put that into our design, and then you can open the block parameters and what we're going to do is we're going to match them as closely as possible to the target motor. In fact, this is the same process that we followed when we selected the BLWR11 series motor that we used. We can simulate to bring up this motor with the each [indiscernible]. So let's go ahead and we'll pull up the data sheet for that inside of our browser window. So here, we have the motor that we targeted is this one right here, but we need to open up the spec sheet, so we'll open up the spec sheet for that device. And then while zooming on this table right here, just take a look at the different parameters that we have for the motor that we're targeting. So if we dive into this, for this model, we're going to select the mechanical input configuration. So let's go back into our model. We're going to set this for torque mode, and we're going to set the simulation type to discrete. And we're going to set our sample time to a variable, called Ts inside of our system And then we need to set these other parameters inside of the block based upon what we've seen inside the data sheet. Now we know from the spec sheet, if we go back over to that. This is a 4-pole star winding type motor. And so that means we have 2 for the number of pole pairs inside here. So let's go ahead and set 2. That needs to be indicated inside of the model. Next, we can copy the line-to-line resistance of 4.63 ohms. We can copy that value over directly from the sheet into the stator resistance per phase. And this is a value in ohms. And then next, we'll take a look at the line inductance value on the data sheet, which is 1.69 millihenries. And then what we're going to do is we're going to divide that by half to get 0.845 x 10 to negative third henries, which we're going to enter here inside of the stator axis, the stator d-axis inductance value, the LDQ value. And then we're going to -- since this is a torque-based mechanical input, we're going to set our torque content, so we need to go back to the data sheet. And we're going to look at the torque constant doc option. So here, we have a torque constant that's specified -- it's specified in ounce inches per amp. And we need to convert this to the expected units inside of Simulink of newton meters per amp. So using our handy Imperial units, the metrics units conversion tables. This turned out to be 0.160297 newton meters per amp. And then next, we're going to look for the motor rotor inertia parameter. This is also specified inside the data sheet right here. But its specified in ounce inches second square. And what we want to do is we want to convert this to kilogram meters squared units, and we're going to enter in 3.315 x 10 to negative 5 inside of this parameter right down here. And then since we don't have the values for the viscous damping or static friction for now, we'll just enter in a small non-zero value 1 x 10 to the negative 6 for each of these other parameters. Just so there's no more divided by 0 operations that happen within the model simulation. Okay, so next, we need to have everything set up for this. So we will need to go back to our model here, and we need to finish connecting up our output of our torque stimulator. So we're going to connect a new motor model up to FOC. So first, we're going to connect the inverter output of our drive stage to the phase voltage inputs on our motor. So we're going to connect those up. Then we connect up the output of our torque stimulator up here to LD torque input. And here, we're stimulating a changing load that starts off low at 0.0015. And then after 2.5 seconds, we're going to step that up to 0.035. So you can imagine this is kind of analogous to a conveyor belt that gets a new package placed on it. And we have to move it down to the end of the destination unload point, so let's get that connected up. Next, we connect up our info output of the motor up to our bus selector over here, and that's going to allow us to pick off the motor torque ratings and display them on this scope over here. And then we're going to connect the phase current output of the motor block to the phase current inputs of our FOC block subsystem over here. And then we're also going to connect this to the phase current scope monitor here, so that way we can keep an eye on them. And then finally, we're going to connect the motor speed output of the block up to our motor speed scope so that way we can see that the motor is actually turning at the rate that we expected. Now before we launch the simulation, let's dive a little bit into the subsystems and see what sort of outputs we will be observing. So let's start with the FOC subsystem here, and we'll push down into that. Here's our basic field orienting control mechanism. If we start over here with the mechanical position input on the right. This is our encoder input, which will perform a sine-cosine lookup upon to get an idea of what sort of rotational angle the motor is currently in. And this feeds into both the Park and the Clarke transform. The Park transform and the inverse park blocks. So next, we're going to input that we need to cover the 3-phase motor currents that are coming in here. And we measure these by our EDC that's onboard. And from those, we pull out the A and the B channel data and we pass it into the Clarke transform block, so that we can drive an i-alpha and i-beta value, which feeds into our Park transform block. And now the output of the Park transform is the Id and Iq components. And these are differentiated with the incoming flux and torque commands that are respectively -- from here before being passed to our 2 PID controllers right here. Again, one PID controller is for flux control, and the other one is for current control. And together, we get a Vd and a Vq value, respectively, which feeds into the inverse Park transform block to yield our V-alpha and V-beta, respectively, which then passes to the inverse Clarke block to yield our free target voltages for energizing the motor windings. Now if we back out of here, we can see that those target voltages get passed into the PWM subsystem. And within the PWM subsystem, we scale the voltages by the DC Link voltage and we drive a PWM reference generator here. This is set for space vector modulation mode just like we have inside of our FPGA. But there's other modes that you can pick. The output from the SVM PWM is passed through an average inverter block, which generates our output in -- our inverter output to drive the windings on the motor. And so this represents the effective voltage output of the prep stage on our KD240 board relative to the DC Link voltage of 24 volts. So what we've essentially done across each of these blocks, we've implemented very much on a one-on-one basis what we have available inside of the Vitis Motor Control libraries, which we have used to generate our sensor-based control app with all of the field-oriented control being done within the programmable logic of the K24 device. Okay. So now that we've taken a tour of the rest of the simulation model, let's go ahead and run the simulation. And while we're waiting for the simulation to complete, let me describe from a high level what we're looking for there. Ultimately, we want to see that the coefficients that we selected for our PID control loops, they result in a rather stable motor state transition operation that we're avoiding any wild oscillations inside the system. So let's first open up the scope plot for the motor torque, take a look at that first. So here, we can see we started with 0, 2.5 seconds, we changed the torque on the motor. So we see that step function change as the box gets put onto the conveyor belt, if you will. And then now let's put -- take a look at what's happening to on the phase currents on this scope plot. Here again, we can see the change of the load at 2.5 seconds. And the same thing with the scope plot for the stator voltages of the motor, let's take a look at that one. And then let's dive really quick back down into the FOC subsystem here, and we can take a look at the XY graph right here to see our i-alpha and i-beta values. They get plotted here, and you can see -- these are plotted in this constellation arrangement. And you see how the system moves to these steady-state areas as it gets closer to meeting the torque demand conditions of the system after that 2.5-second timer as the torque -- the system that we can observe those changes being made smoothly. So one final check that we have is that back to the top level, so let's go back up to our top level system here. And at the top level, we can see -- we want to see that the motor is actually spinning, so let's check the motor speed output. So you can see that the motor is actually spinning, spinning in the negative direction here. But you see, again, at that 2.5-second mark, there was a change there as we changed the torque marker -- torque target in their system. So far, everything points to having the P and I coefficients dialed in for a PID control loop. So with the brand in new motor, these values may be tuned and you may need to tune those quite a bit to settle in on values that give you good system stability. You can also do this somewhat manually within an Excel spreadsheet or use the FOC autotuner block from the Simulink library, which can be stitched in your model and can sweep through those P and I parameters to find the appropriate mean value combinations, which yield the best results for your system. So with some back-of-the-napkin calculations, we can calculate our torque KI and torque KP values and pass those along to the application and get the motor spinning. Okay, how I'm doing on the time here, Jeffrey? All right. Looks like we're coming along here. So let me go ahead and launch. I have my board running here. Let me flip back over to my other camera view here. So if I got my camera here, let me just really quickly -- let me show you before we go to the demo, I want to show you what the K24 SOM actually looks like and here I have a K24 engineering sample. And you can see that it's encased in this protective heat spreading turtle shell. But if we open up the case, and I don't recommend doing this at home. We can see the PCB within the -- it has the MPSoC device, the memory and the other support devices on it. And here, I have my business card, that I'll hold up next to it, so you can see the size of the SOM relative to something of a known size. So that's -- gives you an idea of what the SOM actually looks like. And then what we'll do is I'll switch my camera over to point down at my desktop here, and we can see my KD240 Board, which I've already loaded up with that console right here. So I've booted up the console. I have loaded my accelerated application and there's a Bokeh server that's running in the background. So I can switch over to my browser here. So inside the Bokeh application, I have access to change those P and I parameters for my different control modes, and I can set my control mode into torque mode. And you can see on my desk, the motor really started spinning. So inside of the Bokeh server, you have access to some tools for monitoring fault status on your system. You can look at some of the samples that we collect in terms of motor currents, motor speed on your system. And then you can also see a sort of constellation diagram over here. When I press on the motor, you can see those i-alpha and i-beta values moving on out. Okay. So let me go ahead and -- go ahead and wrap up the demo here, and I'll turn it over to -- going to turn over to Noam from MathWorks and talk to you a little bit more about the capabilities that their tools offer. Noam?

Great. Thanks, Kevin. So I wanted to take a step back. Kevin started this whole thing out. We were going to talk about model-based design and why that's so cool. So I want to sort of pick up that topic again. And really, the whole message of what we've been talking about here is how you approach your design test, what your design philosophy is. And really, it's all about model-based design, and I'll add the other notion of test-driven development on there. And the idea here is that you don't start by saying "Hey, we're just going to dump a bunch of code on to something and hope for the best." You really want to start with a plan, and that plan involves your high-level system specifications, your research and a system model and simulation. And along with that, you want to start also looking at how am I going to test this thing and how I'm going to validate that the behavior that I'm seeing is correct. So if you're moving beyond prebuilt libraries and starting to do your own custom design, you really want to start with that level of modeling and simulation. And at every step, you want to make sure that you're testing your work at every step and validating against your system specifications and requirements. And if you see a deviation in behavior at every step, you don't go and fix it at that step. You go back to your base model. And that's especially true as you get into your implementation integration deployment phases. If you see something break in implementation, you don't fix it in implementation. You go back and you find out, is there something in that model that is causing this part of the implementation to break. And if you follow that type of approach, where every step you're testing, you're validating against requirements, you're fixing it in the model, then your model becomes your golden reference. And you're executable -- basically, it's an executable specification, so that when you do get to hardware, you stand a much better chance that what you come up with is not only going to work, but it's going to work well. And we're going to take a little closer look really into that integration deployment step. And when we look at the tools that we apply to this, so if we look at this more as a linear flow now going from your research requirements through your system architecture and algorithm development and finally, into your implementation models. Kevin has talked a lot already about Vitis Model Composer, which is a Simulink-based tool that takes those model-based design concepts and provides a high-level performance-optimized blocks for AMD platforms. If you want to start moving beyond that and start getting your own custom design, different motor types, different control type algorithms, there's other products that we can talk about from MathWorks that still build on that model-based design philosophy, but can start generating more generic code for your processing system on that Zynq, UltraScale+ device and generate code for that programmable logic on that UltraScale as well. And so using those code generation products you can get -- again, build code from whatever custom design you come up with in MATLAB and Simulink. And furthermore, there are products available that even stepping back another layer of abstraction, if you want to model what those algorithms are going to look like running across that SoC device, look at what effect does my -- do memory operations have on my algorithm deployment. Do that what-if analysis of what parts of my algorithm should I be running in programmable logic versus running on the processing system. There are tools available to help you model that at a system level. And then lest we forget, verification. And this is usually a stumbling block for a lot of people. But how can you make sure that the HDL that you have is actually the right thing. So again, from MathWork's built into this model-based design philosophy is the ability to verify your HDL code through co-stimulation, FPGA and Root testing through a number of industry standard simulators including Vivado simulator. And then to top it all off, if you're in an environment where you need to provide quality standards or meet certain quality certifications for your end product, there are kits available that -- because this model-based design approach lets you have traceability from your system requirements to your coding, we have kits available that will help you streamline certification for your development and your product. And I can turn it back to you, Kevin.

Okay. Great. Thank you, Noam. I'd like to briefly review some of the information that we've collected along with some resources and links that I think will likely benefit you along your Kria journey. So what we have here, the response that we've gotten to AMD Kria, our SOMs, our starter kits, our app store and the value that's brought by our technology partners like MathWorks. This exceeded all of our expectations when we launched over 2 years ago. So webinars like this one serve to further our commitment to simplifying embedded design in your end applications where we can have the greatest impact by bringing adaptive computing benefits without the complexities associated with traditional FPGA design. So if you feel like Kria SOM has the potential to make all your wildest dreams come true on your next embedded system design then I encourage you to purchase one of our starter kits, and evaluate the technology and its suitability for your end application. And before we go, I want to mention that we have a ton of resources available to help guide you through your next design start. So for K24 SOM, we have product collateral, tutorials, guides as well as a growing library of prebuilt accelerated applications, which you can use to evaluate K24 SOM solutions. We also have AMD wiki with many technical resources available to you for updating your board firmware, looking at the DSP you need and where to find device platforms with board constraints, and links to our source code repos for all of our AMD provided applications. And I also want to spend a few moments highlighting the training resources that we have available, including our recent K24 introduction webinar that Jeffrey mentioned at the beginning and another one that covers model composer studio in greater depth than what we were able to touch on here today. Those links are available here as well. Also, many thanks to the MathWorks folks that provided these excellent self-paced learning resources for Simulink. And we also added a link here where you can discover more information on motor control design and dive even further into the simulation techniques for field-oriented control system design. So let's go ahead and move into the Q&A here, Jeffrey.

All right. Great. All right, great. Thank you. That's was awesome, the demo, very cool. So we have -- we're running tight on time a little bit, but we have had [ Tomas ] and [ Grogini ] in the backroom answering questions as we've been going. So I think we've addressed most things that have come in. But we have a few that we want to get to. I just want to give a couple of reminders before we do. So all of those links that Kevin just showed, you can download the PDF copy of the slides, and you'll have full access to all of that in the resources tab, just down below. And there's also a link to the 2 last week's webinars as well. If you want to check that out right after we finish here. And you'll also be able to come back and watch this on demand pretty much right after our session ends today. All right. Let's jump into some of these questions. So Kevin, you showed the production SOM earlier. Does that come with that heat spreader?

It does. So it comes with a heat spreader. The kit comes with the heat sink that you saw on the board that was sitting on my desk, but that's really just for evaluation purposes. It's really up to you to provide your own heat-sink solution on that. And so we work with a number of different partners. I know Avnet has come up with a heat solution for the K26 SOM. You will need to come up with your own heat solution, but it does come with the heat spreader, for the SOM. Good question. Thank you, [ Seema ].

And then we have another question. So are the control blocks converted into C, C++ code, HDL or both? What's going on there?

Yes. So the control blocks that I showed, inside of the slide that showed the sensor-based field orienting control, those are provided as C and C++ libraries. When we run them through our Vitis HLS tool, they get generated into basically hardware blocks that run inside of the program of with logic. They have an AXI interconnect on them. So that way, we can set parameters inside the block, but that's the job of our Vitis HLS tool to do that C-to-gates type conversion.

Cool. So this question has some acronyms, some -- excuse me, for botching them. But so there's a question about there are many industrial encoder feedback protocols used for industrial motor control, and which approach would they use if they want to use the KD240 with a BiSS-C or HIPERFACE DSL encoder?

Yes. That's a really good question, [ Jamal ]. I did some research on that. So HIPERFACE encoder is a mix of incremental and absolute encoders. So I mean if you can turn it into a logic function that the FPGA can interpret, then you can implement that inside the hardware. Like in terms of being able to implement inside your design, I highly recommend simulating it first before you implement that inside of your system. So that way, you can kind of understand whether or not your control algorithm will work with that type of input. And Simulink is a great tool for doing that level of simulation inside your system.

If you can model it, you can put it in your design.

Yes, exactly. It is great to model it ahead of time to know whether or not your algorithm should work. And then when you put it on the hardware, then you have a better idea of whether or not it will work or not on the hardware, but that's a good question. Hopefully, that answers the question.

And then let's see. So it looks like some motors use Hall sensors for feedback. Do we have any libraries available for something like that?

We don't have libraries available as part of Vitis motor control library. I didn't do a thorough inspection through the motor control block set to see if that's something that you can easily simulate. But I mean, a Hall sensor, I believe is like analog input, so you need some sort of EDC block to convert that into digital bits for your system and then that would become very similar to what you would have for like an encoder.