 Hi Seminole. My topic would be arm call plus DSP co-simulation with customized Timo in Zephyr. For me, yeah, I'm a software engineer from NXP Semiconductor and the members of Zephyr Working Group, also the co-ordinator for Zephyr Atos project. And today we will be covering four topics. First one is how a simulator can benefit. And a brief introduction to a Timo system and how we do a design patent for SOC co-simulator and take the idomex RT595 Timo system as an example to do the co-simulator. Let's go to the first topic. Yeah, let's thinking about SOC and its application development process and the experts that we stack up. Yeah, typically we design SOC by hardware SOC engineer and we have register layer in this layer. The SOC engineer is heavy equipment required, which means very costly equipment, as well as special skill sets to do his job. The digital and analog design, the clock optimization, processing optimization, etc. And after that, we need a software engineer to do the embedded software. This guy also needs some skills and some background to do his work. And then we need a software application engineer to do OS and firmware stuff. And then we need a apps engineer based on the formal works to design the apps for given SOC. Yeah, this is a typical process. So this lets us to think what can we do better? So if we have a simulator, then we have some common things between all software and SOC engineers. Assume we have a submarine that can connect everything into a simple once such as all the software engineer can take part in the whole process. And also join a software SOC design with a tool. And this is Zerfer. So all engineers can call work together to give a better design. And they are work can all be shared. So this is my similar point. And I was demo how we organize a such a process with a chemo simulator. And we see powerful tool that is the Zerfer RTOS. Okay, so first of all, I'd like to give you a brief introduction to chemo in case you are not familiar with what is chemo about. Yeah, chemo is a machine emulator. It can run a modified target operation system such as Windows or Linux on all its applications in a virtual machine. In our case, we use Zerfer. And chemo is made of several subsystems and it can emulator CPU. It has multiple almost all existing popular architecture CPU being supported. And it can also emulate devices such as zero port, keyboard, hard disk network card, etc. And some generic devices such as block device, character device, network device also can you summarize by and connect to this emulator system. And also some additional features such as debugger, user interfaces, some machine state descriptor, and also to connect devices to host a machine. Okay, here is how chemo do the system simulation. Yeah, let's take a target system which here is a power PC one. I just abstracted from the cc's from the chemo designer original PowerPoints. And this is, you know, this is assembling code in power PC. And we do first one, the chemo system will do a translation and generate they call it micro operations such as one line of code will be translated to three micro operations. And those micro operations has been predefined in chemo such as it can be each operation can be translated in the x86 system into x86 assembly code. So in this way, the target com operations can be wrong in our way in a host machine. Just to take example here. And so the key concept here we use chemo is we need a full system emulation. Maybe you need some background on those what is full system emulation but in short it's a system that object file has been reprocessed in the first to generate a simple table and micro options and relocate micro operations and the memory copy is same generated data to the micro operation code and do some OS optimization such as the target code object code can be wrong in a host machine. I will explain what is full system. Yeah, in in chemo there are two same region mode one is a full system emulation and another is guess guess the mode which is useful most of visualization such as you have two stages one stage you you just translate all these applications and wrong ads in a host machine code. This is a full system emulation but you also can just translate those operations into a system call and those system call can you know generate at the luxury system call to underlining operation system such as Linux or Windows which would be a common API so no matter what is wrong in x86 or wrong in ARM the kernel API should be you know doing exactly the same thing right so but in here we are using the full system emulation because we we want to involve the SOC designers work and optimized with software engineers capacity yeah this is the target okay so let's talk about how we do the core similarity design yeah let's think about we have SOC with core A and core B because nowadays such kind of SOC we call this hybrid SOC is becoming very popular and um for many many of reasons yeah usually it's our ASMP system and to do a dual core simulator we need a way to do the inter core inter operation so that the whole SOC can be emulated but by native chemo cannot simulate two different architecture so if this is the ASMP system core A could be an ARM core and core B could be another core which is not fully compatible currently it's not implement in chemo and yeah this is a limitation here so to solve this problem usually we run core A in core A process and we run core B application in core B process and in this core simulator scenario we need a real-time IPC such as the core A and core B can enter can do the inter core inter operation and also we need to have a framework that which is very easy to expand to complex scenario so we do not want to design a very complex scenario in A or in B to modify the chemo original code or adding some very customized or dedicated IP operations inside instead want an easy solution then to select the best IPC system we find D-Bus is a good option because D-Bus is a message response system and simply we will be clicking to one another which is designed by free desktop so that in if you know about Linux it's talking about different applications to do the inter process communication and it also helps coordinate the process of lifecycle so for example is core A go crash and the D-Bus system still works and core B can still also post a message and communicate without the impact of core A which is pretty much similar to a real-world system and exactly the same thing we don't want we call it crashed and crash the whole simulation system so this is a very good feature that we where we choose this and also the D-Bus system is heavily tested in real-world over several years so it's very reliable and about the second requirement easy to expand to complex scenario and because we choose D-Bus it's very rich design so we have several script alternatives other than the you know directly C language or C++ which is the second or three generation of code we can use Python such Python Ruby but in D-Bus we can use Python to do the complex scenario design which is very efficient and easy to debug and easy to maintain many many many you know four generations script code can bring us okay yeah let's go more details on how the chemo suppose use a D-Bus to communicate with one another here we design a new device which is called a message unit device in this unit device we need four interfaces one is initialize itself and another one is how we do the write read from this device and how we do write other world and how we pass the interrupts between devices so if we design this message unit devices and yeah we need a daemon process here we call it we're using a Python script running as a D-Bus daemon process for more detail how to design a D-Bus daemon process you can refer this page there are many examples available and in this way easy implement and very reliable system has been established so that call A and call B can communicate in this way okay now let's see how we implement the four parts in chemo devices first the message unit and the interrupt which will be registered in the unit as an interrupt generator and rewrite and read okay if we look at more details how we initialize devices for the bus it's very easy so because the chemo is based on the G-LIB C design and in G-LIB C there is existing D-Bus APIs that we can call the directory so we first created a D-Bus connection and we created a poxy inside this driver and the only parameters that we need to customize is the name and object path and the interface so other things very common and we created a connect signal so that we can create the interrupt by this signal to the daemon of the Python system and then implement the interrupt in chemo it's very easy so you just write the irq call in chemo that's done and then to the right part we can generate a poxy call which we generate call to a MUA write so we will implement this MUA write with this parameter and this is a special parameter that D-Bus is defined so that we can pass in a UN64 data which is a two unit 464 data which is offset and value which is the common parameters passed in a chemo write to a certain address and then the read so if you know pretty much like the way we design the write API we have an API in Python called MUA read which with this D-Bus poxy call it you know it's like something RPC called to the MUA read in the D-Bus on the other side and the department would be only 64 bits you int and then you have everything and this one you can get a read result from this D-Bus call okay here is the diagram for the whole system so in we in one message unit A parts we generate a read and then we pass a read to a demon and the demon will read directly to the message unit B which is in another chemo process and the read result will pass back and if there is an interrupt signal needed and there is a signal writes to the message unit A and then a write then if the message process have a write message or write operations then it will be first passed to the demon and the demon will use a write call to the message unit A okay so for Python it's very easy to implement we call it the bus message unit services and it's very easy to implement you you need only to import three import will do the trick so for more details you can read this link and this is a real hardware that we are going to design to do the call simulation in a real hardware design there is a message unit identical IP which will communicate with the process A which in our case is Cortex M33 and the process B in our case is a DSP call which has A side and B side so with this IP the two calls can exchange message with each other so usually we can do we cannot do anything without a real silicon or some you know very complex or very slow RTL level EDA to do the simulation but if with this the bus design carefully so we can use a chemo do the first emulator design here okay so now goes to the magic of Zerfra toss because as I mentioned earlier if we have a simulator on the hand and how could we share everything and link everything from a SOCR design to the application to the OS and to the firmware to the driver that's Zerfra so if you're looking at a Zerfra call tree for our case we need to implement a SOC architecture but in Zerfra Delias they already have a SOC implement a very rich SOC operations you can architectures that has been implemented and you can choose wrong and you need some drivers and you need to select you know evaluation for that has been supported in Zerfra this way and in our call in our case is RTL 5 series in this series there is a DSP that we need to implement and the good thing is the DSP has been supported in the Zerfra architecture then here we take the sample controller as example and then we have supported boards which is the ARM series and the DSP series which is extensor from cadency and for drivers the message unit driver has been supported in the IPM driver here we use IPM on the line idonicsc and those parts are already supporting Zerfra and are already supporting in many many boards so even you are calling to a new board you can still use those these architecture and you design the board and you design the DSP board this two one will be the applications runs on the boards runs on chemo system and for the ARM core boards the only thing you need to do is just to add in a mailbox at this address which is calling this driver it's quite simple just a few lines of code and in the DSP code it's very easy only need to add those line of code then this board will have the message unit that you want to use in the real world just exactly that real silicon that you can use so let me give you how we do a core simulator in DSP and design a chemo system with Zerfra so in chemo system we need to implement several devices so that the the board can boot so such as the same binary in a real RT595 board can run in the Zerfra simulator without any modification or skip any drivers and we will reuse Zerfra from work for DSP development with this driver implement and then we have inter operation for 95533 and the DSP core and also too easy to boot a core and demo some quality since we also this is a board view of the RT595 core we have to implement the PMIC such as the board can boot right we have implemented the flash so that a code can be loaded from and the SD card as well and the RAM and the real core as a silicon so those peripherals are very important to the to a real board evaluation so we also implement them in the chemo system also the X-server beta is isosceles we also edit because it's quite easy to integrate and the path is already in chemo system and with this three lines we can build a system of course you need some code change and some drivers inside the chemo and we will be open source course code once we pass the license scan and with this build command line you will build a chemo system and with this command line you will start a chemo instance which runs the Zerfra application and then about the solution DSP Tessica is known for its customized extensor mitoprocessor core which is used in idomex RT595 and to create such kind of chemo instance the command line is quite simple you will make a core configure system and make it and the extensor system will be calling like XTRT595 no MMU system and we can start with a sample controller and minus kernel to call the Zerfra binary directory so something to explain here the DSP part is for demo purpose just use simple controller we do not implement a full function DSP like a real silicon because there are many license issues if we implement that way so we tap the sample controller as example okay then the core simulator system design we will create the three process which is same 33 process chemo process at the bus demon and the DSP process which is also a chemo instance and then we will have writing three applications one is the application that prints the received message through IPM driver and Python scripts that implement the message unit logic and a DSP application which just send some so here we send upon message for IPM of course you can do any internal DSP calculations here but just for demos it's very easy just send out a result assume it has do some calculations and then in our talks we have Zerfra talks has background at true site and we can just use a debug supporting host OS for Python script and for the simulator side we on the lighting is a same 33 chemo system which is customized by us and a chemo system or extensor which also customized by us and there is a host PC which is unmodified also now this is a memory map view for this device driver as you can see the bus message is mapping to exactly the same address as a real silicon for the message unit and this is the external parts also we do exactly the same memory mapping to this address okay let's start some demo here we the demo first start up to the DTS side yes yeah now this is a real time demo okay so this is a quite simple demo but just to show that Zerfra is how powerful and how useful when you're linking the all engineers work and they connect every single engineer from different experts to a very huge projects such as SOC hardware design and the extension work here is we will create several customized chemo for CI testing which we find is very useful when we you know do the CI process and use those chemo system for code coverage analyze which is already fully supported in Zerfra as well but you know to do this in a real silicon is very painful and costive but with chemo is very clear it's almost three and easy and it's standard user cases with core simulation this is mentioned here also here are some links maybe you can help you to understand the chemo system and our RT 595 silicon okay thank you thank you for listening and for all the issues and questions please feel free to email me or to the Zerfra mailing list I put it here thank you all